Closed tmcw closed 10 years ago
@tmcw My take is that it should be a string, as with xml:id and gml:id, but not because of those standards. In a different and maybe better world FeatureCollection.features would be a JSON object, not an array, and Features would have string keys as natural identifiers. Sticking to string ids seems like a better fit with JSON and the web in general.
Definitely a hole in the spec. Do you ever see non-string ids out there?
In a different and maybe better world FeatureCollection.features would be a JSON object, not an array, and Features would have string keys as natural identifiers.
This means whomever generates the serialization is responsible for picking a (permanent) identifier for features. Users should be able to serialize newly generated features that will be assigned permanent identifiers farther down the pipe.
Do you ever see non-string ids out there?
I've only seen string ids, and only seen the id
property used in the wild once or twice. Strings definitely seem like the right way to go, though the discussion about the I-D definitely lays out a more detailed / thought-through pragmatic path.
Hello there id property! http://www.geojson.org/geojson-spec.html#feature-objects
@sgillies I hadn't noticed this lil one before - since the spec doesn't specify its type, can this be an object/array/string/number etc?