Planning for IETF draft spec

[perrygeo]

Based on Appendix B of the draft IETF GeoJSON spec here are some additional tests we may want to add to bring geojsonhint in line with the upcoming spec

• positions can have 2 or 3 elements (lon, lat) or (lon, lat, elev)
• objects may have extensions
• position cannot have < 2 elements
• position should not have > 3 elements
• bbox for a feature collection which crosses the antimeridian should use WSEN (not minx, miny, maxx, maxy)
• geometries crossing the antimeridian are cut (recommendation)
• extensions must not change semantics
• Should not have single-geometry geometry collections
• Should not have empty geometry collections
• Should not have nested geometry collections
• Right-Hand Rule for polygon rings (Recommendation)
• Warn if > X decimal places precision?
• Non-default CRS is not recommended. It's hinted that specifying any crs object is not recommended?
• GeoJSON types should be case-sensitive
• bbox should be an array of 4 or 6 numeric elements

This is just a preliminary list; might have missed some and some of these may be covered by existing tests that I didn't see on the first pass. Can we get more :eyes: on this list and help me refine it?

What shoud we do about versions? Should we allow for validation against the GJ2008 spec vs IETF spec?

cc @sgillies

[perrygeo]

re: the crs object. Per chat with @sgillies

a geojson linter should flag the presence of a crs member, absolutely. in the case of "urn:ogc:def:crs:OGC:1.3:CRS84" i believe it should report "this crs member is equivalent to the GeoJSON default and should be removed to minimize confusion"

[sgillies]

@perrygeo thanks! The gist of "extensions must not change semantics" is

• No other types than the ones in the spec
• No geometries with "features", "geometry", "properties".
• No features with "features", "coordinates".
• No collections with "properties", "coordinates".

What shoud we do about versions? Should we allow for validation against the GJ2008 spec vs IETF spec?

The goal of the GeoJSON WG is to obsolete the old spec and enabling people to validate against the old appears (to me) contrary to that goal.

Would you be able to take the lead on this? I'll help but I expect that I'll have to deal with a bunch of nitpicking yet to get GeoJSON to RFC and should focus on that.

[perrygeo]

@sgillies I'll work on getting test cases together next week.

@tmcw I may hit you up for some questions about the codebase.

[tmcw]

IETF branch is now reviewed & merged, and will go out with a v2. The only sketchy part was precision, which might need a rethink soon, especially give the validity of 1e-10 for instance. But I don't see any better way at the moment and what we have is great.