[Geojson] type

[Tim Schaub]

Ok, at risk of slowing things down again, I thought I'd air this 
suggestion again.

Sean was opposed to using a member named "type" because it wasn't 
strictly necessary for parsing.  Further, I think it gave him trouble 
because it reeked of "distributed objects all over again."  I'll let him 
speak for himself if he still cares to elaborate.

I'm not troubled by the member named "type."  However, I'm not opposed 
to taking it out.  Either way, I'm comfortable that we are distributing 
JSON objects (call them data structures if you prefer) and not trying to 
impose a framework for communication between objects.

So, is there any interest in removing the "type" member?

If so, it would mean restricting the GeoJSON vocabulary a bit. 
Specifically, you couldn't use members named "geometry" or "members" 
willy-nilly.

If we're going to go that far, I'd propose we go a bit further and get 
rid of the "members" member.  If we don't have type, I'd like to see 
FeatureCollection have a "features" member (instead of "members") and 
GeometryCollection have a "geometries" member (again, instead of "members").

I know this is late in the game to make a big change, but I thought it 
would be worth asking.

Tim


In case it's not clear, here's the alternative proposal (which I 
actually like better than the current draft):

Geometries
----------
These stay the same.  All geometries have a type member with a value 
corresponding the the geometry type.
e.g.
{
     "type": string,
     "coordinates": array
}

Features
--------
Remove the type member.
e.g.
{
     "geometry": object,
     "properties": object
}

Geometry Collections
--------------------
Remove the type member.  Use "geometries" instead of "members."
e.g.
{
     "geometries": array
}

Feature Collections
-------------------
Remove the type member.  Use "features" instead of "members."
e.g.
{
     "features": array
}