[OSM-talk] Parking symbols: YUCK!

J.D. Schmidt jdsmobile at gmail.com
Sun Feb 24 14:16:02 GMT 2008


Lester Caine skrev:
> J.D. Schmidt wrote:
>> Lester Caine skrev:
>>
>>> Do you have to re-write the renderer every time someone comes up with 
>>> a new conflict?
>> Short answer : Yes.
>>
>> Long answer : The renderer operates on a subset of the data contained in 
>>  the DB. It is up to the operator of the renderer to extract and 
>> possibly massage that data into a format that the renderer can utilize.
>> It is not the place of the renderer to impose limitiations or rules into 
>> what is in the DB, since the the DB is/might/will be used for other 
>> tasks than just rendering maps.
>>
>> This is similar to the previous discussion this month, where someone 
>> wanted to impose limitations on what charactersets could be used for 
>> tagnames.
> 
> Should never have been discussed - Unicode has to be used even if there is an 
> arbitrary limit of English tag names - the content has to be unicode and 
> mixing that with anything else is simply crass.
> 
>> All together now, repeat this months mantra after me : "Implementing 
>> non-DB technical limitations and rules for content in the DB is bad, 
>> recommendations and smarter algorithms in renderers are good."
> 
> Bullshit.
> TAGGING as laid out in the wiki are all rules for content but as yet they do 
> not provide a consistent USABLE base once one moves away from the basic road 
> stuff. And even the base road stuff people are trying to change the rules!

Correction: Tagging as laid out in the wiki is NOT rules for content IN 
THE DB. Let me just repeat that: Tagging as laid out on the wiki in the 
"Mapfeatures" page is NOT rules governing the content in the DB.


They are recommendations, to be used if you'd like to see your content 
rendered by the current default rendering engines used on the OSM site.
Nothing more, nothing less.


> 
> See my other message about the area/node conflict. This problem arises 
> everywhere that node and area options exist for a tag and there needs to be 
> AGREEMENT on how the conflict is handled. Some people using different methods 
> of handling it for different tags is no use to anybody so lets decide ONE way 
> of handling the conflict and stick to it. Personally I have no particular 
> feeling anyway, but a logical means if identifying a SINGLE list of parking 
> places ( for example - but any node/area rag! ) is just common sense.
> 
> This is just a simple case of how do you identify a set of tags UNLESS there 
> is agreement about how a tag is used. *IF* we are going to allow both node and 
> area tags for the same item then we need to ensure that they ARE returning the 
> same data but some logical method of ensuring that the node and area returns a 
> CONSISTENT set of answers is essential otherwise we have anarchy.

There is NO agreement on tags used, and should NOT be any such agreement 
on tags used, since the DB is more akin to a wiki - if you can describe 
it within the framework of <k=name v=value/> then it can go into the DB 
for storage.
There IS an agreement on RECOMMENDATIONS of tags to be used IN THE SCOPE 
of rendering maps with the default rendering engines currently used by OSM.

Its then up to the rendering engines to visualize those tags according 
to whatever rules they use in their visualization attempts.

> 
> LOGICALLY - there should never have been a problem created. A POI element 
> should consist of a single entity which may have additional area information. 
> Even those tags that are currently only defined as 'node' in many cases WILL 
> be expanded to include area information at some point. So PLEASE can we have 
> some sensible method of identifying PAIRS of tags so we can THEN decide what 
> to do with them !!!
> 

It's still not a OSM DB problem. It's a problem to be solved by the 
rendering engines. Imposing non-DB technical limitations and rules to 
the data put into the DB, in order to please the rendering mechanism is 
fundamentally wrong.

Dutch





More information about the talk mailing list