[OSM-talk] Users, contributors and developers

[Andy Robinson]

80n [mailto:80n80n at gmail.com] wrote:
>Sent: 27 April 2007 11:47 AM
>To: Andy Robinson
>Cc: Frederik Ramm; Sebastian Spaeth; talk at openstreetmap.org
>Subject: Re: [OSM-talk] Users, contributors and developers
>
>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?

I favour this route. Leave the database as it is and agree a general
structure basis via the collective wiki approach. It's worked fine doing it
that way till now.

Cheers

Andy

Andy Robinson
Andy_J_Robinson at blueyonder.co.uk

>
>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
><mailto: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
>
>