Die WayMarkedTrails Seite zeigt nur die in der zentralen OpenStreetMap Datenbank hinterlegten Informationen anders an als der Standard-Kartenstil auf openstreetmap.org. Bearbeiten kann man da nichts, das ist nicht das Ziel dieser Webseite.

Man kann Routen-Relation mit dem Browser-Editor "iD" beabreiten und anlegen, ich kann aber nicht sagen wie gut das da gelöst ist da ich dafür den deutlich mächtigeren, aber zugegebenermaßen auch komplizierteren JOSM Editor benutze.

Wenn Du eines der von Dir mit dem Namen versehenen Wegstücke im iD-Editor im Browser anschaust dann wirst Du links unten under all den anderen Detailinformationen bereits unter "Alle Relationen" einen Eintrag "Wanderroute: Schmetterlingspfad" (oder ähnlich, bei mir erscheint das im Englisch, die konkrete Übersetzung kann abweichen) finden.

Wenn Du diesen Link anklickst bekommst Du die Eigenschaften dieser Route zu sehen, und welche Wegstücke zur Zeit darin enthalten sind. An dieser Stelle kannst Du einzelne Wegstücke entfernen, aber nicht hinzufügen.

Ein (oder mehrere?) Wegstücke zu einer Routen-Relation hinzufügen kannst Du indem:

* Das Wegstück auswählst
* Links ganz runter bis "Alle Relationen" scrollst
* auf das [+] Symbol klickst

Dort bekommst Du dann eine Auswahl der in der Nähe bereits vorhandenen Relationen, und auch die Möglichkeit eine komplett neue anzulegen

Genau dafür haben wir ja die Wanderweg-Relationen:

osm.wiki/DE:Tag:route%3Dhiking

Der Name wird dann zwar nicht in der Standard-Kartenansicht gerendert, das ist aber auch gut so, denn sonst hätte ich in meiner Nähe einen Waldweg mit dem Namen "A8-<6>-Leineweber-Dr.Schmidt-Hermannsweg" (und das sind nur die verschiedenen Wanderwege die da über dasselbe Wegstück führen, da läuft auch noch mindestens eine Radroute drüber deren Name mir entfallen ist)

Auf den entsprechenden Themenkarten wie WayMarkedTrais und der ReitWanderKarte sind die Wegnamen *und* ihre Markierungssymbole ersichtlich, und auch zB. die OsmAnd App kann Wanderwege auf Basis der Routenrelations-Daten anzeigen.

Auf WayMarkedTrails werden Wanderrouten übrigens auch über die Suche gefunden.

https://hiking.waymarkedtrails.org/#route?id=6011607

Nur wenn ein Weg auch tatsächlich von der lokalen Bevölkerung so genannt wird wäre eventuell ein

loc_name=Schmetterlingsweg

gerechtfertigt, nicht aber osm.wiki/Tag:name=...

Zu schnell "Upload" geklickt, das hätte eigentlich mit zu "Die ersten Adressen an der Jöllenbecker Straße gehören bereits zu PLZ 33613" gehört

changeset/56926475

Now reported "Allow explicit changeset commit" as a feature request for StreetComplete:

https://github.com/westnordost/StreetComplete/issues/136

TL;DR yes, unintended but correct data wise

I had played around with the StreetComplete app while being on vacation in Japan and waiting for a ferry to arrive.

After having "solved" everything I could in the neighborhood of the hotel we'd been in I then proceeded to solve some of the quests around my parents place in Germany to kill some more time.

I told the app to sync data in between, but that apparently didn't really close the changeset, so having all actions for Yukoshima and Enger merged ....

Ähem ... ?

Finger weg! (you asked for this)

Bethel ist auf den Seiten der Stadt noch nicht einmal explizit als Stadt- bzw. Ortsteil erwähnt.

Während die meisten andern Stadtbezirks-Unterseiten der Stadt (bis auf "Mitte" und "Sennestadt") mit einer Aufzählung der Ortsteile beginnen heißt es bei Gaggerbaum einfach nur "Herzstück des kleinsten Bielefelder Stadtbezirkes, Gadderbaum, sind die v. Bodelschwinghsche Stiftungen Bethel."

https://www.bielefeld.de/de/bz/gad/

Nein, das sollte "täglich von 10 bis 24uhr, Fr, Sa bis 2 Uhr" sein, beim Samstag fehlte also 10:00-24:00 ... ist behoben

Hi, taugt Go Map!! als Editor-App?

Sieht nach "format:top=rounded" statt "=roundet" aus ...

Und ja, unkommentierte Changesets nerven ;(

Ja, das ist der Haltepunkt "Abzweig Johannisberg" stadteinwärts ... ich schau mal die Tage wo genau der nach dem ganzen Informationspunkt-Umbau der jetzt liegt.

Andere Haltepunkt "Baunernhausmuseum" ist der tatsächliche stadteinwärts, stadtauswärts liegt er aber noch etwas weiter westlich in einer Haltebucht an der Wiese

Ich hab da mal ein "Brownfield" Baugrundstück mit der alten Adresse draus gemacht:

changeset/37691267

JOSM: Du bist doof! Ich habe hier defnitiv "Details an Obernstraße, Rathausstraße, Niedernwall" als ChangeSet Kommetnar eingegeben

zu man_made=works: "Draw a polygon around the whole area of the production site and tag accordingly. If you want to get detailed you can also add the single components inside the area and tag them as what they are."

D.h. wenn dann hätte man statt des man_made=works Tags auf dem Gestamp-Gelände (ehem. Thyssen Umformtechnik) den Umriss des Werksgeländes so taggen können.

Aber *nicht* die einzelnen Werksgebäude.

Effekt jetzt: bis auf ein wohl vergessenes Kleingebäude und die Gleisanschlüsse und die Durchfahrt von der Gotenstraße zu "Am Perßwerk" ist das Werksgelände nun auf den Openstreetmap.org Kacheln "leer"

flohoff: ich denke hier wäre ein Revert angesagt? Das alles von Hand wieder richtig zu rücken wäre mir zu aufwändig und fehlerträchtig ...

(hm, die Kommentarfunktion mag keine extra Leerzeichen als Absatztrenner ... :(

"Redundante Daten sorgen für einen nicht zu vernachlässigenden Zuwachs an Datenmenge, der auch aus Sicht des Nutzers nicht erwünscht ist: "

Jein, redundante Daten nehmen natürlich mehr Platz ein, aber erlauben zum Teil auch deutlich schnellere Abfragen. Stichwort Denormalisierung.

Gerade hier mit unserem doch recht komplexen Relationen-Modell und mit zweidimensionalen Bezügen zwischen Daten.

Wenn ich vom osm2pgsql Schema ausgehe dann kann ich im denormaliserten Fall mit addr_* Tags direkt am Node die Adresse eines Nodes direkt abfragen mit

SELECT addr_street, ... FROM plantosm_point WHERE osm.wiki/Tag:osmid=...

Wären die Daten nur am Gebäude dann bräuchte es statt dessen drei mit UNION verknüpfte Abfragen, einmal die von oben und dann je eine über planetosm_line und planetosm_polygon in der Form

SELECT way.addr_street, ...
FROM planetosm_node node
JOIN planetosm_line way
ON ST_CONTAINS(way.way, node.way)
WHERE osm.wiki/Tag:node.osmid=...

Und da hast Du noch den Vorteil dass beim osm2pgsql Import alle Relations-Polygone schon passend zusammengefasst worden sind.

Wenn Du eine Anwendung hast die direkt auf den OSM XML oder PBF Rohdaten arbeitet musst Du Dich um den Schritt auch noch kümmern.

Gerade wenn Du direkt Daten zu einer Bounding Box über das OSM API herunterlädst bekommst Du ja erstmal nur einfaches XML. Bei "Adresse am Node" kannst Du da einfach Adressen auswerten indem Du nur über die <node> Tags iterierst und dann die addr_* Attribute direkt Tag für Tag auswertest. Versuch das gleiche mal von Hand wenn Du auch noch die <way> und <relation> Tags mit einbeziehen und erstmal Geometrien dafür aufbauen musst.

"Große Datenmengen müssen z. B. jedesmal durchs Netz nach einem Aufruf mit dem Browser, was die Ladezeiten spürbar verlängert. Desweiteren wird mehr als unbedingt erforderlich Speicherplatz auf dem Nutzer-Gerät belegt,"

Das ist dann Aufgabe der Serverseite das passend vorzubearbeiten und nur das nötigste zur Clientseite zu schicken.

" was zu erhöhten Berechnungszeiten und Stromverbrauch führt (durchaus relevant für Smartphone/Tablet-Nutzer; Umwelt-Aspekt)."

Die erhöhten Berechnungszeiten hast Du gerade durch ein normalisiertes Datenmodell, denormalisiert brauchst Du zwar mehr Speicher aber sparst beim Recehnaufwand (mal abgesehen davon dass der eh nicht auf der Clientseite passieren sollte)

Du kannst schwer davon ausgehen dass zB. in dem Datenmodell von OsmAnd auch denormalisiert wird (allerdings werden dort doppelte Werte vermutlich nicht doppelt vorgehalten sondern es wird darauf passend verzeigert. Da das ein in-memory Datenmodell ist hat man die Option da ja)

"Im Übrigen hat redundante Datenhaltung ein nicht unerhebliches Fehlerpotential, da sicherlich im Laufe der Zeit Inkonsistenzen auftreteten, insbesondere durch Nutzer die meinen etwas Gutes zu tun"

Jein, ich denke der Fall "User macht Relation kaputt, oder übersieht dass ein Gebäude tatsächlich als Relation erfasst ist und sieht die daran erfassten Adressdaten nicht einmal" leider häufiger ist als "User hat einem POI node innerhalb eines Gebäudes eine andere Adresse verpasst als dem Gebäude"

Auch haben wir schon Fälle gehabt wo Gebäude verschoben oder aus neueren Luftbildern neu erfasst wurden und dabei dazu gehörende POI Nodes einfach nicht mitverschoben wurden. Bei denen die eine Adresse hinterlegt hatten war das leicht zu reparieren wenn man auf so einen Fall gestoßen ist. Bei denen ohne eigene Adresse war die Zuordnung dagegen zum Teil nicht mehr klar.

Und im Prinzip wäre das ja auch vernünftig auswertbar, ein Tool wie Osmose könnte Meckern wenn innerhalb eines Gebäudes POIs mit abweichender Adresse vorhanden sind.

Es ist nur die aktuelle Implementation des Osmose "Doppelte Hausnummer" Checks die das Thema so unangenehm macht.

Aus Datenbanker-Sicht wäre es natürlich Wünschenswert Redundanzen zu vermeiden.

Andererseits ist es nicht trivial herauszufinden in welchem Gebäudeumriss ein POI liegt, insbesondere wenn das Gebäude selbst als Relation erfasst ist.

Deshalb ist es mMn. OK die Adressdaten noch einmal in Kopie am POI, und somit im direkten Zugriff zu haben.

Osmose sollte vielmehr seine "doppelte Adresse" Auswertung auf building=* und reine Adress-Nodes beschränken und offensichtliche POI-Nodes wie shop=* ignorieren.

Mehrfache Hausnummern gibt es eigentlich nur wenn es keine Renderregel für die konkrete POI-Art gibt. "Zeige die Hausnummer" ist dann die letzte Regel die greift wenn vorher keine passende gefunden wurde.

Und die Osmose "Multiple Numbers / Multiple Address" Meldungen sind eh die Pest, diese spezielle Testregel in Osmose ist meiner Meinung nach in der bisherigen Form unbrauchbar.

Jetzt haben wir aber die POI Symbole *vor* den Gebäuden obwohl die Geschäfte eigentlich *in* den Gebäuden sind?

Und die Sparkasse immer noch doppelt ...

Hier sind jetzt alle Geschäfte (Sparkasse, Friseur, Bäcker, Fahrradladen) doppelt?