[OSM-talk] tagging and rendering

[elvin ibbotson]

On 9 May 2008, at 11:05, Dave Stubbs wrote:

>
> As far as I see it there is no difference between mapping 11=autobahn,
> and mapping motorway=autobahn.

I think you missed the point. At present we have highway=motorway and  
I believe a German user would need to use these words. What I suggest  
is that if Potlatch is used on a German computer the user would be  
presented with a menu of road types starting with 'autobahn' while I  
would see a menu starting with 'motorway', both mapping to a database  
field of (hypothetically) 11. I can't see how 'motorway=autobahn'  
helps with anything.

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

Fair point - I didn't think that one through until I'd clicked SEND.  
Best not talk about religion, eh?

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

Point missed again! I'm saying separate rendering from tagging.  
highway=red is exactly the opposite of what I'm suggesting.

>
> 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=BF0 
> FFFFFFFT
>

Yes. Anyone can put up their own viewer, but I imagine most use the  
one on the OSM site and that could (possibly) render the content  
differently according to the keyboard language or to some locale  
setting in its control panel

>
>>
>> Another aspect of the base data structure is that of level-of-detail
>> (LoD) filtering. ...
>>
>
> 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.

No problemo! Special viewers like the cycle map would simply apply  
their own filters. And with well-structured data a map viewer could  
even have settings (eg. cycle routes on/off) allowing it to be  
customised by the user, making a proliferation of specialist viewers  
unnecessary.

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

I never said it was going to be easy :-) I do think that LoD demands  
are something that should be considered in designing the data  
structure. (I also think elevational data should be well integrated,  
too, but that's another topic.)