Subject: Re: [Geojson] Extensibility of GeoJSON

From: Jeff Yutzler <[email-masked]>
Date: Fri, 20 Nov 2015 19:09:00 -0500

All,
I am pleased to see that the GeoJSON community is considering an
extensibility mechanism. I believe there is a benefit to being able to
define ways for different implementers to do the same thing the same way,
without creating a burden on minimally-compliant implementations.

I like your set of five guidelines. The one thing I would add is a
mechanism for discovering what extensions are in use in a file (so that a
client does not have to duck-type). This would be the JSON equivalent to
GeoPackage's extensions table (See
http://www.geopackage.org/spec/#_extensions).

Go for it!
-Jeff

---------- Forwarded message ----------
> From: Sean Gillies <[email-masked]>
> To: [email-masked]
> Cc:
> Date: Fri, 20 Nov 2015 15:04:14 -0700
> Subject: [Geojson] Extensibility of GeoJSON
> Hi all,
>
> Consensus on and documentation of how to extend GeoJSON is part of our
> group's charter. Let's get right to it.
>
> From my point of view, having no extensibility story is not an option.
> GeoJSON is being extended already. Here are 5 examples off the top of my
> head:
>
> - https://github.com/mapbox/simplestyle-spec/blob/master/1.1.0/README.md
> - https://github.com/mapbox/carmen/blob/master/carmen-geojson.md
> -
> https://github.com/geocoders/geocodejson-spec/blob/master/draft/README.md
> - http://wiki.openstreetmap.org/wiki/Overpass_turbo/GeoJSON
> - https://github.com/opengeospatial/owscontext
>
> I see the simplestyle spec, in which styling directives are carried in a
> Feature's "properties" object (akin to inline styles in HTML), as a product
> of the original GeoJSON spec having no extensibility story. With no
> consensus on whether new "style" or "class" objects were valid GeoJSON or
> could expect support from other software, the simplestyle authors saw
> mixing style and content as the only viable option. The result: feature
> properties bloat and key collisions. If every application extends GeoJSON
> by not extending it, by dumping everything into the "properties" object,
> we'll have a mess.
>
> As a starting point for this extensibility discussion, let's begin with
> what's going on in Activity Streams 2.0:
>
> http://www.w3.org/TR/activitystreams-core/#extensibility
>
> Activity Streams 2.0 is based on JSON-LD and GeoJSON is not based on
> JSON-LD. Still, there's plenty of common ground. I think the first
> paragraph of AS 2's 6.0 translates straight to GeoJSON.
>
> In Activity Streams 2.0, an "extension" is any property not defined by the
>> Activity Vocabulary. Consuming implementations that encounter unfamiliar
>> extensions MUST NOT stop processing or signal an error and MUST continue
>> processing the items as if those properties were not present. Note that
>> support for extensions can vary across implementations and no normative
>> processing model for extensions is defined. Accordingly, implementations
>> that rely too heavily on the use of extensions may experience reduced
>> interoperability with other implementations.
>>
>
> Also I think section 6.1 on the re-serializations of extensions is
> something we should adapt to GeoJSON.
>
> Implementations that parse and then reserialize Activity Streams 2.0
>> documents that contain extension properties *SHOULD* take sufficient
>> care to ensure that extension properties used within the original document
>> are preserved and serialized appropriately.
>>
>
> Related: the GDAL package and its ogr2ogr program will, in version 2.1,
> preserve and re-serialize GeoJSON extensions. It's going to be a great
> model for other implementations.
>
> Section 6.2 in AS 2.0, about aggregation, is also relevant to GeoJSON.
>
> Implementations that collect and aggregate Activity Streams objects from
>> multiple sources may often need to deal with conflicting or incompatible
>> extensions.
>>
>
> These three paragraphs seem to me to be a pretty good core for GeoJSON's
> extensibility guidelines. On top of them, I'd like to express that GeoJSON
> should not be extended in the following ways:
>
> - The set of GeoJSON types ("FeatureCollection", "Feature", "Point",
> "LineString", &c) should not be extended.
>
> - The position construct at the heart of GeoJSON's multidimensional
> geometry "coordinates" array (
> https://tools.ietf.org/html/draft-ietf-geojson-00#section-2.1.1) should
> not be extended beyond longitude, latitude, elevation, and linear
> referencing M.
>
> Are there any objections to adding a new extensibility section to the
> draft based on the 5 points above? Are there any extra considerations that
> would need to be added?
>
> --
> Sean Gillies
>
>
>
-- 
Jeff Yutzler
Image Matters LLC <http://www.imagemattersllc.com/>
Mobile: (703) 981-8753

---

From: Erik Wilde <[email-masked]>
Date: Sun, 22 Nov 2015 09:45:36 +0100

hello jeff.

On 2015-11-21 01:09, Jeff Yutzler wrote:
> mechanism for discovering what extensions are in use in a file (so that
> a client does not have to duck-type). This would be the JSON equivalent
> to GeoPackage's extensions table (See

http://tools.ietf.org/html/rfc6906 could be a foundation, but it's a 
simple mechanism. it simply means that it is possible to signal that a 
profile is being used, but it does not support any more fancy "profile 
model" where for example a profile could be recognized as being a 
refinement of an existing profile.

this could be added by having a top-level "profile" member that would 
accept an array of URIs, each identifying one profile.

cheers,

dret.

-- 
erik wilde | mailto:[email-masked] |
            | http://dret.net/netdret    |
            | http://twitter.com/dret    |

---

From: Sean Gillies <[email-masked]>
Date: Tue, 24 Nov 2015 14:53:12 -0700

> accept an array of URIs, each identifying one profile.

A standard/information profile mechanism would be best, I agree. I don't
see in RFC 6906 a mention of embedding profiles in documents. Are you
suggesting doing for GeoJSON what RFC5988 proposed for HTML (
http://tools.ietf.org/html/rfc5988#appendix-A)?

-- 
Sean Gillies

---

From: Erik Wilde <[email-masked]>
Date: Wed, 25 Nov 2015 10:11:14 +0100

On 2015-11-24 22:53, Sean Gillies wrote:
> On Sun, Nov 22, 2015 at 1:45 AM, Erik Wilde <[email-masked]
> <mailto:[email-masked]>> wrote:
>     simple mechanism. it simply means that it is possible to signal that
>     a profile is being used, but it does not support any more fancy
>     "profile model" where for example a profile could be recognized as
>     being a refinement of an existing profile.
>     this could be added by having a top-level "profile" member that
>     would accept an array of URIs, each identifying one profile.
> suggesting doing for GeoJSON what RFC5988 proposed for HTML
> (http://tools.ietf.org/html/rfc5988#appendix-A)?

my usual recommendation re:profiles is:

- if your model supports generic and typed links, then use the "profile" 
relation type for indicating profiles. (but GeoJSON does not have 
generic typed links).

- if your model has no generic typed links, then define some way how 
profile links can be represented. make sure that you allow more than one 
profile to be indicated (that's what GeoJSON could do).

- since the profile links are resource-scoped, it makes sense to also 
allow them in HTTP link headers. the media type ideally should say that 
it's equivalent to see a profile being indicated embedded in the 
resource, or signaled via an HTTP link header.

- ideally, the media type should allow a profile media type parameter, 
so that profiles become visible on the web level and can be used, for 
example, in content negotiation.

https://github.com/dret/I-D/blob/master/Abandoned/atom-profile/draft-wilde-atom-profile-04.txt 
is where i tried to write a blueprint of how profiles (ideally) should 
be used. i abandoned this one a while ago because of a lack of interest, 
but if could serve as a starting point if there was some momentum to 
support profiles in GeoJSON.

cheers,

dret.