[OSM-talk] Users, contributors and developers

Frederik Ramm frederik at remote.org
Fri Apr 27 11:19:25 BST 2007


I'll try to summarize the namespace/subkey argument for the benefit  
of the "laymen" and using Spaetz's examples:

> 1) Bilangual place names have been mentioned:
> place=town,name:en=blah,name:welsh=blubb,name_default=welsh

This, for example, would not be possible if you decree the third  
column to be a "namespace". By defintion, a namespace puts the *key*  
into a context - meaning that a key in namespace A may have a  
completely different meaning from the same key in namespace B.

If you intend to separate e.g. English names from Welsh names (or  
metric units from imperial units), then a namespace doesn't help you,  
as you want to put the *value* into a context ("the name if this  
place is: in English, soandso; in Welsh, soandso; in ..."). This is  
what people often call a "subkey", a logical area below, not above  
the key. The major property of the road is that is has a name; this  
name comes in different flavours.

> 2) Renderer specific hints:
> renderName:osmarender=no

A clear case for namespaces (as is Nick Whiteleggs's "pathtype" tag  
in the "newforest" namespace, because one can easily imagine other  
namespaces where "pathtype" has wholly different meaning and set of  
allowable values than in the New Forest).

> 3) Introducing multiple restrictions on one road:
> restriction:1=noaccess,restriction_valid:1=6am-6pm
> restriction:2=oneway,restriction_valid:2=6pm-6am

This has nothing to do with namespaces. Neither "restriction" nor "1"  
and "2" in your example would make sensible namespaces. What you want  
here is a grouping of keys *per object*:

name=Brauer Blvd.
(restriction=noaccess restriction_valid=6am-6pm)
(restriction=oneway restriction_valid=6pm-6am)

Not a good example, as the oneway restriction proably doesn't vanish  
as long as the noaccess restriction is in place, but I know what you  

> How it's done in the backend and what's it
> called like should be of no concern to the end user...

What you seem want is a joker column that can take any number of  
forms and uses depending on the context ;-)

But I was just trying to summarise the argument. I am actually (by  
now) quite painless about it; we can just introduce a third column  
and see where we get. I suspect we will sooner or later have a  
conflict between the subkey and namespace worlds (i.e. someone  
creating a namespace for the new forest then finding out he needs  
names in different languages), and then we'll have either  
column1=newforest column2=name:en column3=something or  
column1=newforest:en column2=name column3=something or  
column1=newforest collumn2=name column3=en:something, and somehow it  
will sort itself out.


Frederik Ramm  ##  eMail frederik at remote.org  ##  N49°00.09' E008°23.33'

More information about the talk mailing list