[OSM-dev] Essen / data model paper

Robert (Jamie) Munro rjmunro at arjam.net
Wed May 2 16:33:21 BST 2007

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.

Robert (Jamie) Munro

Version: GnuPG v1.4.6 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


More information about the dev mailing list