On 4/27/07, <b class="gmail_sendername">Andy Robinson</b> <<a href="mailto:Andy_J_Robinson@blueyonder.co.uk">Andy_J_Robinson@blueyonder.co.uk</a>> wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>Frederik Ramm wrote:<br>>Sent: 27 April 2007 11:19 AM<br>>To: Sebastian Spaeth<br>>Cc: <a href="mailto:talk@openstreetmap.org">talk@openstreetmap.org</a><br>>Subject: Re: [OSM-talk] Users, contributors and developers
<br>><br>>Hi,<br>><br>>I'll try to summarize the namespace/subkey argument for the benefit<br>>of the "laymen" and using Spaetz's examples:<br>><br>>> 1) Bilangual place names have been mentioned:
<br>>> place=town,name:en=blah,name:welsh=blubb,name_default=welsh<br>><br>>This, for example, would not be possible if you decree the third<br>>column to be a "namespace". By defintion, a namespace puts the *key*
<br>>into a context - meaning that a key in namespace A may have a<br>>completely different meaning from the same key in namespace B.<br>><br>>If you intend to separate e.g. English names from Welsh names (or<br>
>metric units from imperial units), then a namespace doesn't help you,<br>>as you want to put the *value* into a context ("the name if this<br>>place is: in English, soandso; in Welsh, soandso; in ..."). This is
<br>>what people often call a "subkey", a logical area below, not above<br>>the key. The major property of the road is that is has a name; this<br>>name comes in different flavours.<br>><br>>> 2) Renderer specific hints:
<br>>> renderName:osmarender=no<br>><br>>A clear case for namespaces (as is Nick Whiteleggs's "pathtype" tag<br>>in the "newforest" namespace, because one can easily imagine other<br>
>namespaces where "pathtype" has wholly different meaning and set of<br>>allowable values than in the New Forest).<br>><br>>> 3) Introducing multiple restrictions on one road:<br>>> restriction:1=noaccess,restriction_valid:1=6am-6pm
<br>>> restriction:2=oneway,restriction_valid:2=6pm-6am<br>><br>>This has nothing to do with namespaces. Neither "restriction" nor "1"<br>>and "2" in your example would make sensible namespaces. What you want
<br>>here is a grouping of keys *per object*:<br>><br>>highway=residential<br>>name=Brauer Blvd.<br>>(restriction=noaccess restriction_valid=6am-6pm)<br>>(restriction=oneway restriction_valid=6pm-6am)<br>
><br>>Not a good example, as the oneway restriction proably doesn't vanish<br>>as long as the noaccess restriction is in place, but I know what you<br>>mean.<br>><br>>> How it's done in the backend and what's it
<br>>> called like should be of no concern to the end user...<br>><br>>What you seem want is a joker column that can take any number of<br>>forms and uses depending on the context ;-)<br>><br>><br>>But I was just trying to summarise the argument. I am actually (by
<br>>now) quite painless about it; we can just introduce a third column<br>>and see where we get. I suspect we will sooner or later have a<br>>conflict between the subkey and namespace worlds (i.e. someone<br>>creating a namespace for the new forest then finding out he needs
<br>>names in different languages), and then we'll have either<br>>column1=newforest column2=name:en column3=something or<br>>column1=newforest:en column2=name column3=something or<br>>column1=newforest collumn2=name column3=en:something, and somehow it
<br>>will sort itself out.<br>><br><br>Am I missing something here, if we allow the key column to take any format<br>of tags separated by colons and the value column separated by semicolons do<br>we not get all the flexibility we need without introducing unnecessary
<br>restriction?</blockquote><div><br>There is potential ambiguity because name:de could mean "the de variant of the name tag in the default/unrestricted namespace" or it could mean "the de tag in the name: namespace".
<br><br>A third column would formalise this (and involve a fair bit of work on the server, editors and renderers) or we could just declare that name:de means "the de tag in the name: namespace" and find some otherway of representing language variants.  Perhaps name/de?
<br><br>IMHO the developers have more important and pressing issues to work on than fixing a problem that was already dealt with by the community over a year ago.<br><br>80n<br><br><br><br><br><br><br><br> </div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Cheers<br><br>Andy<br><br>Andy Robinson<br><a href="mailto:Andy_J_Robinson@blueyonder.co.uk">Andy_J_Robinson@blueyonder.co.uk</a><br><br><br>>Bye<br>>Frederik<br>><br>>--<br>>Frederik Ramm  ##  eMail <a href="mailto:frederik@remote.org">
frederik@remote.org</a>  ##  N49°00.09' E008°23.33'<br>><br>><br>><br>>_______________________________________________<br>>talk mailing list<br>><a href="mailto:talk@openstreetmap.org">talk@openstreetmap.org
</a><br>><a href="http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk">http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk</a><br><br><br><br>_______________________________________________<br>talk mailing list
<br><a href="mailto:talk@openstreetmap.org">talk@openstreetmap.org</a><br><a href="http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk">http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk</a><br></blockquote>
</div><br>