[OSM-talk] tagging and rendering

Jeffrey Martin dogshed at gmail.com
Fri May 9 15:09:39 BST 2008


The rendering should be separate from the data. Marking a hiking trail
as an autobahn so it will be a different color or be visible on higher
zoom levels I think we all agree is wrong.

Provided the data is correct, I don't see a problem with altering the
way data is collected and recorded to make it easier for renderers,
and those who program them and write the rendering rules.

----

I can see the attraction to the use of numbers for the values of the
highway tag. Having a new system that does not use terms that
have other meanings can force people to think about the OSM
definitions of the values. The UK centric terms have this effect
for me. I have to think about what motorway means for the US
or Korea in terms of the OSM definition because I have no competing
definition of the term motorway in my mind. For me motorway
only has an OSM definition.

People in countries with roads called motorways have a conflict
in their minds. If a section of a UK motorway is a single lane
dirt track then someone in the UK may be tempted to label
it as a motorway because it has a motorway sign. (That's just
a hyperbole to make a point. Let's keep discussions of the
highway tag itself on a separate thread.)

One solution to this psychology problem is to use terms
that do not have a local meaning. Numbering might be
one way to do that for some tags but not for others.

Another way to solve this psychological problem is to hide
the recorded data from the user. Something like presets
was suggested. Having different terms being used by the
person who writes the rendering rules and the person
collecting the data might cause other problems.

On Fri, May 9, 2008 at 6:27 PM, 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. 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
>



-- 
http://bowlad.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20080509/d5dc61f4/attachment.html>


More information about the talk mailing list