[Geojson] Solution for collection and member "type"

[Tim Schaub]

I'm interested to hear your motivation.

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.

> 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.

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.

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