[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:
>> 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;
>> B) or by inspection: Features have a "geometry" member, 
>> FeatureCollections do not.
> 
> I do not like this. The reason to have type is simply to avoid this
> neccesity for context. Take the type value from the object, and dispatch
> to a function of the same name. I agree with your evaluation -- I just
> disagree with the conclusion that 'inference is good enough'.  
> 
>> Applications may opt to add "type" members to objects for convenience, 
>> but it should not be mandatory. Comments?
> 
> I agree with some conversation on the IRC channel that it should be all
> or nothing, as far as the spec is concerned. I just think it should be
> all.
> 
> Regards,

Chris, Tim, I'm going to take one more shot at winning you over.

For the sake of argument, let's say we have an application that accepts 
either features or collections as input and does something with them. 
It's written in pseudocode that looks almost exactly like Python. We 
have handlers registered for features and collections:

   handler['Feature'] = handleFeature
   handler['FeatureCollection'] = handleCollection

Your approach is to dispatch like:

   def handle_typed(data):
       # data is JSON deserialized into a hash
       return handler[data['type']](data)

Right? Here's mine:

   def handle_untyped(data):
       # data is JSON deserialized into a hash
       if data.has_key('members'):
           # has the exact signature of a feature collection
           return handler['FeatureCollection'](data)
       elif ['id', geometry', 'properties'] in data.keys():
           # has the exact signature of a feature
           return handler['Feature'](data)
       else:
           # Report that data is not a feature or collection

6 lines to your 2. Within a larger application, this isn't a significant 
savings. And mine handles the case where someone sends data like:

   {"type": "Bogus", ...}

Modifying handle_typed to do likewise adds 2 more lines

   def handle_typed(data):
       # data is JSON deserialized into a hash
       try:
           return handler[data['type']]
       except KeyError, e
           # Report something about no handler for the type

And now, say someone sends data with type=FeatureCollection but no "members"

   {"type": "FeatureCollection", "membranes": []}

You'll need to handle this too, either in handle_typed or in one of the 
other handlers, adding yet more code. In the end, code based on "type" 
isn't really going to be more concise or more elegant. You'll still need 
to verify that the input objects have all the members that they should 
have, and dodge wacky input data like this:

   {"type": "Feature", "members": [{"type": "Feature", ...}, ...]}

Keeping "type" means that there's potential for inconsistency between 
what the object *is* and what it is labelled as. In the end, what's 
important is whether the JSON objects have the members we want to act 
upon, not whether the objects have a label that says "Feature" or 
"FeatureCollection".

Cheers,
Sean