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

[Tim Schaub]

(Resending from new address.)

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 on your questions 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.  The
exterior ring would represent the exterior of the donut and the
interior would represent the hole.

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