[OSM-talk] Parking symbols: YUCK!

Sven Grüner sven at schunterscouts.de
Sun Feb 24 20:25:09 GMT 2008


J.D. Schmidt schrieb:
>> 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.

I'm not talking about certain uses, I'm talking about encoding and
decoding of information using certain keys. That applies to all kind of
geodata whether it's stored in a papermap, a database or a GPX-file.
We encode the geodata we survey on the street when entering it into the
DB and we decode it again when we use it, regardless for what we use it.
The data stored in the osm-DB isn't self-explaining when it says <tag
k="highway" v="residential"/>. It would be self-explaining if we would
tag things like
<tag k="description" v="A tarmac-road with a lane in each direction and
side-walks on both sides, mainly used by people living in the houses on
this street, about 5m wide."/>
That would make something like map-features obsolete (sure, an extreme
example but highway=residential could also be a street where people live
on the street, ie. the homeless or a road *leading* to a residential
area (since it's a HIGHway))

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

Sorry, I used the wrong term.
In my terms a map stores geodata, ie. is geodata. Whether that geodata
is in a strict GIS-sheme on a HD or colorful lines on some paper doesn't
make a difference in the first place. When I know which
tranformation/encoding was used for reality->geodata I can read both.

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

I'm trying to. But rendering a map is just another way of bringing the
data in a different shape, which still is encoded. Stylesheets are
patient, you can draw every highway=primary with red lines. But when you
don't know what highway=primary means you aren't any smarter with those
red lines. At least here in Germany they are (like most roads) not red
but grey-black (because of the tarmac), neither do they have big labels
everywhere saying *primary*.
Ie. that tag doesn't describe the road, it's explanation on map features
does.

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

That's actually pretty close to my example above and pretty far apart
form what the DB looks like. Still might someone reading it expect a
tree that's urinating because of some disease which also colors it's
leaves yellow/brown. Maybe that tree secretes 200ml of beer each day ;-)

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

Sure, you can use the DB to store whatever geodata you like and I'm fine
with it. You can use it just like a scrap of paper on your desk. But
that's nothing this community will bother about or what we run a wiki
for. That happens because we want to create geodata that's valuable to
everybody and not only to the mapper himself.

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

But those city planners would have much less scope of interpretation if
you described your tag on something like map features.

> 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 that's not what we're doing, describing geodata within that scope.
Instead we're using keywords to label things and those keywords are
described in map features.

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

It's important for the whole process of gathering and using geodata. Map
features isn't there to suggest rendering for certain tags. It's there
to define what those tags resemble.

Puh, I hope made my point.
No matter how you use the data we gather, you better should know what
some tag means. "Map features" closes the gap between the physical
object and how it's stored in OSM. It's some kind of translation table
and without it you can still draw shiny maps or make fancy statistics
but you don't know what they show. You can *guess* with some knowledge
of the english language and British culture but you will never *know*
for sure.

regards, Sven




More information about the talk mailing list