[OSM-talk] Highway tagging in general around the world

[Lester Caine]

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 
language requested.

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