[Geojson] clarification on Feature id

[Mateusz Loskot]

Allan Doyle wrote:
> On Mar 15, 2008, at 7:52 PM, Mateusz Loskot wrote:
> 
>> Keith Jenkins wrote:
>>> On Sat, Mar 15, 2008 at 5:54 PM, Christopher Schmidt
>>> <crschmidt at metacarta.com> wrote:
>>>> "id" isn't part of the spec. So, it's definitely not required,  
>>>> though it
>>>> probably makes sense to put it there, and most implementations  
>>>> that I've
>>>> seen that have such a thing will do so. However, I've always seen  
>>>> it as
>>>> reasonably common sense, and not worked it into the spec (though I
>>>> wouldn't have a problem with making it recommended).
>>> I think it makes sense to recommend it, and if so, also to mention it
>>> in the spec as a special element that can exist directly within the
>>> Feature object, rather than being relegated to the properties object.
>> I agree with Keith. I found it a little confusing when I was
>> implementing OGR driver for GeoJSON. The "id" is used in the examples
>> but it isn't mentioned in the spec.
> 
> I agree that it may be confusing to have it in the examples the way  
> they are. But unless there's some agreement on the semantics of an id,  
> I'm not sure it makes sense to define it.

I'm not sure neither :-)

> Would it have to be unique?  

I'm quite sure GeoJSON should not be that specific and it better defines 
it a "implementation specific".

> What about systems that don't have a concept of feature id?
> What if it's unique to the server but not to the client? etc. etc.

Good questions. So, if the concept of id is unspecified, why not to move 
it completely under the "properties" and leave its definition and 
meaning to client?

> I like examples that show how to mix spec and non-spec things  
> together, since that helps me to understand what's legal and what's  
> not, but maybe the main examples should not use id.

I agree, however I'd prefer to see it specified that it's correct to 
inject and mix non-GeoJSON objects/properties on every level of
GeoJSON tree.

This way we avoid confusions and have this aspect well explained.

Greetings
-- 
Mateusz Loskot
http://mateusz.loskot.net