[OSM-talk] tagging and rendering

Juan Lucas Dominguez Rubio jldominguez at prodevelop.es
Fri May 9 14:56:53 BST 2008


Hi, 
the last line of your messge looks like a triple parallelism. Just to be precise: we are tagging 'autopistas' and 'autovias' as motorways, 'carreteras nacionales' as trunks and main regional roads as primary (for example, the roads linking Catalan cities to the Pyrenees)... just in case you are mapping something in Spain :-P
 
It's funny to see you say 'carretera general', that's old-fashion language, often heard in the rural Spain.
 
Cheers,
Lucas
 

________________________________

De: talk-bounces at openstreetmap.org en nombre de elvin ibbotson
Enviado el: vie 09/05/2008 11:27
Para: talk at openstreetmap.org
Asunto: [OSM-talk] tagging and rendering



Much debate centres around the way features are tagged and how they 
are rendered (for example recent discussion of golf course tagging, 
the term 'highway', rendering power lines,...) and it seems that much 
of this is inextricably involved with the OSM data itself. I  
wondered if it was time, while OSM is still relatively young and 
before it becomes too ossified and institutionalised, for the 
approach to be reviewed.

My own thoughts, for what they are worth, are that the data structure 
should be language/locale agnostic. For example, ways could have a 
numeric type field with, hypothetically, 10-19 being used for roads. 
In this scenario 11 might be a UK motorway, an Italian autostrada or 
an American interstate, while 19 might be a rough track (10 being 
reserved for some not-yet-invented super highway, after all some of 
us were here before motorways).

The editors used to input data (Potlatch, JOSM, whatever) would hide 
this structured data from the user and translate it to/from human 
language. One immediate advantage is that a German user could tag an 
autobahn rather than a motorway and global users would not have to 
use language clearly derived from the British motorway/trunk road/A/B 
(and little-known C) road classification system. Instead, local 
nomenclature would be mapped (no pun intended) to the underlying data 
structure by the local edition of the editor. Highways are an obvious 
example we are all familiar with, but the principle would apply to 
all feature types. Places of worship could be mapped as cathedrals, 
churches, chapels, etc in Britain or as mosques, temples, shrines, 
whatever in the east.

Rendering of the data is I think less tied up with the data itself, 
but again could be implemented differently by different map viewers. 
My paper road map of Ireland shows primary roads red in Ulster and 
green in Eire. Autbahns are green on my map of the Alps while 
autopistas are patriotically red and yellow on my Spanish map. Local 
or customisable viewers are possible with the current OSM but not, as 
far as I know, implemented yet, but the principle of separating the 
core data from the way it is described and depicted is, I believe, 
important.

Another aspect of the base data structure is that of level-of-detail 
(LoD) filtering. This is obviously done at present (villages and 
footpaths disappear as you zoom out) but is dictated by the people 
who code the viewers and is not, as far as I know, very well 
addressed in the API, so LoD filtering has to be done after data has 
been acquired, when it should be possible to specify LoD when 
requesting data. If LoD were considered in structuring the database 
it would be easy to filter data (eg. road types 10-13 only or for 
major ways of all types *0-*3). This is simpler for programming than 
clumsily using named tags (highway=motorway|trunk|primary) and would 
be invisible to users who might see autopista, autovia or carretera 
general.

elvin ibbotson

_______________________________________________
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/20080509/c9fabe43/attachment.html>


More information about the talk mailing list