[OSM-talk] Highway tagging in general around the world
lester at lsces.co.uk
Thu Aug 16 06:10:28 BST 2007
Alex Mauer wrote:
> Steve Coast wrote:
>> No I think that's super dumb. It's never going to work, ask the OGC.
>> If in the UK we have M, A and B roads. If in country X you have T, F
>> and D roads then just tag them that way.
> I think that's super dumb. To me, it doesn't make much sense to
> redesign a tagging scheme from scratch for each country just because the
> terms used are different.
> Where it's possible to tag "generically" I think it should be done, and
> some planning should be done to make this as easy as possible. Sometimes
> it's simply not possible, but I feel that only in those cases should
> there be country- or region-specific tags.
> If you want the system to know that a given road meets some UK standard
> that defines a motorway, then those specific tags could also come in
> handy. But for nearly every purpose, motorway, interstate, and autobahn
> have so much in common that distinguishing among them is not very useful.
This is more about the 'discussion' over language conversion than tags.
PERSONALLY I would still prefer to see some of the CORE tagging replaced with
a simple set of numeric tags, which can be 'translated' to local language
variations simply by selecting the correct language file. So that 'highway'
tag would become 1 to X and 1=motorway, 2=trunk, 3=primary, 4=secondary and 5
to 15 = tertiary, residential, service etc. 16,17,18,19 would be motorway_link
etc. ( Although the use of oneway and roundabout could probably provide THAT
variation? ) Religiously following the 'XML' rules can still be maintained,
with a schema that maps numbers to tag names, and a 'language' flag to select
which schema you want, but operationally, a standard relational database table
will return the same raw text as everyone expects - except translated for the
This does not prevent people 'inventing' new highway tags, they will just be
allocated the next highway tag number and automagically added to every
language set until a local translation is also created. HOWEVER I do STILL
feel that tags like highway should NOT be extensible in this way. The tags
like name or ref should be used for 'fine tuning' details that the core tag
does not cover, but the basic tree when translated into different languages
will probably allow many of the 'extras' to be covered simply by translating a
5 to 15 value to an appropriate local variation.
My sole language is English, but I don't think that a single language should
be forced on OSM *IF* it is intended to be world wide database. In addition,
the replacement of strings such as 'motorway' with an integer value will
vastly reduce the storage requirements and the size of plant dumps and also
make the provision of local language versions of josm and potlatch simple to
implement? The drop down list is just presented in the language requested.
To complete this tidy-up, oneway, bridge and roundabout should be rolled into
a second numeric tag. A roundabout IS oneway? SO a junction would have a
junction tag, which would say either roundabout or link (one way segment) and
level would indicate where a junction is on several levels. Links could also
indicate turnings that have limited access although they may have to be
allowed on single nodes which will not work as there is no 'direction' detail?
But roundabout tags on single nodes may need to know the countries driving
direction at some point in the future - to give 'first exit' or 'third exit'
directions correctly? But for closed ways, selecting 'junction' will flag
'roundabout', which open ways or 'link' - both inherently being one way. Since
these 'flags' are an inherent part of 'highway', they COULD simply be numbers
added to the base highway type. Use 1 to 15 as base type of highway, add 16
for link, 32 for roundabout, leaving '64' and '128' available for bridge and
tunnel. Confining the 'highway/junction' tags to a single character value?
Lester Caine - G8HFL
Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact
L.S.Caine Electronic Services - http://home.lsces.co.uk
MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/
Firebird - http://www.firebirdsql.org/index.php
More information about the talk