[OSM-talk] Users, contributors and developers

[80n]

On 4/27/07, Andy Robinson <Andy_J_Robinson at blueyonder.co.uk> wrote:
>
>
> Frederik Ramm wrote:
> >Sent: 27 April 2007 11:19 AM
> >To: Sebastian Spaeth
> >Cc: talk at openstreetmap.org
> >Subject: Re: [OSM-talk] Users, contributors and developers
> >
> >Hi,
> >
> >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*:
> >
> >highway=residential
> >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
> >mean.
> >
> >> 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.
> >
>
> Am I missing something here, if we allow the key column to take any format
> of tags separated by colons and the value column separated by semicolons
> do
> we not get all the flexibility we need without introducing unnecessary
> restriction?


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".

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?

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.

80n









Cheers
>
> Andy
>
> Andy Robinson
> Andy_J_Robinson at blueyonder.co.uk
>
>
> >Bye
> >Frederik
> >
> >--
> >Frederik Ramm  ##  eMail frederik at remote.org  ##  N49°00.09' E008°23.33'
> >
> >
> >
> >_______________________________________________
> >talk mailing list
> >talk at openstreetmap.org
> >http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
>
>
>
> _______________________________________________
> talk mailing list
> talk at openstreetmap.org
> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20070427/ffecb018/attachment.html>