[GeoJSON] Aligning implementations

Allan Doyle adoyle at eogeo.org
Tue Apr 10 12:24:09 PDT 2007


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 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.

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 Doyle
+1.781.433.2695
adoyle at eogeo.org






More information about the GeoJSON mailing list