[OSM-talk] Parking symbols: YUCK!

J.D. Schmidt jdsmobile at gmail.com
Sun Feb 24 18:56:13 GMT 2008


Sven Grüner skrev:
> J.D. Schmidt schrieb:
>>> 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.
> 
> True.
> I don't understand why it's so fashionable on this list to play down the
> importance of "Map features". Without that page all those "80GB of
> cryptic XML would be pretty useless.

Thats again because you look at the DB and the usage of the data 
contained therein as one entity that defines OSM.

If you on the other hand look at the DB and the data contained therein 
as one entity and the USAGE of the data in the DB as a seperate entity, 
you get a more correct view of the state of our wonderfull hutsputz of 
geodata and geodata usage.

  But that's nothing bad or something
> we should encounter, that just the nature of any map, whether it's
> stored in a DB or printed on colorful paper.

We (OSM) do not store a map in a DB. We store geodata.

> 
> A map is an abstract description of the landscape, that's what makes it
> different from an aerial or plat. Someone making that description uses
> certain symbols or certain code for certain features. Someone who uses
> that description needs to know what every symbol/code resembles. On a
> paper map that's done by the map keys which tell you whether those blue
> lines are motorways, railways or maybe rivers, for OSM-data "Map
> features" tell you.
> 
> Anybody can enter anything into the DB, we can't change that, we don't
> want to change that and we are all aware of that. But when I (and most
> other mappers as well) enter something in the DB I want other people to
> know what it stands for in reality. I could use some crude tags only I
> know, but what's then the point in making it accessible for the whole world.

Again, look at the visualization of the data as a seperate entity - 
related to, and an important part of OSM, but not the defining measure 
of OSM.

An example (graphic to fit my reputation ofcourse.. You have been duly 
warned ;) ) :
If I decided to map all the trees I have taking a leak up at on the way 
home from drinking bouts the last couple of years, I can do so. I'll 
just tag it with 
<k="urinated_tree_were_the_leaves_has_become_yellow_brownish_in_colour" 
v="200 ml used and processed beer"/>.

I could even tag the same tree multiple times, depending on whether I 
took the piss at the north, east, west, or south side of the tree. And I 
could even use a different tagname such as 
<k="Urinerede_Træer_som_har_blade_med_gul_brunlig_kulør" v="200 ml brugt 
øl"> without any problems.

This points out the wiki-like outlook on our DB. The tag and data has 
only mildly interest for anybody else, but it might have real value for 
me. I could be the type that tends to loose my keys everytime I take a 
leak in toxicated condition, and now I have the possibilty to see where 
I have been, and go look for them. Or maybe I'm making a map showing 
which trees not to sit under during summer.

Whatever the reason, it's geodata, and valid to go into the DB or the 
80GB of cryptic XML as you called it. It might be useless for anybody 
else, but it wouldn't be to me. AND it could become usefull for someone 
else later on (urologists researching maximum distance intoxicated 
people can go between leaks, city planners looking for information on 
best placement of public restrooms, etc, etc).

The other entity - visualization of the data in the OSM DB, takes a 
subset of the data in the DB, and masssages it into a format that the 
rendering mechanism can utilize. I.E. Mapnik imports the OSM data into a 
postgres DB according to the rules it needs, and then renders the 
imported data from that mapnik specific DB.
Osmarender downloads the data and post-process it into SVG compliant XML 
according to the rules it needs, then renders it via Batik/Inkscape.
Kosmos and all the other rendering mechanisms utilizing OSM data at the 
moment, does similar things with the extracted OSM data for the areas 
the user wants visualized - extract an area from the DB, massage it 
(postprocess, import to own formatted DB, etc, etc), then visualize it 
from the postprocessed data.

So as I said before, its not the rendering mechanism that should define 
what goes into the OSM DB. At the most basic level, if it is geodata, 
and can be described within the scope of <k=name v=value> it IS valid 
for inclusion in the OSM database, no matter how "useless" it would 
appear to other users.

> 
> And things like the cycle map would definitely not exist without some
> kind of explanation of the relevant tage in the wiki. Without this
> translation/documentation ("ncn=xyz means this way is part of a route
> that...") there wouldn't be all those tags in the DB. I'm sure Andy
> didn't think, well today I'm gonna render abc=xyz, maybe there are some
> mappers who describe their cycleroutes just that way.
> 
> Without "Map features" OSM is like an undocumented command-line
> programm: To be certain about all it's capabilities you'd need to read
> every single line of code. And reading planet.osm might take a while...

The Mapfeatures page on the wiki is an important part, but only for "the 
second entity" - the visualization of the data. Thats why it is called 
"MAP features".
If you want your geodata rendered with the stylesheets currently 
deployed for mapnik and Osmarender, then you should use those tags on 
that wiki page*, but nothing stops anybody from making their own 
stylesheets to render the data in what ever way they want to render it, 
nor from only rendering specific data tagged with specific tags, in 
whatever way they want to visualize it.




Dutch





More information about the talk mailing list