RFC 7159 deprecates RFC 4627.

On friday, 13 this year the usage of the name Stefan Drees - to indicate me - will be deprecated 😀 After my marriage It will become Stefan Hagen instead.
Also the email address for my contact entry will need an update, as the new email address will then be: [email protected]
I will offer a pull request, when it is done ...

This would incorporate #18 and #19 into the I-D.

• tag draft-butler-geojson-01
• upload

As an alternative to #36, which itself is an alternative to #33, I propose to add the following to section 6 "Interoperability Considerations":

Some commonly-used CRS definitions and/or references specify coordinate ordering that is not longitude then latitude (for geographic CRSs) or easting then northing (for projected CRSs). Using such CRSs is explicitly allowed but NOT RECOMMENDED.

for positions, this is the current draft language: "Additional position elements MAY be included but MUST follow the three specified above and MAY be ignored by software. Interpretation and meaning of additional elements is beyond the scope of this specification."
i am wondering whether it was ever brought up to be able to identify these additional elements? it probably would be possible to add some metadata somewhere that would probably contain URIs, which could then be interpreted as the "metadata label" for any position element beyond the three standard ones. then i could have positions with five elements, and i would be able to tell that the fourth element would be heart rate data, and the fifth would be power data.
it seems to me that adding this should be able without breaking backwards compatibility, and it would make interpretation of GeoJSON using additional position elements much more robust.

Here is the only comment from IANA's expert reviewer:

> Security considerations :
> vnd.geo+json shares security issues common to all JSON content types.
> See RFC7159 Section #12 (http://tools.ietf.org/html/rfc7159#section-12)
> for additional information. vnd.geo+json does not provide executable
> content. Information contained in vnd.geo+json documents do not require
> privacy or integrity services.

> As with other geographic data formats, e.g.,
> application/vnd.google-earth.kml+xml, providing details about the
> locations of sensitive persons, animals, habitats, and facilities can
> expose them to unauthorized tracking or injury.

This seems to directly contradict the preceeding paragraph: First you
say that privacy/integrity protections are not required, and then you
say the content can be sensitive, in which case such protections would
seem to be appropriate.

I suggest deleting the final sentence in the first paragraph and
adding something like, "If sensitive data requires privacy or
integrity protection it must be provided externally."

I'm inclined to do exactly that.

We got super sort notice about https://datatracker.ietf.org/meeting/92/agenda/dispatch/ due to (as I understand it) temporary AD vacancy. I'm going to put together slides this afternoon for review here and then send them to Mary Barnes (DISPATCH WG) on Sunday.

I'm certain that application/geo+json or application/vnd.geo+json are the right media types for us. The former will require that the draft become an RFC. The latter gets approved much more quickly and I'm inclined to go that route.

Instructions on how to register are at http://tools.ietf.org/html/rfc6838 and the form to do it is at http://www.iana.org/cgi-bin/mediatypes.pl.

Comments @geojson/owners @geojson/contributors?

Add section headers and move text around if needed.

The language of http://tools.ietf.org/html/draft-butler-geojson-02#section-2.1.6 admits empty coordinate arrays. I'd like to add some text explaining, since it isn't very clear that parsers may skip these.

@geojson/owners @geojson/contributors

If the spec mandates WGS84, then it should also mandate date/time for each coordinate, otherwise geojson files can only be used for short-term throwaway datasets, since accuracy and longevity are impaired. Using my local crs (OSGB36) I know that coordinates drift far far less since it is locked to the European plate, but WGS84 coordinates will constantly drift.

I am opposed to removing support for crs. Please maintain support for crs, and preferably it should be a mandated attribute.

If any Authors of the original GeoJSON spec or Contributors to the present I-D know of any claim to Intellectual Property Rights for GeoJSON, please contact me or @dret and we'll guide you through the disclosure process.

I'm happy to say that I'm personally unaware of any. Existence of IPR doesn't block the formation of a working group but delayed disclosure would be a pain in the neck.

/cc @geojson/owners @geojson/contributors @pramsey @sheppard @dr-shorthair @skj3gg

http://tools.ietf.org/html/draft-butler-geojson-03#section-3.2 describes how to link to an external CRS definition. Fairly comprehensive services are available from OGP (EPSG) and OGC that provide CRS definitions formatted in GML, so it would be useful to add "gml" to the list of suggested values for CRS type, and perhaps an example. Here is a proposed modification, starting with the last sentence of the second paragraph:

Suggested values are: "proj4", "ogcwkt", "esriwkt", "gml" but others can be used:

"crs": {
"type": "link",
"properties": {
"href": "http://example.com/crs/42",
"type": "proj4"
}
}

"crs": {
"type": "link",
"properties": {
"href": "http://www.opengis.net/def/crs/EPSG/0/27700",
"type": "gml"
}
}

Currently we have 6 authors

Independent                                                    H. Butler
Internet-Draft                                                 Hobu Inc.
Intended status: Informational                                   M. Daly
Expires: February 6, 2015                                        Cadcorp
                                                                A. Doyle
                                                                     MIT
                                                              S. Gillies
                                                             Mapbox Inc.
                                                               T. Schaub
                                                                 OpenGeo
                                                                S. Drees

Too many? Just right? Stefan Drees suggested that we might want to have just the editor's name.

Text contributions are summarized at https://github.com/geojson/draft-geojson/graphs/contributors. This does not include comments made on this repo's issues.

Needs a new version. From the IETF Secretariat:

The following draft will expire soon:

Name:     draft-butler-geojson
Title:    The GeoJSON Format
State:    I-D Exists
Expires:  2015-02-06 (in 1 week, 3 days)

now that I-JSON is available (http://tools.ietf.org/html/rfc7493), maybe it would make sense to refer to it and say that GeoJSON producers should produce I-JSON, but also should be prepared to process JSON that is not proper I-JSON (basically postel's law for GeoJSON, at least for the serialization level).

Attending IETF 93 will help our chartering processing enormously. Let's send a representative. Here are some possibilities, in my preferred order:

1. One of you other authors ;)
2. Me (I like Prague, but holy cow my summer is busy enough already)
3. Someone else from Mapbox to stand in for me (we have 2 engineers in Karlsruhe, Germany)

Any volunteers?

/cc @adoyle @mpdaly @tschaub @hobu @crschmidt @sdrees

Preferably, allow for short definitions, such as "EPSG" : 3857 to make it more compact. How one would transfer already projected data via GeoJSON? If it required unprojecting to WGS84, the process is lossy and often is slow for polygons/ polylines.

Clearly define what is the interpretation of the line segment in geographic space. If interoperability is important, preferably it should allow for Plate Carree like interpretation of WGS84, at least as a clear option.

As an alternative to #33, I propose to add to the end of section 3 an explanation like this:

CRS-sensitive applications shall write coordinates in longitude, latitude or easting, northing order. This may require flipping the coordinates from their "native" order. These applications will also write a CRS object which, in addition to describing the ellipsoid, datum, and projection parameters of the coordinate reference systems, indicates to other CRS-sensitive applications that they will need to flip the coordinates back when reading them.

My intent is to make it very clear that the CRS indicated in the GeoJSON doc does not govern the ordering of coordinates as they are expressed in the GeoJSON doc. It tells a CRS-sensitive application that another one of its class has "jumped through the hoops".

Does this help? Of course, a definition of CRS-sensitive will be needed.

• set date
• tag
• upload

@pramsey I'll bust the considerations out of template.xml and move them to a considerations.md to make work on #43 easier.

Here's the Dispatch agenda: https://datatracker.ietf.org/meeting/93/agenda/dispatch/. I'll update here as it goes.

http://tools.ietf.org/html/draft-butler-geojson-03#section-3.1 provides a mechanism for referring to a named CRS. The draft recommends use of OGC CRS URNs.

Since 2010 OGC has recommended URLs (aka "http URIs") in preference to URNs, and provides services to make these resolvable, which is all more web- and linked-data- friendly. I suggest that this is added either in place of [or alongside] the recommendation to use URNs. Here is a suggested replacement for section 3.1:

3.1. Named CRS

A CRS object may indicate a coordinate reference system by name. In
this case, the value of its "type" member must be the string "name".
The value of its "properties" member must be an object containing a
"name" member. The value of that "name" member must be a string
identifying a coordinate reference system. OGC CRS URLs [or URNs] such as
"http://www.opengis.net/def/crs/OGC/1.3/CRS84" [or "urn:ogc:def:crs:OGC::CRS84"] are RECOMMENDED over legacy identifiers
such as "EPSG:4326".

"crs": {
"type": "name",
"properties": {
"name": "http://www.opengis.net/def/crs/OGC/1.3/CRS84"
}
}

The elements in [square brackets] can be included if it is considered desirable to reflect common usage of the URNs (if that is the case) but I would recommend omitting them to encourage use of URLs going forward.

@sdrees wrote in the original readme

• What about an ANTLR4 grammar as non-normative appendix B after the examples and before the contributors (which then would become Appendix C)?
• Surely no (A)BNF as GeoJSON is simply not describable through ABNF (case sensitivity is missing from literals in ABNF :-) ! ... right?

Clearly IETF members appreciate a formal grammar.

What is the process for moving into and through the IETF process? What tasks do we need to do, what are the steps, what order are they in, and what is the approximate time line?

I'd rather get the big picture settled a little bit before engaging in a lot of debate about proposals for changes to the spec, etc. because I need to know when to really pay attention.

Anyone want to take a stab at documenting how to represent the bounding box of Antarctica in GeoJSON? @pramsey?

I'm finding http://www.jasondavies.com/maps/bounds/ to be a cool resource for thinking about this.

As pointed out in geojson/geojson.github.io#16, the coordinates in one bbox example aren't quite valid.

Our charter is inadequate. We'll work out with the RAI ADs what exactly that means, do it, and get this WG started.

Apparently, I was looking at the wrong charters (JSON WG charters, very terse) for guidance.

The IETF needs some rights to GeoJSON. The way this works is that we grant rights to the IETF Trust and the Trust then grants them to the IETF. Which rights? See RFC 5378 sec 5.3:

5.3. Rights Granted by Contributors to the IETF Trust

To the extent that a Contribution or any portion thereof is protected
by copyright or other rights of authorship, the Contributor and each
named co-Contributor grant a perpetual, irrevocable, non-exclusive,
royalty-free, world-wide, sublicensable right and license to the IETF
Trust under all such copyrights and other rights in the Contribution:

a. to copy, publish, display, and distribute the Contribution, in
whole or in part,

b. to prepare translations of the Contribution into languages other
than English, in whole or in part, and to copy, publish, display,
and distribute such translations or portions thereof,

c. to modify or prepare derivative works (in addition to
translations) that are based on or incorporate all or part of the
Contribution, and to copy, publish, display, and distribute such
derivative works, or portions thereof unless explicitly disallowed
in the notices contained in a Contribution (in the form specified
by the Legend Instructions), and

Bradner & Contreras Best Current Practice [Page 10]

RFC 5378 RFC 3978-incoming November 2008

d. to reproduce any trademarks, service marks, or trade names which
are included in the Contribution solely in connection with the
reproduction, distribution, or publication of the Contribution and
derivative works thereof as permitted by this Section 5.3,
provided that when reproducing Contributions, trademark and
service mark identifiers used in the Contribution, including TM
and (R), will be preserved.

My interpretation of the CC-Attribution license on the GeoJSON spec is that the rights above are already granted. Does anyone disagree?

/cc @metazool @geojson/owners @geojson/contributors

Not sure when to raise this, but what the heck. The debate on RFC 5988 webby extensions vs. JSON-LD semwebby extensions in #56 makes me wonder about extensions in general. It strikes me that the beauty of extension mechanisms in JSON is that there are so many to choose from. Why do we need to specify an extension mechanism at all? Won't the communities doing the extension want to choose the mechanism that is best suited for their community? People can develop extensions any way they want, and can happily use them without us needing to include the entry points in the base spec. Look at https://github.com/topojson/topojson-specification - they just went about their business and have what seems to be a pretty robust GeoJSON. No fuss, no muss.

Use the form at http://datatracker.ietf.org/submit/

Checklist (from guidelines at http://www.ietf.org/id-info/guidelines.html):

• IPR-Related Notices Required in Internet-Drafts
• Internet-draft boilerplate
• Formatting
• Naming and submission

Proposed name: draft-butler-geojson-00. Howard Butler is the first author in alphabetical order.

Submission-ready draft.txt: https://gist.github.com/sgillies/8304592.

In http://tools.ietf.org/html/draft-butler-geojson-03#section-3 the last dot point leaves a slight ambiguity about the interpretation of CRS references. This was subject of discussion on the email list in December 2013, but there was no follow-up on the final suggestion from Jeff Yutzler. I suggest a minor reword - in place of

o The presence of a CRS object SHALL NOT change the ordering of
coordinates specified in section 2.1.1.

use the following:

o Coordinates SHALL be ordered as specified in section 2.1.1. regardless of the coordinate order specified by a CRS object.

and then add a small gloss as follows:

NOTE: For historical reasons, some standard CRSs specify that coordinates are given in latitude-longitude order. Care should be taken when exchanging data using these coordinate reference systems, as the coordinate order may be misinterpreted by clients. For full compatibility with both GeoJSON and the historical CRS definitions, it is RECOMMENDED that only "right-handed" CRS are used in GeoJSON.

I feel the I-D needs to address undefined elevation. Doing it like https://tools.ietf.org/html/rfc5870#section-3.4.5 seems to be the proper thing.

Directions from the AD:

Sorry for the delay here. It looks like the next step here is to send a charter proposal to the DISPATCH mailing list, [email protected]. Then we'll have some discussion at the IETF meeting in Dallas, and assuming there are no blockers (I don't foresee any), we'll get the charter sent to the IESG.

Would you mind sending your draft charter to DISPATCH? You can crib from some of the prior examples, e.g.:
http://www.ietf.org/mail-archive/web/dispatch/current/msg05560.html

The 15 decimal places of precision (looking at you, OGR) we see in the wild are a real interop problem to be addressed.

Pending response from IANA on application/vnd.geo+json

draft-butler-geojson-05 expires 2015-08-01.

this one may be interesting to look at, and maybe it's even useful to add this as a reference? http://www.w3.org/TR/2015/NOTE-sdw-ucr-20150723/

in positions, extensions can be used by simply adding more values after the first three ones (the question if these extensions must be numbers is a separate one and has been raised in #57). but is it possible to use extensions when there is no elevation? it's hard to imagine how, because the spec requires number values and thus NULL would not be a valid elevation. if there indeed is no way to use extensions when there is no elevation data, then maybe adding a clarification about this would be useful.

Privacy is a big concern for the IETF and its members. Recently, RFC 7258 asserted that Pervasive Monitoring Is an Attack. Tim Bray has the back story.

Years before that was published, there was a working group chartered to design an architecture for using location information while respecting the privacy of users: GEOPRIV. Contributors to GEOPRIV will certainly be contributing to a GeoJSON WG and questions about GEOPRIV's privacy requirements will come up. My response today to such a question is here: https://mailarchive.ietf.org/arch/msg/dispatch/6sGVLInUvyl232IYF0x8Aahz34Y.

On Wed, Jul 22, 2015 at 10:09 AM, James Winterbottom xxx@xxx wrote:

It feels like the question is the target of the location ever going to be
conveyed with the location information?

Are you asking if it's possible to convey, say, phone numbers and locations
of the the phones and the semantics needed to track the devices and their
users together in GeoJSON? This would require a protocol or framework
external to the GeoJSON format. GeoJSON specifies that Features should have
an "id" property and that it should uniquely identify the feature within
its collection. There's no requirement or implication that the id
identifies the thing described by the Feature. GeoJSON's "id" is no more
than Atom's Entry "id" (RFC 4287 has had a major influence on GeoJSON).
Semantics such as what it would mean to use, eg, "tel:867-5309" as a
feature id are not defined by GeoJSON.

I (backed up by former chairs of GEOPRIV) am asserting that the GeoJSON format is exempt from GEOPRIV requirements in the same way that RFC 5870 'geo' URIs are: https://tools.ietf.org/html/rfc5870#section-9.2. There may be more debate on this.

Certainly, some applications of GeoJSON including ones I've drafted to use JSON-LD are less exempt. Using JSON-LD it's possible to connect things and their locations with explicit semantics and truly identify targets in the GEOPRIV sense. And that's why it's a good thing to keep these applications out of the charter.

I hope I've been able to represent the IETF's privacy concerns briefly and well to geo developers. We (counting myself among the latter) don't talk about privacy enough in my opinion.

Summary: privacy is important, let's not brush it aside but draw some lines around where it is and isn't strictly required.

https://datatracker.ietf.org/doc/draft-ietf-json-text-sequence/ is getting close to completion and an interesting way how potentially large collections of JSON objects can be serialized without having to wrap them in one all-encompassing JSON structure. maybe there is a way how this could fit into GeoJSON's overall picture.

We've agreed to not recommend use of coordinate systems other than CRS84, which is a big step toward interoperability. It's not unlike the UTF-8 encoding constraint in I-JSON: RFC 7159 JSON allows UTF-16 and UTF-32, but I-JSON says "use only UTF-8 for maximum interop."

I-JSON constraints

I-JSON also adds constraints to JSON numbers, saying:

I-JSON messages SHOULD NOT include numbers that express greater magnitude or
precision than an IEEE 754 double precision number provides, for
example, 1E400 or 3.141592653589793238462643383279.

and adds constraints to object items:

Objects in I-JSON messages MUST NOT have members with duplicate names.

Constraining GeoJSON geometries

I propose that GeoJSON interop could be helped by adding a geometry constraint. Consider the geometry below:

{ "type": "GeometryCollection", 
  "geometries": [
     { "type": "GeometryCollection", 
       "geometries": [ 
         { "type": "Point", "coordinates": [0, 0] } 
       ] } ] }

It's functionally equivalent to { "type": "Point", "coordinates": [0, 0] }: if you read the geoms into a simple features implementation (JTS, GEOS, &c), it should say they are equivalent. But it's clear that arbitrarily nested collections are harmful to interoperability.

About geometry collections we could say

1. maximally interoperable geometry collections MUST NOT contain other geometry collections
2. and/or, maximally interoperable GeoJSON SHOULD NOT contain geometry collections

Questions for you all:

1. Do you support or oppose such constraints?
2. Do they belong in the GeoJSON I-D or a subsequent draft (like I-JSON for JSON)?

Changes include:

• Ring winding recommendation and bounding box best practice.
• tag
• submit (https://datatracker.ietf.org/submit/status/66238/af2a94226d2265fb918f28381724aa63/)
• announce (http://tools.ietf.org/html/draft-butler-geojson-05)

As mentioned in #4, I think the master branch should only contain a single set of sources (assuming that would be middle.mkd, back.mkd, template.xml, and transform.xsl).

The gh-pages branch could be used for built docs (and then we could preview them at http://geojsonwg.github.io/draft-geojson/draft.html etc.).

If folks are in favor, I'll turn this into a pull request.

See #76 for a discussion of drift and WGS 84.

This issue is not about representing trajectories of features or paths in time. It's about letting providers specify that coordinates in a collection were measured at a particular time so that future users can account for WGS 84 revisions and drift between, say, Ordnance Survey National Grid and WGS.

I suggest that we consider one single timestamp for a collection and not mix features measured at different times into one collection.

As a part of this work we can also specify interpretation of measurement time when no timestamp is provided, using filesystem or transport protocol timestamps.

the spec currently says the following about values in positions past the three specified elements of long, lat, and elevation:

Additional position elements MAY be included but MUST follow the three specified above and MAY be ignored by software. Interpretation and meaning of additional elements is beyond the scope of this specification.

this seems to allow non-number values. but then again, the text about positions in general says it's "an array of numbers". so the question is: can i have non-number values past the third position? specifically, i am wondering if the following is legal position or not:

        [
          -122.45698875747621,
          37.78691156767309,
          138.1999969482422, 
          NULL
        ]

it would be good to clarify the language so that it's clear whether non-number values are allowed or not.

what about removing the "To-do" list from the README and instead create issues that can be tracked and commented on?

On Friday I talked with Alissa Cooper, an IETF AD for the Real-time Applications and Infrastructure Area (rai) and got some great advice about moving the GeoJSON I-D forward. She suggests that we write a charter for a new working group specifically focussed on GeoJSON and submit that for approval. Here's a nice tight charter showing that working groups don't have to be open ended: https://datatracker.ietf.org/wg/json/charter/. As well as an approved charter, we'd need to draft two non-author chairs. We can continue to work on the I-D on GitHub, but actual motions by the chairs and all that would (I presume) be done on an IETF mailing list.

I'm very interested in doing this. Are there any @geojson/contributors or @geojson/owners opposed to forming a GeoJSON working group that would oversee the last few revisions of the GeoJSON I-D?