Ist dir hier node/1260812894 und hier node/638587915 die Straße verrutscht?

node/332056473

Ich würde nicht für jeden Container einen eigenen Node machen, bringt ja keinen Vorteil (und ist bestimmt auch nicht so gedacht). Bring eher Nachteile: mehr unnötige Daten und wenn man schauen will, was man dort einwerfen kann, muss man drei Einträge untersuchen an statt einem, also z. B. in OsmAnd alle drei Recyclepunkte antouchen an statt nur einem.

node/1204447156 Was verstehst du unter access=permissive?

Ich finde es nicht überflüssig, denn soweit ich weiß, wird das, was du als „Biergarten“ eingetragen hast, mit leisure=outdoor_seating getaggt: osm.wiki/DE:Tag:leisure=outdoor_seating Unter Beispiele steht ausdrücklich, dass so etwas keine Biergärten sind. osm.wiki/DE:Tag:amenity=cafe#Stra.C3.9Fen-Caf.C3.A9

foot=permissive ändert technisch immer noch nichts. Das heißt auch, dass jeder immer die Nutzungerlaubnis hat, bzw. Duldung. Wenn dann würde ich es mit foot=customers taggen. Und das access gar nicht, da ein access=permissive|yes auch die Durchfahrt von Fahrzeugen erlaubt.

way/467956358

„Reine Außenbestuhlungsflächen gastronomischer Betriebe ohne Gartencharakter und ohne die Möglichkeit, eigene Speisen mitzubringen sind keine Biergärten und sollten auch nicht als solche erfasst werden.“ osm.wiki/DE:Tag:amenity=biergarten

way/467956357

Hier ist ein Durchgang? Nicht dass ich wüsste.

Also durch die Tür darf jeder durchgehen? Ständig? Die ist immer offen?

In der Datenbank steht auch ganz of access=designated. Nur weil es oft drin steht, heißt das nicht, dass es sinnvoll ist.

Warum foot=yes an einer Tür? Das jeder Fußgänger jederzeit durchgehen darf? Jederzeit? Die ist nie verschlossen?

Das man durch Türen durchgeht und nicht durchfährt, ist klar.

Wenn du mit foot=yes angeben willst, dass man als Fußgänger durch die Tür durchgehen darf, dann gibst du mit access=permissive an, dass JEDES Verkehrsmittel durch die Tür darf, auch LKW.

Das barrier=door an einem Node, der eh schon mit entrance=yes eine Tür ist, ist unsinnig.

Ich bin für sinnvolle explizite Tags, nicht überflüssige und unsinnige.

Ich weiß nicht, was genau du im Wiki zu access=permissive meinst. Kannst du das mal zitieren?

node/4625254581

Warum access=permissive? Und warum foot=yes? Und was soll barrier=door sein? Hier ist das nicht aufgeführt: osm.wiki/DE:Key:barrier

Mit door=* kannst du die Art der Tür angeben, wozu auch immer.

Doch, die Begründung mit dem Navi war enst. Allerdings hätte man man auch bicycle=no eintragen können, die Löschung war wohl etwas voreilig. Siehe https://forum.openstreetmap.org/viewtopic.php?id=57806 Dazu https://forum.openstreetmap.org/viewtopic.php?id=57863

Ich hätte nach links in die Dümptener Straße abbiegen sollen, aber das Navi wähnte mich auf dem Fußweg, welcher ohne Abzweigung auf die Dümptener Straße führte, und hat daher keine Richtungsanweisung gegeben. Ich war aber auf der Fahrbahn der Oberhausener Straße und bin dieser daher weiter gefolgt.

Dass der Path einfach so im Nichts endet, ist ja wirklich komisch und ich denke, die meisten Kartographen würden ihn einfach wieder mit der Straße verbinden. Daher würde ich den Weg etwas weiter eintragen, z. B. bis zur Straße Terp Wai, aber korrekterweise als reinen Fußweg (highway=path, foot=yes, access=no, traffic_sign=DE:239, surface=*).

way/374954737

Ich würde bei maxstay=* immer die Einheit dazu schreiben, damit es eindeutig ist. maxstay=*

way/466914953

Der noexit-Tag gehört nur auf den Endknoten:

osm.wiki/DE:Key:noexit

Und ist eigentlich nur dafür da, damit klar ist, dass man dort nicht hin gehen muss und den Weg weiter kartographieren. Für die Karte oder Routenplaner ist er überflüssig.

Und access=destination bezieht auch Fußgänger mit ein, nicht nur Fahrzeuge. Ich gehe davon aus, dass auch in diesem Fall vehicle=destination richtig ist. Siehe

http://osmtools.de/traffic_signs/?signs=250,1020-30

way/235290363

Was soll denn access=designated bedeuten?

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.

Ich kenne die Wikiseite zum Micromapping.

Ich habe mir mal einen Punkt in Witten angeschaut:

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

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

http://osmapa.pl/osm24 ?

Du solltest so kartographieren, dass es nützlich ist, also die Navigation verbessert, nicht verschlechtert und Probleme verursacht.

way/313575725

Straßenbegleitende Stellflächen werden nicht als Parkplatz eingetragen, sondern mit osm.wiki/DE:Key:parking:lane

way/116523889

Straßenbegleitende Stellplätze werden nicht mit amenity=parking getaggt sondern mit osm.wiki/DE:Key:parking:lane

way/443834985

Straßenbegleitende Stellflächen werden nicht als Parkplatz eingetragen, sondern mit osm.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 osm.wiki/DE:Tag:amenity=parking_space