geojson/draft-geojson

Address AD comments

sgillies opened this issue · 2 comments

sgillies commented

This is a multi-issue tracking ticket. From https://mailarchive.ietf.org/arch/msg/geojson/dK5vSfGSXCuWR7QkzQulk2yicMs

= Section 3.1.1 =

"Implementations SHOULD NOT extend positions beyond 3 elements.
Parsers MAY ignore additional elements. Interpretation and meaning
of additional elements is beyond the scope of this specification."

Since this is given as a SHOULD NOT I assume there are exception cases envisioned where implementations will specify more than 3 elements. What kind of circumstances might give rise to those exception cases? It would be good to provide some explanation in the spec.

  • PR addressing this: #196

= Section 4 =

"Applications requiring a CRS
other than the default MUST assume all responsibility for CRS
identification, coordinate accuracy, and interpretation of missing
elevation values."

"MUST assume responsibility" is a bit of a strange construction for a normative requirement. I think I get what this is trying to accomplish, but I'm not sure it works as phrased. For coordinate accuracy and interpretation of missing values, I think the idea is really to warn implementors that they will have to fill in the gaps if they receive coordinates meant to be understood using a different CRS than what the application is using. Is that right? If so, I think this should just be phrased as a warning, without the normative requirement.

CRS identification is a bit trickier, because it is included in [GJ2008] but not here, so this sort of sounds like it could be recommending use of the crs parameter as specified in [GJ2008] while also not incorporating that into this spec (for an unspecified reason). If you really want to require implementations to identify the CRS if they're not using the default, then I would think a way to do so (a la [GJ2008]) should be included in this spec. If not, then it seems inappropriate to normatively require that the CRS be identified; a non-normative recommendation would do instead, I think. Note that the decision of what to do here also has bearing on Section 10.3, which basically assumes that the CRS will be identified.

  • PR addressing this: #202

Nits:

= General =

(1) Typically RFCs in the IETF stream are limited to 5 authors. Would you consider collecting authorship under 1 or 2 editors? If not, do all 6 authors here expect to be active in responding to review comments and AUTH48 questions?

  • PR: #201, we're going with 6 authors after all.

(2) The other geographic position formats that have been specified previously in the IETF include some support for expressing uncertainty. It would be helpful to explain somewhere in this spec why it is not doing that.

= Section 3.1 =

s/A Geometry object represents points, curves, and surfaces in coordinate space./A Geometry object represents a point, curve, or surface in coordinate space./

  • Clarification made on the list by @tschaub, accepted. No change.

= Section 4 =

s/height in meters above the WGS 84 reference ellipsoid./height in meters above or below the WGS 84 reference ellipsoid./

(Right? I'm assuming this element also covers depth.)

= Section 10.4 =

s/SHOULD/should/

sgillies commented

@coopdanger @martinthomson @dret We've done it. May I upload -03?

And no, I didn't purposefully wait until Friday the 13th :)

martinthomson commented

Go for it!