<div dir="ltr">List,<div>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. </div><div><br></div><div>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].</div><div><br></div><div>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.</div><div><br></div><div>Thanks,</div><div>Jeff<div><br></div><div>[1] <a href="https://github.com/venicegeo/geojson-go/commit/d2c793d8209686951cc87f80c1c0aba5d64dfef9">https://github.com/venicegeo/geojson-go/commit/d2c793d8209686951cc87f80c1c0aba5d64dfef9</a></div>-- <br><div><div dir="ltr"><div><div dir="ltr"><div>Jeff Yutzler<br><a href="http://www.imagemattersllc.com/" target="_blank">Image Matters LLC</a><br>Mobile: <a href="tel:%28703%29%20981-8753" value="+17039818753" target="_blank">(703) 981-8753</a><br></div></div></div></div></div>
</div></div>