[Geojson] Solution for collection and member "type"

[Christopher Schmidt]

On Thu, Aug 02, 2007 at 12:52:03PM -0600, 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;

I strongly disagree that context is a sane way of determining things,
unless you only mean context within a single GeoJSON object (rather than
'this URL returns features', 'this url returns featurecollections'). In
which case, I think it's likely related strongly to b)...  

> B) or by inspection: Features have a "geometry" member, 
> FeatureCollections do not.

FeatureCollections *may* have a geometry member. Features *may* have a
'members' member. GeoJSON allows the addition of any other members you
want:

"2. The GeoJSON object may have any number of members (name/value pairs)."

With this in mind, inference by inspection is not trivially simple. I
believe that this, in and of itself, is enough to make removing the
'type' member silly.

And I am even more strongly against removing #2 from the spec.

Regards,
-- 
Christopher Schmidt
MetaCarta