[OSM-dev] Re: [OSM-talk] Map Features tagging question

Immanuel Scholz immanuel.scholz at gmx.de
Fri Jul 21 09:33:22 BST 2006


> *) refusing uploading of data for keys beginning with "mf:" when they not
> meet namespace rules, returning to clients error message such as
> "mf:highway tag must be unique" , "mf:toll must be yes or no" or "dog key
> not admited in the mf namespace.

Some technical notes if someone want to implement this:

If you (someone) want to *enforce* any structure in properties, I think
the best way to do this is using a proxy server which filters out any
wrong formatted data from the server and replies with error messages from
user data. Then clients speaking with the proxy instead of the osm server.
(Redirection to the proxy could be done by the core server and deduced
from parameters within the request, to avoid the burden of struggling with
multiple URL's)

This keeps the complexity of structure enforcement out of the current
server code (and proxy writer can compete against each other for the best
implementation ;). Such a proxy is usefull for many other tasks too.

IF someone REALLY want to integrate the enforcement code into the core
server, then I suggest moving the namespace out of the key name (as
suggested numerous times before) into the XML specification, where it is
faster to detect by the server (but then, the server HAS to know about
it). I strongly dislike this solution ;).

> The actual data should be copied if consistent to the namespace, leaving
> them unaltered in the "default" namespace.

To copy around some tags is definetly a job for a proxy, not for the core
server. (If you are speaking of transparently and constantly copying data
instead of a one-time shot).

> Users can continue to put what they want into osm, i think there is no
> freedom break limiting to add a mf:girlfriend tag instead of girlfriend.
> If some purist named m... f... was bored we can choose  __OSMF_MF as
> prefix :))))

mo... fu...? Hope we don't attract some perverts into OSM ;-D


Ciao, Imi

More information about the dev mailing list