[OSM-talk] tagging and rendering

[Lester Caine]

elvin ibbotson wrote:
>> Typos in real words are easier to detect than a mistake in entering a 
>> number.
>>
> In the scenario I was suggesting numbers would only replace words for 
> type tags and users would never see the numbers but would just see words 
> (in their own language) mapped to/from numbers in the database by the 
> editor/viewer software. This somewhere between the ID numbers (set 
> purely by software) and latitude/longitude (which users do not enter 
> directly) and all the other tags, most of which (like name=) require 
> user direct input.

Some considerable time ago I tried to push the idea of using numeric types for 
the key map data so that translation is easy and since then I've been 
reconsidering how it could be done if I was going to run something locally.

highway, cycleway, waterway, railway, leisure and the like provide a top level 
  number and the 'approved' values provide sub-numbers. So that 'key' 1000001 
- for example - would be a highway:motorway. Just storing a single number for 
that data. We can maintain the free format by using 1000000 to indicate that 
there IS a string element to go with the tag.
All the 'way' tags would be 1xxssss, so 101 = cycleway, 102 = waterway etc.
Leisure/amenity/shop would become a 2xx series and so on.

0xx tags would then be used for additional data such as note, name, 
description, source ( with sub tags for approved sources ).

Reserving say 9xx for private tags that would only be used with perhaps a 
particular user ID so people could potentially use 9000000 for private notes .

Tools would then simply pick up a language file for their own translations of 
those numbers and create new tags or edit existing tags based on the list 
provided in their particular language set. If free form text is added then 
perhaps a warning could be posted about non-rendered data being added? Or even 
a switch to prevent free form data if not appropriate.

I am still looking at this from an internal storage point of view, and 
nowadays who actually TYPES the text for the main key entries - you just copy 
an existing item, or select from the list? The debate really is do we need to 
maintain a full 'XML' view of the data at all? By switching to a much more 
compact storage mechanism, data can be output as a full XML extract - perhaps 
even with a language switch for extracts in the target countries language - if 
required? But a compact - language agnostic - format would improve performance 
in a number of areas?

-- 
Lester Caine - G8HFL
-----------------------------
Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact
L.S.Caine Electronic Services - http://home.lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php