Hallo,
ich habe erst Anfang der Woche durch einen Forenbeitrag davon erfahren, dass direction auch zu give_way und stop gesetzt werden sollte. Bislang galt die Aussage, dass diese Zeichen automatisch zum nächsten Kreuzungsnode ausgewertet würden. Diese Ansicht hat sich anscheinend in der letzten mir nicht bekannten Zeit geändert. Ich werde dies natürlich zukünftig beachten.
Gruß
Thoschi

Sorry, ein Versehen, danke für den Hinweis. Werde ich ändern, spätestens wenn ich aus dem Urlaub am WE zurück bin. War dran vorbeigefahren und hatte gleichzeitig den Zeitungsartikel vorliegen, da hab ich wohl zu viel interpretiert.

Hi,
danke für den Hinweis. Habe aber jetzt auf die Schnelle nur 6 Nodes wiedergefunden (und geändert).
Gruß Thorsten

Meines Wissens hatte ich damals nur die landuses von den Wegen getrennt. Ob der Weg existiert weiß ich nicht, der ist wohl seit 2012 dort eingezeichnet. Weder auf Bing noch im NRW-Atlas (hab das mal dort nachgesehen), ist dieser Weg erkennbar. Aber ich war nie dort vor Ort.

Hallo,
kann sich das nochmal jemand ansehen? Ich habe versucht, das Multipolygon zu "flicken". Ob es mir gelungen ist, kann ich nicht sagen. Grundsätzlich finde ich diese Art der Polygone sehr Reservierung änderungsUNfreundlich.

Uii...das habe ich nicht bemerkt, danke für den Hinweis. Meines Wissens hatte ich diesbezüglich nur Riverbank der Wupper angefasst. Ich schau mir das nochmal an, gib mir ein paar Tage Zeit.

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

Hallo,
Adressen an landuse sind nicht gewünscht. Es sollte hier ein eigener Node für den Reiterhof (hier vor allem Falkenhof) verwendet werden. Auch fehlen amenity oder ggf. leisure, um den Reiterhof zu kennzeichnen.

Erstens, vom Eintragen von Flaggen wird NICHT explizit abgeraten, ich finde im Wiki nichts dazu. Das Beispiel Flaggen an Golflöchern kann mich nicht auf Werbeflaggen übertragen, Werbeflaggen sind wichtige Landmarken. Die Eisfahne am Kiosk hingegen ist mit denen bei Golflöchern gleich zu setzen und somit unerwünscht. Also, wo steht, dass diese Werbeflaggen z.B. vor Autohäusern und Supermärkten unerwünscht sind?

Ein lanes=2 ist an einer 2-spurigen Straße mit Gegenverkehr ohne ein lanes:forward oder lanes:backward falsch, da es den Eindruck erweckt, ich kann beide Spuren in eine Richtung frei wählen, lanes=2 ist nicht nur überflüssig, sondern tatsächlich leider falsch.

Mit Adressen an POIs habe ich immer meine Schwierigkeiten, auch wenn es nicht verboten ist. Redundante Daten sind Datenmüll, egal ob sie auf der einen Seite das Leben erleichtern oder nicht.

Im übrigen habe ich die Diskussion ins Forum gebracht, weil ich es unsinnig finde, nur zu zweit im Changeset zu diskutieren. Es muss dabei sichergestellt werden, dass wir beide in den meisten Punkten unserer Differenz über die Sinnhaftigkeit von richtigen Tagging-Eintragungen streiten. Bei lanes hingegen sehe ich es tatsächlich wie oben beschrieben als falsch an.

Wegen level=0 meinetwegen, ich halte es für überflüssig, da es impliziert wird, auch bei 3D, dort ist es höchstens für die Wartung interessant. Wenn es POIs gibt, bei denen level ungleich 0 ist, sollte man diese setzen. In den meisten Fällen sind diese ja auch nachzutragen, nicht jeder denkt daran, deshalb kann man es ja nachholen.
lanes=1 ist bei Einbahnstraßen auch impliziert und absolut überflüssig. Ich muss da auch nicht wissen, ob es default ist oder explizit gesetzt, es ist überflüssig.
Adressangaben an POIs sind überflüssig, sie werden bei jeder Suche, auch über OSM gefunden, mit Overpass geht das wohl auch. Ich finde es unsäglich, wenn eine Adresse gesucht wird und gleich zig Treffer mit irgendwelchen Läden etc angezeigt werden. Auch halte ich es für sinnvoll, POIS nicht mit dem Gebäude zusammen einzutragen sondern als Extra-Node, das macht zustätzlich die Wartbarkeit des POIS einfacher und auch ein Umzug eines Geschäftes lässt sich mit einfachem Verschieben des POIs realisieren. Ich zusätzlich die Adresse zum POI getaggt, hat man natürlich hier mehr Aufwand. Auch halte ich es für sinnvoll, wenn möglich den POI auf den Eingang eines Geschäftes etc. zu setzen.
Flagpole bezieht sich z.B. auf die Fahnen bei Golfplatzlöchern. Bei advertising werden sie durchaus als wichtige Landmarken angesehen, was sie auch sind. Also nicht unsinnig. Zudem widersprichst Du Dich hier mit Deiner Aussage zu den nicht vorhandenen Relevanzkriterien.
Gegen aera:highway habe ich doch gar nichts gesagt, experementiere selbst gelegentlich damit rum.
Ja, wir leben in BigData (leider), aber deshalb muss ich nicht redundante Informationen taggen, das ist m.E. übertriebener Ehrgeiz und unsinnig.

Es ist unsinn, sie sind genauso leicht auffindbar, wenn POIs ohne Adresse an oder auf einer Fläche angebracht sind. Die Adresse ist in diesem Fall Datenmüll und das Wiki schreibt nur von einer Empfehlung und nicht von einem "Muss".

level=0 ist ebenso unsinnig, es sei denn, wir befinden uns im 3D-Mapping. Die POIs sind aber alle 2D gemappt, so dass level=0 nur Datenbalast ist.

AVU ist die korrekte Bezeichung, war im Kundencenter und habe gefragt. Auch intern wird die alte Langbezeichnung nicht mehr genutzt.

OSM-Daten werden von externen Anbietern herunter geladen. Um OSM bekannt zu machen und für möglichst viele Nutzer attraktiv zu machen, sollte auch Datenbank"beschickern" möglichst wenig Datenballast eingetragen werden. Auch wenn Datenballast nicht unzulässig ist, muss man nicht jede überflüssige Eintragung machen. Auch wenn lanes=3 und lanes:forward=2 ist, ist lanes:backward=1 überflüssig, da impliziert.

Hausnummern, die mit Semikolon getrennt sind, sind zwar zulässig, für die Adresssuche jedoch äusserst ungünstig zu finden. Es ist ebenso zulässig, getrennte Adressnodes für auf ein Gebäude mit mehreren Hausnummern zu setzten. Dies ist auch Nutzerfreundlicher.

Noexit ist nur dann notwendig und erforderlich, wenn auch Fußgänger keine Möglichkeit haben weiter zu kommen. Auf Parkplätzen haben Fußgänger alle Möglichkeiten nach rechts und links weiter zu gehen, von daher ist "notexit" an der parking_aisle hier eindeutig falsch!

lanes=1 ist für residential-Streets, welche als Einbahnstraßen getaggt sind, überflüssig, da impliziert.

layer=0 ist überflüssig, da impliziert.

level=0 ist im 2d-Tagging überflüssig, da impliziert. Dies macht nur Sinn, wenn die Gebäude im 3d-Tagging vorhanden sind.

Überlege bitte mal, was Du alles für unnötiges Zeugs taggst, das eindeutig überflüssig ist.

Hallo,
ich ja Deinen Ärger verstehen, ABER:
Adressinformationen an einem POI machen keinen Sinn, da die Information über die Nähe zur nächsten Fläche (in diesen Fällen Gebäuden mit eindeutiger Adresse) problem gefunden werden. Die Aussage im Wiki ist so zu interpretieren, dass die Adressinformationen zu POIs dann wichtig sind, wenn keine Adresse in der Nähe zuzuordnen ist oder sie uneindeutig ist. Von daher blähen diese Informationen den Datensatz nur unnötig mit redundanten Informationen auf. Auch Layer=0 ist unnötig (mit Ausnahme von sehr sehr wenigen Ausnahmen), da diese Information impliziert wird, alles ausser layer=0 hingegen ist interessant. Von daher ist es im Intersse auch von Nutzern mobiler Geräte, die Informationen gering zu halten, also auch auf redundante Informationen wie Adressen, die anderweitig eh ermittelt werden, zu verzichten. Dank mal drüber nach. Ich weiß, es ist schmerzlich, viel Arbeit in etwas hinein gesteckt zu haben, aber wenn es Daten unnötig aufbläht und somit nur schwer auswertbar macht, sollte man darauf verzichten. Und da der Algoryhtmus zur Adressfindung eh existiert und läuft, ist eine dopptelte Adresseingabe unsinnig.
Ähnliches gilt m.E. z.B. für "Aktiengesellschaft für Versorgungs-Unterehmen", welche sich selbst in allen Anschreiben und der Website als AVU tituliert und so auch allgemein bekannt ist. Hier als Operator den Langnamen einzutragen ist m.E. Datenmüll.

Danke für den Hinweis, ich schau mir das nochmal an.
Thorsten

Hallo Mary,
das wiki ist hier nicht eindeutig, bzw. hat eine Dokumentionsschwäche. Das jetztige Tagging würde bedeuten, dass Fußgänger bis auf die Autobahn gehen dürften, und schon daran erkennt man, dass hier ein Problem ist. Bei der Beschreibung von service hat man nur an Tankstellen und Parkplätzen ausserhalb von Autobahnen gedacht. Zudem ist in Komibination mit der Beschreibung zu motorway_link die Sache wieder eindeutig.
LG Thoschi

Hallo,
meiner Erkenntnis und dem Verständnis des wikis nach ist die Zu- und Abfahrt von der Autobahn, welche nicht für Fußgänger freigegeben ist, als motorway_link (osm.wiki/DE:Tag:highway%3Dmotorway_link) und nicht als service (osm.wiki/DE:Tag:highway%3Dservice) zu mappen. Nur der Teil des Rastplatzes selbst ist als service zu taggen.
Die Änderung ist m. E. falsch!

Also diese komischen roten Marker sind Usermeldungen, die man nicht so einfach als Unsinn abtun sollte. Die helfen, die Karten besser zu machen!

Doch: Hüttengrund Steinacher Straße Steinacher Straße mit
neuen Hausnummern 200 +bisherige Nummern

Hallo,
der Waldfriedhof ist bereits gemappt. Er ist auch kein "amenity=place of workshop" sondern "landuse"cemetery" -> siehe: osm.wiki/DE:How_to_map_a#F.
Da der nun doppelt vorhanden ist, habe ich ihn einmal gelöscht.