<div dir="ltr">Folks,<div><br></div><div>I think I already know the answer to this, but I'm checking in just in case. </div><div><br></div><div>In reading the GeoJSON doc it says:</div><div><br></div><div>"<br clear="all">
<div><div>2. GeoJSON Objects</div><div>GeoJSON always consists of a single object. This object (referred to as the GeoJSON object below) represents a geometry, feature, or collection of features.</div><div><br></div><div>
The GeoJSON object may have any number of members (name/value pairs).</div></div><div>..."</div><div><br></div><div style>Can I construe this to mean that it is acceptable to extra fields not in the spec in GeoJSON objects under the assumption that baseline clients will just ignore them?</div>
<div style><br></div><div style>I'm thinking of adding schema, bounding box and other stuff info feature collections and I want to know if it is still legitimate to define it as type: FeatureCollection.</div><div style>
<br></div><div style>BTW, in case it hadn't been noted before the newly published Google Maps Engine API uses GeoJSON as the feature exchange format. </div><div style><br></div><div style>  <a href="https://developers.google.com/maps-engine/documentation">https://developers.google.com/maps-engine/documentation</a><br>
</div><div style><br></div><div style>PS. as you might guess I wish the CRS was preserved but I obviously lean towards paleolithic complexity, so I'm not objecting to a slim and trim specification.</div><div style><br>
</div><div style>Best regards,</div>-- <br>---------------------------------------+--------------------------------------<br>I set the clouds in motion - turn up   | Frank Warmerdam, <a href="mailto:warmerdam@pobox.com" target="_blank">warmerdam@pobox.com</a><br>
light and sound - activate the windows | <a href="http://pobox.com/~warmerdam" target="_blank">http://pobox.com/~warmerdam</a><br>and watch the world go round - Rush    | Geospatial Software Developer<br>
</div></div>