[GeoJSON] GeoJSON "Interior Ring" and "Hole" Definitions

[David Ellis]

Thank you all for a thorough explanation!

This should unblock us on incorporating holes in in-n-out. :)

David

On Tue, Nov 12, 2013 at 11:34 AM, Tim Schaub <tschaub at boundlessgeo.com>wrote:

> One thing to note.  The GeoJSON specification intentionally does not
> enforce that geometries are "valid" or "clean."  This allows GeoJSON
> to be used as a transfer format between a client that might allow
> drawing of "invalid" geometries and a server that might be in charge
> of cleaning or validating (for example).
>
> My opinions below:
>
> On Tue, Nov 12, 2013 at 10:54 AM, David Ellis <ellis at uber.com> wrote:
> >
> > Some questions on the spec:
> >
> > Is there a reference implementation for generation and/or consumption of
> > GeoJSON objects. Alternatively, is there a test suite of some sort
> involving
> > GeoJSON objects?
>
> Tom already mentioned the MapBox hinter.  There is also
> http://geojsonlint.com/.
>
> We should do a better job on the site listing implementations.  I
> don't think any should be endorsed as "reference" - but it would be
> nice to point to some reusable utilities for testing & parsing.
>
> > What are "Interior Rings" and what are "Holes"? Are they synonyms?
>
> They should be considered synonyms.  If you are modeling a 2d donut,
> you can do so in GeoJSON by using a polygon with two rings.  As
> mentioned above, GeoJSON doesn't say that all points on an interior
> ring must be inside the exterior ring.  So GeoJSON can be used to
> serialize geometries that might not pass common topology validation
> rules.
>
> > What happens if interior rings overlap? If holes overlap? If an interior
> > ring overlaps a hole? What happens if they partially intersect? (See
> image
> > in the link above.)
>
> See above.  GeoJSON doesn't enforce that you have a geometry that
> passes common topology validation rules (you can still serialize
> "invalid" geometries).
>
> > Finally, the specification does not define what a GeoJSON interpreter
> should
> > do with malformed and/or extended GeoJSON objects. Is this truly
> > implementation specific? (This would seem to limit the ability for
> interop
> > between GeoJSON producers and consumers written by different software
> > teams.)
>
> The spec is about a serialization format.  It does not describe a
> service or any protocol used to communicate between consumers of
> GeoJSON.  Consumers of GeoJSON can decide for themselves how
> strict/lenient they want to be in parsing.  This is akin to the HTML
> spec not describing what consumers should do with invalid HTML.
>
> Quoting from the HTML 4 spec:
>
> "This specification does not define how conforming user agents handle
> general error conditions, including how user agents behave when they
> encounter elements, attributes, attribute values, or entities not
> specified in this document."
>
> This has worked out well for HTML in terms of interoperability.
>
> Tim
>
>
> >
> > Regards,
> >
> > David Ellis
> >
> > Uber Technologies, Inc
> >
> >
> > _______________________________________________
> > GeoJSON mailing list
> > GeoJSON at lists.geojson.org
> > http://lists.geojson.org/listinfo.cgi/geojson-geojson.org
> >
>
>
>
> --
> Tim Schaub
> Vice President, Engineering | Boundless
> tschaub at boundlessgeo.com
> @tschaub
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.geojson.org/pipermail/geojson-geojson.org/attachments/20131112/d349736d/attachment.htm>