You are not logged in.
- Topics: Active | Unanswered
Announcement
Please create new topics on the new site at community.openstreetmap.org. We expect the migration of data will take a few weeks, you can follow its progress here.***
#26 2017-04-03 08:15:05
- geri-oc
- Member

- From: Sachsen
- Registered: 2011-03-21
- Posts: 5,055
- Website
Re: Falsches Kartieren von straßenbegleitenden Parkflächen
Das ist eine sehr eingeschränkte Sichtweise. Das berücksichtigt weder das Ziel von OSM noch dass die Daten dargestellt und ausgewertet werden müssen; die Daten sollen ja auch verwendet werden, nicht nur eingetragen.
Willkommen bei OpenStreetMap, dem Projekt, welches freie geografische Daten erstellt und bereitstellt. Aus diesen Daten können Straßen-, Wander- oder Fahrradkarten, Routenplaner oder andere wissenswerte Informationen erstellt werden.
Offline
#27 2017-04-03 11:24:06
- Thoschi
- Member
- Registered: 2013-07-19
- Posts: 767
Re: Falsches Kartieren von straßenbegleitenden Parkflächen
Ich möchte noch mal auf das Problem aufmerksam machen, dass OsmAnd bei Erreichung des Ziels eine Parkplatzliste anzeigt. Wenn an der Straße nun jeder Stellplatz mit amenity=parking einzeln eingetragen ist, sind das sehr viele Parkplätze, welche in der Liste von OsmAnd stehen, welche man dann aus dem Auto auch sowieso direkt sieht. Die Funktion von OsmAnd ist ja sinnvoll, aber sie wird kaputt gemacht, wenn man straßenbegleitende Stellflächen einzeln mit amenity=parking taggt.
Auch wenn ich selbst OsmAnd verwende, es ist aber nur EINE Routingsoftware/-app. Und noch steht meines Wissens der Grundsatz, dass wir nicht für Renderer mappen, ich versuche es mal so zu präzisieren: zumindest nicht für die individuellen Bedürfnisse EINES Renderers.
Von daher kann ich dies als Grund nicht akzeptieren (auch wenn ich parking:lane selbst häufig tagge).
Offline
#28 2017-04-04 20:44:33
- pyram
- Member
- Registered: 2012-06-16
- Posts: 1,509
Re: Falsches Kartieren von straßenbegleitenden Parkflächen
Beim area:highway-Tagging soll die Straßenfläche ja den Way nicht ersetzen, sondern zusätzlich eingetragen werden. So würde ich das auch mit dem Parkstreifen handhaben:
...
Wenn unser Ziel ist, das Flächenmapping und die Semantik unter einen Hut zu bringen, wäre das zumindest mal eine eindeutig auswertbare Lösung, die zudem auch rückwärtskompatibel ist (d.h. man kann die Flächen ignorieren und weiter nur den Way auswerten, ohne dass Information verloren geht). Damit könnte ich mich durchaus anfreunden.
Danke. Man könnte fast sagen: Zwingend logisch.
Jeder, der die Daten nutzen will, sollte auf >einfache Weise< unterscheiden können, ob es sich um einen Parkplatz handelt (wie auf "klassichen Karten" sichtbar) - oder nur um irgendeine sonstige Abstellmöglichkeit von Autos am Straßenrand. Letztere könnte man dann ja wie einen Parkplatz auf der Hauptkarte gelb darstellen, aber das "P" weglassen. Nicht, weil ich das bräuchte oder schön fände, sondern weil viele letztendlich doch nur für den Renderer mappen :-(
Irgendwie erinnert mich das an den Bedeutungswandel von natural=tree (für vormals landschaftsprägende Bäume, wie sie in topographischen Karten von Bedeutung waren). In OSM-generierten Topo-Karten musste man wieder "bei Null" anfangen und warten, bis natural=tree mit Zusatztags wieder ausreichend genau einen >bedeutenden< Baum beschrieb.
Wird das jetzt bei Parkplätzen genauso? Dass sehr viele Parkplätze gar nicht öffentlich nutzbar sind (Anwohnerparkplätze/Firmenparkplätze etc.) macht hier die OSM-Daten ohnehin nur sehr beschränkt nutzbar (persönliche leidvolle Erfahrung). Und dass mann innerorts am Straßenrand parken darf ist keine wirklich hilfreiche Information - insbesondere, da dort in den Städten meistens ohnehin kein Parkplatz frei ist ;-)
Offline
#29 2017-04-05 14:23:25
- Graf Westerholt
- Member
- Registered: 2017-01-27
- Posts: 92
Re: Falsches Kartieren von straßenbegleitenden Parkflächen
WIKI wrote:Willkommen bei OpenStreetMap, dem Projekt, welches freie geografische Daten erstellt und bereitstellt. Aus diesen Daten können Straßen-, Wander- oder Fahrradkarten, Routenplaner oder andere wissenswerte Informationen erstellt werden.
Wenn man Daten so einträgt, dass die Verwendung nicht mehr möglich ist, also die Daten nicht sinnvoll verwendet werden kann, dann ist das nicht zielführend. Damit die Daten verwendet werden können, müssen sie sinnvoll eingetragen werden. Nicht einfach stumpfsinnig „so eintragen, wie es in der Realität ist“.
Und noch steht meines Wissens der Grundsatz, dass wir nicht für Renderer mappen, ich versuche es mal so zu präzisieren: zumindest nicht für die individuellen Bedürfnisse EINES Renderers.
„Die Redewendung „Don't tag for the renderer“ (Attributiere nicht für den Renderer!) hat bei OSM eine lange Geschichte und bedeutet: Nicht absichtlich falsche Attribute vergeben, nur weil diese zur gewünschten Darstellung führen.“ http://wiki.openstreetmap.org/wiki/DE:T … e_renderer
Genau das wird aber gemacht, wenn man amenity=parking für straßenbegleitende Parkmöglichkeiten missbraucht. Es ist „mappen für den Renderer“.
Ich sehe bei amenity=parking keinen Bedeutungswandel, sondern einen Missbrauch, damit es auf Karten dargestellt wird.
Das Wichtigste beim kartografieren: immer das Wiki gut studieren.
Offline
#30 2017-04-05 15:27:28
- Jo Cassel
- Member
- Registered: 2015-12-02
- Posts: 1,534
Re: Falsches Kartieren von straßenbegleitenden Parkflächen
Mmh, wenn ich das richtig verstehe, soll das Ergebnis dieser (auch kommunalpolitisch hochrelevanten) Planung:
https://www.hna.de/kassel/bad-wilhelmsh … 503883.htm
in OSM dem Bürger vorenthalten, quasi im Code vesteckt werden,
nur damit irgendeine suboptimale Software auch genau so funktioniert, wie sich das jemand wünscht?
Naja, dann bekenne ich mich mal zum "stumpfsinnigen" Mappen, "wie es in der Realität ist" - für Menschen und nicht nur für Maschinen.
Offline
#31 2017-04-05 15:57:12
- geri-oc
- Member

- From: Sachsen
- Registered: 2011-03-21
- Posts: 5,055
- Website
Re: Falsches Kartieren von straßenbegleitenden Parkflächen
...
Wenn man Daten so einträgt, dass die Verwendung nicht mehr möglich ist, also die Daten nicht sinnvoll verwendet werden kann, dann ist das nicht zielführend....Genau das wird aber gemacht, wenn man amenity=parking für straßenbegleitende Parkmöglichkeiten missbraucht.
Dann wird aber auch das Verkehrszeichen "Parkplatz" missbraucht.
Wie gesagt lässt sich die Straßenbegleitung aus gemeinsammen nodes ableiten und dem "auszeichnen" ableiten. Dann sollte vielmehr auf das eintragen der "Realität" gedrungen werden:
amenity=parking
parking=surface
surface=asphalt
parking:condition:maxstay= 2 h
parking:condition:time_interval=Mo-Fr 08:00-18:00; Sa 08:00-13:00
parking:lane=parallel
operator=Stadt Dresden
access=*
website=*
lit=*
fee=*
description:de=*
Das zeigt dem Renderer mehr und er kann entscheiden ob er z.B. parking:lane nutzen möchte und wie (eventuell wie von pyram vorgeschlagen: 'Letztere könnte man dann ja wie einen Parkplatz auf der Hauptkarte gelb darstellen, aber das "P" weglassen.').
Das sind m.E. Daten der Realität - die Daten die jeder (nach seinem Bedarf) sinnvoll verwenden kann. Wer eine "reine" Parkplatzkarte erstellen will kann dann nach fee, lit, access, ... weiter unterscheiden.
Offline