[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