[Geojson] clarification on Feature id

Sean Gillies sgillies at frii.com
Mon Mar 17 10:45:04 PDT 2008

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.


More information about the GeoJSON mailing list