[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