[Geojson] Solution for collection and member "type"
Sean Gillies
sgillies at frii.com
Thu Aug 2 15:15:41 PDT 2007
Tim Schaub wrote:
> I'm interested to hear your motivation.
>
My motivation is to keep the spec as simple as possible. Omit needless
members.
> Sean Gillies wrote:
>> I propose we make the "type" member for Features and FeatureCollections
>> *optional*.
>>
>> Geometries need to specify geometry type because multipoints and
>> linestrings have otherwise identical representations. The "type" is
>> needed here, and it is the "geometry type".
>>
>> Features and FeatureCollections do not need a "type" member. Instances
>> of these objects can be differentiated from objects of other kinds
>> (including Geometries) entirely by
>>
>> A) context: Geometries are contained by Features which are contained by
>> FeatureCollections;
>
> The root GeoJSON object doesn't have any such context. Looks like
> you're talking about the context of geometry or feature - if your parser
> gets to the point where it has made sense of a geometry, it must have
> already made sense of the feature. So, I'm confused how context helps
> here - unless you're not talking about parsing.
>
Everything has a context. I'm planning to make JSON collections and
features available from a web service. /places.json will *always* return
collections, and URLs like /places/1.json will *always* return features.
There's the context. A web service that returns collections or features
unpredictably (requiring a check of the "type" on the root object) is of
no use.
>> B) or by inspection: Features have a "geometry" member,
>> FeatureCollections do not.
>
> Ok, if you are talking about parsing, you're suggesting that the test to
> determine the object type for a feature is different than the test to
> determine the object type for a geometry.
>
Yes I am.
> In pseudo-code, this means that you determine the type of a geometry
> object by accessing
>
> object.type
>
> To determine the type of a feature object, you do the equivalent of
>
> if(object.geometry) ...
>
> I'm not claiming that the latter is particularly onerous. Just don't
> see any reason at all to require that all clients test for feature type
> objects this way.
>
I actually see myself doing that second test almost never. I'm going to
rely on context instead, and I think that's the best approach for all of us.
> Again, mostly interested in hearing your motivation - as I don't know
> what the "problem" is that your "solution" proposes to address. If it
> is just "type can be inferred", then is it ridiculous to suggest that
> type not be required for points, since they are the only object type
> that has a components array where each element is a number?
>
> Tim
Tim, Feature and FeatureCollection "type" is needless. Geometries need
"type" to distinguish between linestrings and multipoints. Once type is
needed here, we pretty much have to apply it across all geometries for
sanity sake.
Sean
More information about the GeoJSON
mailing list