[OSM-dev] Essen / data model paper

Andy Robinson Andy_J_Robinson at blueyonder.co.uk
Wed May 2 17:29:45 BST 2007

Robert (Jamie) Munro wrote:
>Sent: 02 May 2007 4:33 PM
>To: dev
>Subject: Re: [OSM-dev] Essen / data model paper
>Hash: SHA1
>Frederik Ramm wrote:
>> Robert (Jamie) Munro wrote:
>> > For example, we should
>> > enforce key names & tag values where appropriate. Make list fairly easy
>> > to edit, but a two stage process - create a new key (or value for a
>> > restricted key) with a description (perhaps by making a special wiki
>> > page), then the backend should strictly enforce it.
>> You know that many in this project, are strongly opposed to this. I am
>> undecided; I see the merits of the open and the closed approach.
>I think what people are opposed to is trying to figure out a fixed tag
>structure in advance. They want to be able to add new tags when they
>want to, not have to wait for it to be approved in some way. That's why
>I don't want a closed approach in a strict sense, I want a hybrid
>approach where people can only use pre-defined tags, but they are able
>to go and pre-define them easily. Make the list fairly easy to edit, but
>strictly enforced.
>In the backend, I'd like to separate namespace:key/language for
>enforcement purposes, but in an OSM file they would be recombined to the
>current format. People would be allowed to register a namespace, which
>they can leave it, or they can define what keys are allowed in it. The
>global namespace would have only a restricted set of keys in it,
>corresponding to current accepted usage. We could have a global test:
>namespace which is open, and stuff can get converted from it to the
>global namespace when it is generally approved (or it could get dropped
>at any time).
>The list of languages would be static and based on the standards.

This is all very much what I had in mind for what I had called STAGS. STAGS
forms the structure from which you define your keys allowing anyone to
continue to define their own so long as it fits in with the basic structure.
Since I joined this project because of the flexibility of tagging I'm not
about to throw flexibility away and I saw any change in the tagging schema
as a way of providing a tool for better open tagging rather than anything



Andy Robinson
Andy_J_Robinson at blueyonder.co.uk

>Robert (Jamie) Munro
>Version: GnuPG v1.4.6 (Darwin)
>Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>dev mailing list
>dev at openstreetmap.org

More information about the dev mailing list