[GeoJSON] Aligning implementations

[Sean Gillies]

Allan Doyle wrote:
> On Apr 10, 2007, at 14:31, Tim Schaub wrote:
> 
>> Chris Holmes wrote:
>>>>> [multiple geometries]
>>>>> what do I do?
>>>> {
>>>>      id: string,
>>>>      geometry: array,
>>>>      properties: object
>>>> }
>>>>
>>> Yeah, I don't really like that so much.  If you have multiple  
>>> geometries
>>> people will probably want names for them.  Ie which one's the  
>>> building
>>> and which one's the lot.  If you just have an array you don't know  
>>> which
>>> is which.
>> I don't like it either.  But if you want geometries to have arbitrary
>> names, then a geometry object would look like:
>>
>> {
>>      type: string,
>>      data: array,
>>      name: string
>> }
>>
>> and you could iterate through all your geometry objects in the
>> feature.geometry array to find the name you want.
>>
>> If you really want geometries to be keyed by arbitrary names, then
>> you'll have to iterate through all keys to get all geometries anyway.
>>
>> Again, I don't like this, but I think it is preferable to iterating
>> through all the keys of the properties object and testing each  
>> value to
>> see whether or not it is a geometry.  What if I want to name my  
>> geometry
>> link or title?  Are those forbidden names for geometry because they  
>> are
>> also optional properties?
> 
> Rats. Now you have me thinking. And it's making my head hurt.
> 
> It seems to me that an "alternate" geometry is really a (sub)feature  
> in disguise since it has a name that's probably overloaded with  
> semantics. You're not using "lot" and "building" in your example  
> because you mean "office" and "desk". So how are "lot" and "building"  
> not features? They have a geometry, they have a name property, and  
> they have an implied id - foo.geometry[n].
> 

That's a cool insight.

> That leads me to think we could define feature as { id, geometry,  
> properties } where a property's value can be a feature or an array of  
> features. It's all just strings anyway.
> 
> Furthermore, what semantics do we attach to 'id', and what semantics  
> do we attach to 'properties'? Is 'id' the (RESTful) path back to the  
> feature? Is it unique within the JSON stream? Is it a uuid?
> I don't think we're requiring 'id' to be numeric, or to even be  
> unique. I could have a feature whose id is a GeoJSON representation  
> of a feature.
> 

String is my preference. Unique to the origin server at a minimum.

> And the properties? Is 'title' the thing I label my rendered geometry  
> with? Doest that mean we require a 'title'? What if there's a  
> property called 'income'? Do I render all incomes below a certain  
> number in red?
> 
> Maybe what it comes down to is that what we really need to define is  
> the string that can be used as the value of any key whose name is  
> 'geometry', and everything else is fair game.
> 
> That would lead to the following definition:
> 
> 1. A feature is a dictionary containing a 'geometry' keyword, and  
> that keyword must follow the JSON defined by us.
> 2. A feature may have any other keywords.
> 
> This would lead to interoperable access to geometries, but nothing  
> else. So what else do we want to have be interoperable? Looking at  
> Sean's http://zcologia.com/news/430/feature-demo/ it seems to me that  
> he's got some Atom-ish things in there, but he's not really  
> explicitly stating that. The last thing we want to do is develop yet  
> another random namespace of terms.
> 
> 
> 	Allan
> 

Allan, it may be a free-for-all in the properties attribute, and that 
would be just fine. Remember, JSON is about simple data structures, not 
about documents. If an application needs strict semantics and hierarchy, 
XML is a much better choice.

Sean