Changeset: 42355589
Details < Witten < Erde
Closed by Reclus
Tags
created_by | JOSM/1.5 (10966 de) |
---|---|
source | survey; Metropole Ruhr: Luftbilder (10 cm) |
Discussion
-
Comment from Graf Westerholt
http://www.openstreetmap.org/way/443834985
Straßenbegleitende Stellflächen werden nicht als Parkplatz eingetragen, sondern mit http://wiki.openstreetmap.org/wiki/DE:Key:parking:lane Überlege mal, wie nützlich das ist, was du gemacht hast, wenn man in einem Navi nach einem Parkplatz in der Umgebung sucht. Für einzelne Stellflächen, z. B. für Behindertenstellflächen gibt es http://wiki.openstreetmap.org/wiki/DE:Tag:amenity=parking_space
-
Comment from Reclus
Danke für den Hinweis! Ich lasse es mir gerade durch den Kopf gehen. Die Nützlichkeit von parking:lane ist ja erst mal unbestritten. Ich werde mich bemühen, das zu ergänzen.
Rein formal: amenity=parking_space soll eine Ergänzung eines umgebenden amenity=parking sein. Einen allein an einer Straße eingetragenen Behindertenparkplatz ohne amenity=parking als amenity=parking_space einzutragen, wäre also eindeutig falsch.
Die straßenbegleitenden Parkplätze, die ich eingetragen habe, sind entweder durch den Bodenbelag separat vor Ort vorhanden oder durch Farbe klar von der Straße getrennt und damit auch vor Ort vorhanden. Ich denke also schon, dass man sie im Rahmen von Micromapping eintragen kann. Ich verstehe aber natürlich auch, dass manche Software damit Probleme hat. Sie sollten also idealerweise etwas anders getaggt werden als größere Parkplätze. Vorschläge?
In Witten ist schon einiges recht genau gemappt (Micromapping). Ich plane zumindest, demnächst auch die Straßen als Fläche einzutragen und bei dieser Gelegenheit auch die Bürgersteige separat als Linienzüge. Die ja in der Realität ja als Fläche vorhandenen straßenbegleitenden Stellflächen zu löschen würde da nicht reinpassen.
Ich überlege noch und bin für Vorschläge offen. Bitte lösche aber vorerst in Witten nicht oder mappe falsch um (parking_space ohne parking s.o.). Danke!
-
Comment from Graf Westerholt
Hallo Reclus,
du solltest dir überlegen, wofür du etwas machst und welche Folgen es hat. Zum Beispiel deine Idee, die Straßen als Flächen einzutragen, ist ganz schlecht, da du damit das Routing durch Navis verhinderst. Ich kenne keinen Routenplaner für OSM, der gescheit über Flächen routet. Daher ist bei Flächen oft immer noch ein Weg zum Routen gezeichnet. Wenn dir von Mapnik die Straßen zu schmal dargestellt werden, kannst du das über width=* ändern, falls du das noch nicht gemacht hast. Natürlich keine fiktive Breite, sondern die reale Breite der Straße angeben.
OSM muss kein 100% detailgetreues Abbild der Realität sein. OSM ist eine Karte, einerseits zum draufgucken, einerseits als Daten für Routenplaner. Separate Bürgersteige haben bei mir beim Routen auch schon oft zu Problemen geführt, da die User nicht ausreichend Verbindungen zu anderen Wegen und Straßen eingetragen haben, oder weil beim abzweigen von einer Straße ein Navi glaubt, man müsse da abbiegen und dafür eine Anweisung gibt, wodurch ich beim Fahrradfahren in die Irre geleitet werde, und es bringt weder zum Routen noch zum auf die Karte gucken Vorteile, Bürgersteige separat einzutragen, sondern eben nur mehr Aufwand und Probleme. Nutzt du oft ein Navi mit OSM, z. B. OsmAnd?
amenity=parking ist für größere Parkplätze, und eindeutig nicht für straßenbegleitende Stellflächen, ein Grund ist, dass man in Navis nach Parkplätzen, welche mit amenity=parking getaggt sind, suchen kann. Es ist richtig, dass es noch nicht ganz klar ist, wie ein einzelner Behindertenparkplatz eingetragen werden soll, aber da amenity=parking dafür ausscheidet, bleibt die Möglichkeit, es mit amenity=parking_space und parking_space=disabled zu machen. Siehe die Diskussion: https://forum.openstreetmap.org/viewtopic.php?id=57365
OSM ist eine Abstraktion der Realität, kein detailliertes Modell oder gar ein Luftbild. Man trägt eine Straße ein, nicht jeden Pflasterstein, aus dem sie besteht. Man trägt den Grundriss jedes Gebäudes ein und nicht jeden Stein, aus dem das Haus besteht. Man trägt eine Wiese als Fläche ein und nicht jeden Grashalm. Und man trägt nicht jede Stellfläche einzeln ein.
Es gibt noch so viele Sachen, welche man sinnvoll in OSM eintragen kann. Ich weiß nicht, was alles in Witten oder deiner Umgebung eingetragen ist, aber z. B. wheelchair=*, diaper=*, diet:*=*, organic=*, payment:*=*, öffentliche Toiletten … (falls noch nicht passiert, bitte die Wiki-Einträge dazu lesen) Kennst du
Du solltest so kartographieren, dass es nützlich ist, also die Navigation verbessert, nicht verschlechtert und Probleme verursacht.
-
Comment from Reclus
Darüber, was OSM ist, kann man sehr unterschiedlicher Meinung sein. Ich sehe es als offene, verlinkte Geodatenbank. Und OSM hat – zum Glück – keine Relevanzkriterien. Zu Micromapping siehe: https://wiki.openstreetmap.org/wiki/DE:Micromapping
Die Vorschläge um Straßen flächig einzutragen habe ich mir noch nicht angesehen. Ich gehe aber davon aus, dass die vorhandenen Linienzüge nicht gelöscht werden. Die Kompatiblität würde damit vorhanden bleiben. Mapbox hat in letzter Zeit Interesse an Straßen als Flächen gezeigt und in Bezug auf selbstfahrende Autos wäre es meines Wissens nach auch notwendig, Straßen als Flächen zu haben. http://blog.openstreetmap.de/blog/2017/02/wochennotiz-nr-343/
Die von dir genannten Attribute sind nach Möglichkeit alle in Witten eingetragen. Und noch einiges mehr. Siehe auch: https://wiki.openstreetmap.org/wiki/User:Reclus
Die Frage ist für mich nicht, ob straßenbegleitende Parkplätze als Fächen eingetragen werden sollten, sondern wie. Ich hatte ja oben schon um Vorschläge gebeten.
-
Comment from Graf Westerholt
Ich kenne die Wikiseite zum Micromapping.
Ich habe mir mal einen Punkt in Witten angeschaut:
http://www.openstreetmap.org/node/837938805
Da kann ich weder einen diaper=*-Tag, noch diet:*=* noch organic=* noch fair_trade=* noch takeaway=* noch delivery=* finden. Wenn es das da nicht gibt, sollte das mit no getaggt werden, damit klar ist, dass es nicht vergessen wurde. Allerdings ein disused:amenity=pub. Was das da soll, kann ich nicht verstehen, da die Stelle wohl als Restaurant genutzt wird. Hier ist eine Overpass-Turbo-Abfrage mit Restaurants ohne diet:vegan=*-Tag:
http://overpass-turbo.eu/s/nO3
Hier für Restaurants ohne diaper=*-Tag:
http://overpass-turbo.eu/s/nO5
Ist also noch viel zu tun.
Wie trägt man Einbahnstraßen mit einer Fläche ein, also wie gibt man da an, in welche Richtung man fahren darf?
Zum Eintragen von straßenbegleitende Parkflächen als Fäche braucht man wohl einen neuen Wert, so etwas wie area=roadside_parking. Du könntest dazu ja ein Proposal machen. Ich denke, das würde angenommen, da einige jetzt das amenity=parking für straßenbegleitende Parkmöglichkeiten missbrauchen. Ob es damit sinnvoll ist, jede Stellfläche einzeln einzutragen, bezweifele ich. Was bringt das für einen Vorteil?
„Ungeschriebene Regel
So präzise wie möglich mit so wenig Punkten wie erforderlich mappen!
Micromapping erzeugt enorme Datenmengen. Verliert man sich allzu sehr in unnötigen Details wird z.B. in Zukunft die Datenübertragung bzw Echtzeitrendering unnötig verlangsamt.“Micromapping ist ja nur ein genaueres kartographieren und sollte dazu dienen, die Orientierung mit dem Auto, zu Fuß, Fahrrad oder anderes zu verbessern, nicht verschlechtern. Eine Parkplatz-Liste, welche aus über 1000 Einträgen besteht, woraus 100 davon die straßenbegleitenden Stellflächen um mich herum, welche ich sehe, besteht, ist nicht hilfreich. Du solltest ständig ausprobieren, ob die Navigation gut funktioniert, also immer wieder Routen mit OSM planen, auch für Wege, welche du kennst, weil du auch da merken kannst, wenn das navigieren nicht funktioniert, nicht nur im Auto, auch zu Fuß oder Fahrrad (Bluetooth-Ohrstecker und OsmAnd in der Jackentasche oder großer Hosentasche).
-
Comment from Reclus
Als Alternative für straßenbegleitende Parkplätze als Fläche würde sich amenity=parking_lane anbieten, das in der OSM-Datenbank auch schon 27mal vorhanden ist. Siehe:
https://taginfo.openstreetmap.org/search?q=amenity%3Dparking_laneFormat definiert ist es bislang nicht.
Was hältst du davon? Das sollte die von dir angedeuteten Probleme mit vorhandener Software lösen.
-
Comment from Reclus
Es ist offensichtlich unsinnig, wirklich alles was nicht vorhanden ist (also an jedem Ort unendlich viel) explizit mit no zu taggen. Zudem ist mir vieles auch unbekannt. Bei einigen Informationen, bei denen mir Dinge nicht so selbstverständlich scheinen, habe ich tatsächlich einiges explizit getaggt was auch implizit galt und ein anderer Mapper (Thoschi) hatte schon angefangen, das zu löschen.
wheelchair, diet, opening_hours, diaper, organic, payment etc. sind in Witten eingetragen soweit Informationen vorliegen. Du kannst gerne per Overpass danach suchen.
Inzwischen wird die Diskussion von deiner Seite aus leider albern. Es fehlt leider die Konstruktivität. Ich werde mir sicher nicht vorschreiben lassen, was ich zu mappen habe. Schlaf lieber mal etwas über die Angelegenheit statt in deiner Wut unsinnige Aussagen zu machen.
-
Comment from Thoschi
Hallo,
die explizite Eintragung von "no"-Werten sind auch nach Regeln des Micro-Mapping zu vermeiden. Wenn "yes" bedeutet, dass Werte wie "diet" etc. vorhanden sind, ist ein "no" in der Regeln absolut überflüssig. Den Regeln für das Micromapping (So präzise wie möglich mit so wenig Punkten wie erforderlich mappen!
Micromapping erzeugt enorme Datenmengen. Verliert man sich allzu sehr in unnötigen Details wird z.B. in Zukunft die Datenübertragung bzw Echtzeitrendering unnötig verlangsamt.) im Wiki (http://wiki.openstreetmap.org/wiki/DE:Micromapping) sind zwar aktuell Beispiele nur Flächen zugeordnet, lassen aber absichtlich andere Tags entsprechend offen. Es gibt sicher Tags, wo man überlegen sollte, ob ein "no" sinnvoll sein KANN "z.B. wheelchair=no, wenn andere Eingänge an einem Gebäude für Rollstühle zugänglich sind, in der Regel ist ein explizites "no" überflüssig. Wenn eine Auswertung (z.B. auch über OSMAnd) zu einem POI gemacht wird, interessiert den Nutzer das was da ist und nicht das was fehlt. Gerne sollte man diese Diskussion im Forum fortsetzen, da die Diskussion für die bilateralen Change-Set wohl eher ungeeignet ist (ich nehme für mich nicht die Unfehlbarkeit in Anspruch!).
Gruß Thoschi -
Comment from Graf Westerholt
Wie kommst du darauf, dass ich wütend bin? Bin ich nicht.
Es gibt viele Restaurants, welche einen Wickeltisch haben und das nicht eingetragen ist. Genauso ist es bei diet:*=*. Es für offensichtlich unsinnig zu halten, das, was nicht vorhanden ist, mit no zu taggen, ist unsinnig.
„wheelchair, diet, opening_hours, diaper, organic, payment etc. sind in Witten eingetragen soweit Informationen vorliegen.“ Wie kann ich herausfinden, ob zu einem Restaurant, in dem kein diet:vegan=yes steht, keine Informationen vorliegen oder es dort nicht Veganes gibt? Ein nichtvorhandener Eintrag ist unpräzise.
Mit ist es egal, wie eine Fläche für straßenbegleitende Stellflächen getaggt wird, solange man es von amenity=parking unterscheiden kann.
-
Comment from Reclus
Gut, ich werde dann demnächst wohl die fraglichen Flächen zu amenity=parking_lane umtaggen. Damit sollte dieser Konflikt gelöst sein.
Zu den anderen Fragen: Muss ich zum dritten mal schreiben, dass mir nicht alle Informationen für jeden Ort vorliegen? Oder möchtest du tatsächlich von anderen Mappern verlangen, dass sie mit einer Strichliste zu jedem POI gehen und dann abfragen, ob man dort z.B. vegan oder halal essen kann? Und dann vielleicht mit den POI-Betreiber noch aufklären, was mit diesen Begriffen gemeint ist und anschließend mit ihm seine Zutatenlisten durchgehen? Und all das nur weil du nicht willst, dass ein paar Parkplätze mehr in deinem Navi-Gerät stehen?
Wie ich schon schrieb: Die Diskussion ist von deiner Seite aus albern. Da der grundsätzliche Konflikt ja gelöst scheint, hoffe ich, dass sie jetzt endlich vorbei ist.
Welcome to OpenStreetMap!
OpenStreetMap is a map of the world, created by people like you and free to use under an open license.
Hosting is supported by Fastly, OSMF corporate members, and other partners.
https://openstreetmap.org/copyright | https://openstreetmap.org |
Copyright OpenStreetMap and contributors, under an open license |