[GeoJSON] Features with "unexpected" properties

[Sean Gillies]

On Fri, Sep 16, 2016 at 4:41 AM, Jeff Yutzler <jeffy at imagemattersllc.com>
wrote:

> List,
> One of the things I appreciated about GeoJSON early on is that it is not
> rigid when it comes to properties in the features in a feature collection.
> The very first example in the spec shows different properties in different
> features. I have been able to take advantage of this design decision to
> simplify my own code and to avoid brittle feature schemas.
>
> I am finding that other code bases do not react well to this technique. It
> appears the way they work is that the first feature in a feature collection
> is used as a template. If any properties appear in subsequent features that
> are not in the template, the operation may fail. To work around these
> failures, I find myself doing immoral things to the features[1].
>

> While I don't expect any normative changes in the specification, I would
> like to know more about the expected behavior when applications see
> unexpected properties. If it were up to me, I would expect applications to
> accept any valid GeoJSON gracefully. However, I am willing to be convinced
> otherwise.
>
> Thanks,
> Jeff
>
> [1] https://github.com/venicegeo/geojson-go/commit/d2c793d82
> 09686951cc87f80c1c0aba5d64dfef9
>

Jeff,

I agree that applications should accept any valid GeoJSON gracefully,
whether it meets their expectations or not. It's widely recognized that
JSON is flexible like this. See http://www.json.org/fatfree.html, in which
Douglas Crockford asserts

> JSON is flexible. New fields can be added to existing structures without
obsoleting existing programs.

Or https://www.mnot.net/blog/2011/10/12/thinking_about_namespaces_in_json,
in which Mark Nottingham writes

> JSON has a head start in that it embodies the mustIgnore rule; if you put
extra data in a JSON document (for example, an extra property on an
object), all implementations will just ignore it.

In my view, applications that do not ignore extra properties are broken.
Excepting ones that are written specifically to detect whether features
have homogeneous properties. We had a discussion about in November 2015 and
several of us strenuously objected to any "mustIgnore" language in the
spec, which is why the spec doesn't recommend what you, I, and others
recognize to be a best practice.

How to tell applications what to expect in GeoJSON *before* reading it is
something we might try to solve together. I've seen firsthand that the use
of the first or first N features to diagnose a schema can fail
spectacularly.

-- 
Sean Gillies
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.geojson.org/pipermail/geojson-geojson.org/attachments/20160917/3d5f75de/attachment-0002.htm>