[OSM-talk] tagging and rendering

[Dave Stubbs]

On Fri, May 9, 2008 at 10:27 AM, elvin ibbotson
<elvin.ibbotson at poco.org.uk> wrote:
> 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.


What makes this not possible with named tags like we have at present?
As far as I see it there is no difference between mapping 11=autobahn,
and mapping motorway=autobahn. As long as we have enough highway
grades to cover the uses I don't think just numbering stuff will
actually improve anything. You could already build an editor that
remaps the highway tags to a local equivalent (it would probably be
best to do it via "presets" so as not to confuse people).


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

Um... except that Britain has quite a lot of mosques, temples and
shrines. These are different things, not the same things named
differently.


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


This is why we don't have (and have resisted) tags such as highway=red.

People have done customised renderings... see Freemap Slovakia for example:
http://www.freemap.sk/?lang=en&zoom=8&lat=48.49281826990847&lon=18.326709281821315&layers=BF0FFFFFFFT


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

It's true that filtering highways based on a purely numeric system
would be simpler than having to maintain a comprehensive list of
highway type names, but this only really covers the "standard" map
display where you count motorways as the most important thing on the
map. If you consider something like the cycle map where we have ncn as
the things that should show up at zoom level 6 instead, then we have
to apply different rules.
So we only really gain something if the LoD demands happen to coincide
with the data model you define.

LoD is generally a more complicated problem that requires you to
actually define a whole array of features, and mechanisms for
simplification.


Dave