Principal members of types must not be used in other types.

[sgillies]

List discussion: https://mailarchive.ietf.org/arch/msg/geojson/eVZbpxrORyt5koH6P7QjdcfcRHE.

[tschaub]

Looks good to me.

[mpdaly]

👍

[sgillies]

@tschaub @mpdaly thanks for the quick feedback! I've got one more question I'm going to ask in the email thread.

[sgillies]

In 45814c3, I attempt to do what I said I would on the list. @dret @sdrees does it look right to you? I think it needs better wording. I'm open to suggestions.

Allan,

That's not disallowed, but I'm working on text that makes it clear that
since "foo" is a foreign property, GeoJSON semantics do not apply under it.
It's not a Feature object, no matter that it is structured like one.
On Feb 12, 2016 12:43 PM, "Allan Doyle" xxxx@xxxx wrote:

Are we disallowing nesting a GeoJSON object inside another? Here's a
GeoJSON LineString called "foo" embedded in a Feature.

{ "type": "Feature",
"geometry": {
"type": "Polygon",
"coordinates": [
[ [100.0, 0.0], [101.0, 0.0], [101.0, 1.0],
[100.0, 1.0], [100.0, 0.0] ]
]
},
"properties": {
"prop0": "value0",
"prop1": {"this": "that"},
"foo": {
"type": "Feature",
"geometry": {
"type": "LineString",
"coordinates": [
[102.0, 0.0], [103.0, 1.0], [104.0, 0.0], [105.0, 1.0]
]
},
"properties": {
"prop0": "value0",
"prop1": 0.0
}
}
}
}

[dret]

what about changing the heading from "Semantics of GeoJSON members and types are not extensible" to "Semantics of GeoJSON members and types are not changeable"? after all, it is possible to extend semantics with additional members, and that is fine, as long as none of the basic GeoJSON semantics are changed.

[sgillies]

With the exception of @dret's suggestion above (which I like), this is good to go. I'll merge later today if there are no objections.

[mpdaly]

I'm feeling bad now that we've banned FeatureCollection from having a "properties" member, but not bad enough to stand in the way of progress.