Danke!

Ich habe einen Link mit Anker gepostet. Zitat:
"Note, that different entrances can have different access values and different roads inside area can have different access values too. For example, we have area with permissive access - so we mark it with access=permissive. But there are several entrances, one of which is designated for all people, and other - only for persons, which have key. So we mark one entrance with access=permissive and other - with access=private. Another example - we have botanical garden with permissive access, which have roads, which are designated for public, and roads, which are designated only for staff of garden. In such case we have access=permissive at one roads and access=private (or access=no) at another."

Bezüglich foot=yes könntest du Recht haben. Wahrscheinlich wäre da ein foot=permissive sinnvoller statt einem access=permissive + foot=yes. Steht ja auch im Wiki:

"To avoid ambiguity, you may therefore want to avoid general tags access=yes and access=permissive, and use more specific transport modes where appropriate. For example, to distinguish a footway with open access from one with private access, use tags like foot=yes and foot=private instead of access=yes and access=private."

access=*#Transport_mode_restrictions

Den Durchgang habe ich von vor längerer Zeit in Erinnerung. Ich war zwar vor kurzem vor Ort, habe den Durchgang aber nicht prüfen können. Falls er nicht mehr vorhanden sein sollte, darfst du das gerne korrigieren. Dafür brauchst du auch keine Änderungssatzdiskussion anzustoßen. Das ist entweder richtig oder falsch.

Das Drucklufthaus schreibt auf seinen Webseiten selbst von einem Biergarten und aufgrund der umgebenden Bepflanzung sollte eigentlich niemand den Gartencharakter in Zweifel stellen.

http://drucklufthaus.de/ueberuns.php

Ob Speisen mitgebracht werden dürfen oder nicht weiß ich nicht. Ich vermute aber, dass das in den "Biergärten", die hier im Ruhrgebiet so bezeichnet werden, selten erlaubt sein wird. Da sollte also eher das Wiki der (außerbayerischen) Realität angepasst werden statt dass alle Biergärten außerhalb Bayerns gelöscht werden sollten.

Könntest du bitte in Zukunft mal etwas selbst recherchieren bevor du Änderungssatzdiskussionen anstößt? Ich finde das völlig überflüssig, zeitraubend und nervend.

access=permissive für Eingänge ist im Wiki beschrieben. access=*#Nodes.2C_ways_and_areas

barrier=door steht im Wiki als barrier=<user defined>. Es ist in der Datenbank immerhin schon 16444x vorhanden, also ziemlich etabliert.

https://taginfo.openstreetmap.org/tags/barrier=door

Was foot=yes heißen soll muss ich wahrscheinlich nicht wirklich erläutern. Es gibt ja natürlich auch Eingänge, die nicht für Fußgänger erlaubt sind. Beispiel:

node/4329478362

Ein Mapper hat in Witten mal immer an ein paar Eingängen foot=yes ergänzt. Daher habe ich dann überall foot=* explizit gesetzt. Du hattest dich vor kurzem noch selbst für explizites Tagging von z.B. diet:vegan=* und diaper=* ausgesprochen.

Danke für den Hinweis zu door=*.

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.

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.

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_lane

Format definiert ist es bislang nicht.

Was hältst du davon? Das sollte die von dir angedeuteten Probleme mit vorhandener Software lösen.

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

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!

Oh, habe es gerade im Wiki gesehen. Frage beantwortet.

Was genau rechtfertigt denn ein surveillance=outdoor an den Packstationen? Sind da Kameras angebracht?

Habe dir gerade eine Antwort auf die PM zum gleichen Thema geschrieben.

Zu lanes ein weiteres Mal: Wenn ein Wert nicht da ist kann man nicht wissen ob der Wert unbekannt oder tatsächlich der Default-Wert ist. Es wird auch meines Wissens nach auch nirgendwo davon abgeraten, lanes explizit zu mappen.

Höre bitte endlich damit auf, zu versuchen, deinen persönlichen Geschmack durchzusetzen. Die Dinge, die ich so gemappt habe, habe ich aus guten Gründen so gemappt.

Die Vorteile der vermeintlich leichteren Wartbarkeit sind tatsächlich keine. Ich versuche den Ort beizubehalten und die Namen der vorherigen Geschäfte und old_name zu schreiben. Auch wenn man das Geschäft verschiebt sind es nur wenige Klicks um die Adresse zu aktualisieren.

Bei POIs macht es manchmal Sinn, sie als Knoten einzutragen und manchmal, sie als Weg einzutragen.

Dass es semantisch wenig Sinn macht, POIs an Eingänge zu mappen, sieht man insbesondere wenn an den POIs dann auch barrier und vielleicht colour und material dransteht. Das macht einfach keinen Sinn. Dagegen kann es sehr viel Sinn machen wenn ein am Gebäude dransteht wenn z.B. das komplette Gebäude das Geschäft ist.

Ich habe mir nicht widersprochen. Meinetwegen kannst du gerne auch unbedeutende Flaggen mappen. Ich habe dich auf deinen Widerspruch hingewiesen, einerseits willkürlich Daten sparen zu wollen und andererseits Daten einzutragen, von deren Eintragen explizit im Wiki abgeraten wird.

Wenn mit der Overpass API POIs zusammen mit Adressen abgefragt werden können konstruiere doch bitte mal eine Overpass-Abfrage z.B. von Apotheken mit Adressen in Wetter. (Ich gehe mal davon aus, dass sie dort ohne Adressen eingetragen sind.)

Höre damit auf! Die lanes-Angaben sind definitiv nicht falsch, sondern richtig. Ich hatte dir schon geschrieben, dass bei einem nicht angegebenen Wert nicht unterschieden werden kann, ob dieser Wert unbekannt ist oder der Default-Wert ist. Daher ist es oft sinnvoll, auch Default-Werte explizit zu setzen.

Durch deine unsinnigen Aktionen sparst du kaum Daten ein. Wie ich dir auch schon geschrieben hatte werden viel, viel mehr Daten durch ganz andere Dinge verbraucht. Das ist aber auch nicht schlimm, denn es gibt keinen Grund, mit korrekten Daten zu sparen.

Was soll das? Unterlasse solche Änderungen bitte endlich!

Der Ruder-Club Witten ist als Fläche vollkommen korrekt gemappt und das macht auch sehr viel Sinn so.

club=*

Den Club zusammen mit dem Eingang und barrier (!) zu mappen macht dagegen semantisch keinen Sinn.

Schlimmer noch: Du hast Namen und Kontaktdaten komplett gelöscht.

Höre endlich mit diesem Unsinn auf!

Auch wieder hier: Praktisch alle Gebäude in Witten sind in 3D gemappt. Die dazu passende level-Angabe ist daher sinnvoll. Höre auf, so etwas zu löschen.

Nein, die Adressen von POIs sind nicht genauso einfach auffindbar wenn sie an einer Fläche dranstehen. Wenn man z.B. bestimmte POIs (z.B. Apotheken) in seiner Umgebung per Overpass API abfragt hat man eben nur die POIs ohne die sie umgebenden Wege. Deshalb ist es sinnvoll, an POIs immer auch die Adresse dranzuschreiben.

Witten ist quasi komplett in 3D gemappt. Daher ist auch die Angabe von level sinnvoll. Und es gibt auch diverse Beispiele wo level nicht gleich 0 angegeben ist, z.B. Praxen oder Geschäfte in der Stadtgalerie.

Wenn kein lanes-Wert angegeben ist lässt sich nicht unterscheiden, ob der Wert einfach nicht gemappt ist oder der Default-Wert ist. Daher ist es sinnvoll, ihn bei Straßen in jedem Fall anzugeben.

OpenStreetMap ist eine allgemeine Geo-Datenbank. Es gibt keine Relevanzkriterien und es gibt keinen vorgegebenen Verwendungszweck wie z.B. Routing. Stattdessen können die OSM-Daten auf diverse Arten genutzt werden und Aufgabe der Mapper ist, möglichst viele, korrekte Daten einzutragen.

Wir leben in Zeiten des Big Data und größere Datenmengen sind – wenn die Daten korrekt sind – kein Problem.

Du hast Daten gelöscht, deren Erfassung im Wiki explizit empfohlen wird. Andererseits trägst du Daten ein, von denen im Wiki explizit abgeraten wird (z.B. Flaggen). Bitte verstehe endlich, dass du damit komplett falsch liegst und nur Schaden anrichtest.

Selbst wenn du alle level und lanes löschen würdest würdest du damit im Vergleich nur sehr wenig Daten "einsparen". Viel, viel mehr Daten machen z.B. die 3D-Daten der Gebäude aus, die ja auch für Routing unnötig sind, die aber allgemein anerkannt sind.

Was in Zukunft übrigens noch kommt ist die Erfassung von Straßen als Flächen. Da kommen dann noch viel, viel mehr Daten dazu, die für einfaches Routing nicht benötigt werden, aber z.B. für automatisches Fahren sehr sinnvoll sind.

Ich bitte dich nochmal: Höre mit deinen Lösch- und Ummapaktionen auf!

Bitte unterlasse solche Änderungen. Hausnummern werden laut Wiki explizit mit Kommata getrennt.

osm.wiki/DE:Key:addr

Bitte unterlasse ebenfalls die diversen Löschungen, z.B. von lanes und noexit.

Deine Interpretation der Wiki-Seiten kann ich überhaupt nicht teilen. Die Adressen lassen sich einfacher auffinden wenn sie direkt am POI stehen. Ich bitte doch nochmal: Unterlasse weitere Löschungen von Adressen.

layer=0 benutze ich kaum. Du meinst scheinbar level=0. Das bedeutet, dass der POI im Erdgeschoss ist. Du hast also offenbar Daten gelöscht, die du nicht mal verstanden hast.

Datenmengen sind bezüglich Mobilgeräten völlig uninteressant. Niemand sagt, dass alle OSM-Daten auf Mobilgeräte heruntergelasen werden müssen. Stattdessen ist ein Extrakt der für die spezielle Anwendung relevanten Daten sinnvoll.

Und zu AVU: Da kennt die Wikipedia schon diverse Bedeutzungen. Das ist international nicht eindeutig. Daher ist der Langname eindeutig sinnvoll um eindeutige Aussagen zu machen.

https://de.wikipedia.org/wiki/AVU

Hallo! Bitte höre auf, erneut Daten zu löschen, die ich eingetragen habe. Adressinformationen an Läden und anderen Einrichtungen machen Sinn und sind auch im Wiki beschrieben.

Shop:

shop=*#Address_information

Erstes Beispiel zu addr:* ist ein Restaurant:

osm.wiki/DE:Key:addr