Subject: Re: [Geojson] Extensibility of GeoJSON

From: Jeff Yutzler <[email-masked]>
Date: Wed, 25 Nov 2015 13:21:46 -0500

When Sean started the thread, he said the following:

...as a product of the original GeoJSON spec having no extensibility
> story...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.

We will make no progress unless we agree on this assertion or come up with
another one that we can agree on. I happen to agree with it; others are
(vehemently) opposed. Before talking about the way ahead, we must resolve
this.

The reason I agree with the assertion is that there is an emerging
unwritten set of best practices for presenting GeoJSON content. Things like:
* Feature properties are presented in tabular form.
* If simplestyle-spec properties exist, they are used to style the
features.

I think these are good things for the community. They encourage treating
similar information the same way. They are not domain-specific. They aren't
harmful (they don't break any of the existing rules). They are also brittle
- they break down when GeoJSON producers innocently do conflicting things.
A defined extension mechanism would solve this problem, but only if we
agree if it is a problem worth solving.

-Jeff

---

From: Allan Doyle <[email-masked]>
Date: Wed, 25 Nov 2015 13:48:51 -0500

On Nov 25, 2015, at 1:21 PM, Jeff Yutzler <[email-masked]> wrote:
> ...as a product of the original GeoJSON spec having no extensibility story...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.
> 
> We will make no progress unless we agree on this assertion or come up with another one that we can agree on. I happen to agree with it; others are (vehemently) opposed. Before talking about the way ahead, we must resolve this. 
> 
> The reason I agree with the assertion is that there is an emerging unwritten set of best practices for presenting GeoJSON content. Things like:

Please explain what this means.

> * If simplestyle-spec properties exist, they are used to style the features.  
> 
> I think these are good things for the community. They encourage treating similar information the same way. They are not domain-specific. They aren't harmful (they don't break any of the existing rules). They are also brittle - they break down when GeoJSON producers innocently do conflicting things. A defined extension mechanism would solve this problem, but only if we agree if it is a problem worth solving.

How, specifically, would a defined mechanism solve the problem? (This is asked in total innocence, not to be obstructive. I really want to understand the answer.)

I’m not against solving the problem. I’m against solutions that arbitrarily invalidate existing GeJSON or that just add a level of insulation and there’s still a free for all inside there. 

	Allan