[Geojson] clarification on Feature id

[Sean Gillies]

Mateusz Loskot wrote:
> 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

My original use case for id was that it would be globally unique, like
atom:id, and support CRUD operations between clients and servers, like
the WFS feature id. OpenLayers, for example, has feature ids in its data
model, and could take advantage of server-provided ids.

An application like Fire Eagle doesn't need such an id because it has
only one location (hierarchy) per response. The user is the identifier.
The typical GIS applications, on the other hand, providing sets of
features from a single URL or service endpoint, will benefit from ids.

Sean