[Geojson] clarification on Feature id

[Sean Gillies]

Mateusz Loskot wrote:
> Sean Gillies wrote:
>> 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.
> 
> Sean,
> 
> Yes this is one of the most common use case of feature id. My 
> understanding is that most of users working with table/tree-like data 
> sets expect to be able to uniquely identify a feature within a dataset 
> or at least within single document (subset of the original dataset).
> Thus I'd vote for making GeoJSON more explicit about handling feature 
> id, even if GeoJSON does not intent to handle it.
> 
> Greetings

Let's at least recommend a feature "id", though I don't think it would
be a difficult requirement. It would be unfortunate if people assigned
IDs in several different ways. As Christopher pointed out, they don't
need to be globally unique.

Sean