[Geojson] Solution for collection and member "type"

[Sean Gillies]

Christopher Schmidt wrote:
> 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,

OK. I fold.

Sean