[Geojson] clarification on Feature id

Mateusz Loskot mateusz at loskot.net
Mon Mar 17 10:25:18 PDT 2008

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.


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.

Mateusz Loskot

More information about the GeoJSON mailing list