Wiederholt bin ich mit dem Problem konfrontiert, dass der Editor JOSM auf meinem MacBookPro, entweder mit der Zeit sehr langsam wird, oder sonst ungewöhnlich reagiert. Manchmal kommt es vor, dass plötzlich beim setzen eines Nodes, sich der Kartenausschnitt ruckartig seitlich verschiebt.

Nach einigem Probieren wende ich nun bei solchen und ähnlichen Problemen folgende JOSM Reset Vorgangsweise an.

Anschließend die gewünschten JOSM Einstellungen wiederherstellen. Nun von diesen Einstellungen eine Sicherungskopie anlegen. Dazu "Ausgewählte Elemente exportieren" anwenden.

Kommt es erneut zu Problemen, so kann ich nach erfolgten erneuten Reset, durch Einspielen des Backups, meine gewohnten JOSM Grundeinstellungen wiederherstellen, und so zügig weiterarbeiten.

Im Versuch den Begriff "Adresse" genauer aufzulösen, habe ich soeben im AT- OSM Forum eine Absage erhalten. https://forum.openstreetmap.org/viewtopic.php?id=63031

[quote=Negreheb]4 Threads zum mehr oder weniger gleichen Thema? [/quote]

Mythos aus Fräulein Smillas Gespür für Schnee (Film), Seufz mit dem Mythos, dass Inuit zig Wörter für Schnee besitzen, muss endlich Schluss sein. https://www.stuttgarter-nachrichten.de/inhalt.die-wahrheit-inuit-und-der-schnee-von-gestern.3bf350e0-f343-4bd5-93e3-d3bd05d340b9.html

Adresse ist nur Adresse, ein Thread genügt dazu laut Negreheb auch vollkommen. Eigentlich genügt auch ein Deutschsprachiges OSM Forum. Österreich kann genauso gut im DE Forum abgehandelt werden.

Warum diese Nervosität bezüglich Aufklärung über at Adressen. Transparenz ist doch nur gut.

Vorgestern mit dem Rad einen mir bisher unbekannten Weg gefahren und ein Siedlungsschild gefunden, dessen Aufschrift mir nicht bekannt war. Die Siedlung besteht nur aus einem Hof. Heute dann das erste mal place=isolated_dwelling verwendet. Eine Premiere für mich :-) Algesbüttel, willkommen auf der Karte!

Gegeben sei: (mapillary)

Dieses Gewirr wollte ich gerade geradebiegen, kuck ich so ins Wiki um zu schauen, wie man das in schön machen kann, und das Wiki sagt:

Wo Trams auf einem von der Straße umschlossenen Gleiskörper verlaufen, werden die Trams 
als zwei Spuren und die Straße als Linien auf beiden Seiten gezeichnet. Straße und Trams 
können mit oneway=yes getaggt werden.

Wo ich mich dann frage: Könnte man das nicht alles noch etwas komplizierter und umständlicher machen?

In der Wochennotiz https://wiki.openstreetmap.org/wiki/Wochennotiz wird vielfach auf eine sogenannte Mailingliste verwiesen.

In OpenStreetMap gibt es zwei verschiedene Diskussionsräume. Die Wochennotiz wird daher auch in beiden Räumen publiziert. OSM Neulinge sind durchaus verwirrt.

a. Mailingliste: eine Mailingliste Identität bedingt lediglich eine beliebige e-mail Adresse

b. Webforum: die Nutzer Identität im Webforum ist mit der OSM- Mapper Identität verknüpft

Meine Versuch einer Erklärung:

a. Mailinglisten Beiträge behandeln OSM eher aus der Sicht des Daten Anwenders. Externe Stakeholder stellen OSM Ressourcen zur Verfügung, wirken selbst aber eher nicht als Mapper mit. Externe Stakeholder benutzen daher gerne als deren Kommunikationskanal Mailinglisten. Beispiel https://lists.openstreetmap.org/pipermail/talk-at/

b. Forumsbeiträge beschreiben die Sicht der OSM Mapper. Beispiel: https://forum.openstreetmap.org/viewtopic.php?pid=704020#p704020

Manche OSM Mitwirkende benutzen auch beide Diskussionsräume, für Verwirrung in der Diskussion in OpenStreetMap ist daher regelmäßig gesorgt. Auch daher da offensichtlich den Mailinglisten und so auch OSM Externen, viel Gewicht in der Entscheidungsfindung zugebilligt wird.

Hatte ich den schon mal?

Welche Richtung geht eine Fahrspur in Richtung "Bus"? Oder Richtung "psv"?

Besonders beliebt in Berlin und in NRW.

Das Schöne an dem Tagging ist, dass man das in der Regel als Ortsunkundiger nicht korrigieren kann. Also bleibt's bis zum Sankt Nimmerleins-tag wie's is

Wir (Mapbox) haben soeben RoboSat unter einer MIT Lizenz auf Github veroeffentlicht. RoboSat ist ein generisches Ecosystem um aus Luft- und Satellitenbildern Daten zu extrahieren. Im Folgenden beschreibe ich die technische Umsetzung und wie es fuer OpenStreetMap eingesetzt werden kann.

Luftbilder von Berlin, Segmentierungsmasken, Gebaeudeumrisse, vereinfachte GeoJSON Polygone

On-demand Tileserver fuer Debugging-Zwecke

Hier ist ein Ueberblick ueber RoboSat.

RoboSat's Kern ist ein Segmentierungsmodel — ein "fully convolutional" Neuronales Netz das wir auf Paaren von Bildern und Masken trainieren. Die Luftbilder entnehmen wir der Mapbox Maps API; die Masken generieren wir aus OpenStreetMap Geometrien die wir als Bilder rasterisieren. Dadurch koennen wir relativ schnell und vor allem komplett automatisch einen Datensatz zum Trainieren des Segmentierungsmodels generieren (und dann manuell verfeinern).

Der Datensatz besteht dann aus zwei Slippy Map Verzeichnisstrukturen mit Bildern und Masken. Die Slippy Map Verzeichnisstruktur hilft uns die Geo-Referenzierung der Bilder und Masken aufrecht zu erhalten, was wir spaeter benoetigen um von Pixel zurueck zu Koordinaten zu kommen. Allgemein ist die Slippy Map Verzeichnisstruktur die Hauptdatenstruktur in RoboSat: die meisten Tools transformieren eine Slippy Map Verzeichnisstruktur in eine Andere.

Danach trainieren wir das Segmentierungsmodel und speichern die besten Checkpoints. Wir haben die Segmentierungsmodelle in PyTorch implementiert und lassen sie auf AWS p2/p3 Instanzen, und einer GTX 1080 TI die unser Berliner Buero im Winter warm haelt, laufen.

Wenn wir dann die trainierten Modelle auf einer Slippy Map Verzeichnisstruktur von Luft- bzw. Satellitenbildern laufen lassen erhalten wir Wahrscheinlichkeiten fuer jeden Pixel in den Bildern:

Parkplatz Wahrscheinlichkeiten; Wahrscheinlichkeiten skalieren S-Komponente im HSV Farbraum

Diese Wahrscheinlichkeiten wandeln wir dann in Masken um, wobei wir Slippy Map Tile Grenzen und Wahrscheinlichkeiten von mehreren Modellen handhaben:

Masken fuer Slippy Map Tile Grenzen. Keine Tile Grenzen zu sehen? Perfekt!

Wir speichern sowohl Wahrscheinlichkeiten als auch Masken in optimierter Form als PNG Dateien mit einem einzigen Kanal und fuegen eine Farbpalette hinzu die es uns erlaubt diese Tiles direkt in einem Kartenlayer anzuzeigen.

Basierend auf den Masken entfernen wir dann Rauschen, fuellen kleinere Luecken, Extrahieren Kontouren und darauf aufbauend (Multi-)Polygone, die wir schlussendlich mittels Douglas-Peucker simplifizieren:

Masken, Rauschen entfernen, Luecken Fuellen, Kontouren Finden

Hier erlaubt uns die Geo-Referenzierung der Slippy Map Verzeichnisstruktur aus Pixel in Bilder GeoJSON Features mit Koordinaten zu generieren. Noch dazu verschmelzen wir Features ueber Tile Grenzen und de-duplizieren gegen OpenStreetMap Geometrien die bereits gemappt sind.

Als Resultat bekommen wir eine GeoJSON Datei mit simplifizierten (Multi-)Polygonen!

Hier ist eine Animation der Segmentierungspipeline:

Luftbilder, Wahrscheinlichkeiten, Masken, extrahierte Features, Features ueber Tile Grenzen

Ich sehe RoboSat als Baustein fuer mehrere Anwendungsfaelle und Projekte:

• RoboSat kann sich jede OpenStreetMap Aenderung in Echtzeit "ansehen" und potentielle Falsche Aenderungen markieren. Gleichzeitig koennen wir Aenderungen durch unsere Validierungspipeline durchlassen, fuer die RoboSat das Okay gibt.
• RoboSat kann eine Vollstaendigkeitsanalyse durchfuehren und uns sagen wie Vollstaendig OpenStreetMap in bestimmten Bereichen fuer bestimmte Features ist. Z.b. "Gebaeude in Bamberg sind zu 90% gemappt", und fuer die noch nicht gemappten Gebaeude Vorschlaege generieren.
• RoboSat kann in Platformen wir OpenAerialMap und Toolchains wir OpenDroneMap integriert werden um Minuten nach dem Drohnenueberflug eine automatische Auswertung zu generieren.

Wenn auch die Moeglichkeiten ohne Grenzen sind moechte ich festhalten, dass RoboSat weder fuer vollstaendig automatisches Mappen gedacht ist, noch dazu ausgelegt ist. Wir werden RoboSat als unterstuetzendes Werkzeug einsetzen, aber nicht fuer automatische Importe.

In den folgenden Monaten werden wir weiter in RoboSat investieren um mehr Features zu implementieren, wie z.b. Gebaeude und Strassen (was wir intern bereits haben; siehe Bilder oben), um Variationen in Bildqualitaet und Zoomlevels besser handzuhaben, und dabei sicher gehen dass RoboSat generisch und skalierbar bleibt.

Randbemerkung: Pratik hat vor Kurzem einen Diary Eintrag ueber die Nutzungsbedingungen von Mapbox Satellitenbilder fuer Machine Learning Use-Cases geschrieben. Fuer weitere Luftbilder rate ich einen Blick in die Wiki.

Ich bin offen fuer Feedback und konstruktiver Kritik; fuer Feature Requests, Ideen, oder Bug-Reports bitte ein Ticket im RoboSat Repository oeffnen! :)

Wer kann mir helfen? Warum sehe ich keine Orthofotos bei einem Zoomlevel von < 50m bei den Bildern von Digitalglobe? Was muss ich im JOSM einstellen/ändern? Ich kann so nichts einzeichnen.

Danke

Ich habe vor einigen Tagen in 72827 Wannweil ca 10 Korrekturen vorgeschlagen. Immer mit Hausnummern. Einerseits, Häuser die keine hatten bekamen eine Hausnummer Häuser die noch gar nicht eingezeichnet waren bekamen auch eine Hausnummer (logisch, dass dann das Haus noch irgendwie skiziert werden müsste).

Ich bekam heute die Bestätigung das die Hausnummer 2 hinzugefügt wurde, diese Änderung von mir angenommen.

Wie? Wieso ist alles? Oder kommen die andren Änderungen noch? Darüber wird diskutiert und nicht einfach von unsichtbarer Hand gelöscht? Richtig?

Hallo,

ich suche noch mitstreiter, die helfen wollen alle Hydranten bzw. das gesamte Löschwasserwesen auf dem Stadtgebiet in Singen zu erfassen.

Bei interesse einfach melden.

Gruss Ralph

• JOSM Plugin AustriaAddressHelper https://forum.openstreetmap.org/viewtopic.php?pid=694491#p694491
• JOSM Plugin Coloured_Streets https://forum.openstreetmap.org/viewtopic.php?pid=693213#p693213
• Basemap Overlay bmapoverlay https://forum.openstreetmap.org/viewtopic.php?id=61922
• Logitech G13 AddressHelper zu Adress Node Skript https://www.openstreetmap.org/user/wiki%20the%20map/diary/43339
• Overpass Turbo Bereinigungsabfrage doppelter Adressen Place und Street ohne Gewerbe: http://overpass-turbo.eu/s/yqI
• JOSM Overpass_API Filterregeln

Ref: https://forum.openstreetmap.org/viewtopic.php?pid=695091#p695091 Ref: https://forum.openstreetmap.org/viewtopic.php?id=62412

Jahre schon hat mich genervt, dass das tiles-laden bei der Bereichsauswahl extrem träge ist. Mehrere Anläufe, das zu beheben (cache vergrössern, an prefs rumdrehen etc.) scheiterten und nun eben wollte ich das nochmal angehen und finde das hier.

Das mit dem Lesezeichen hab ich weder verstanden, noch versucht, die beiden prefs gab es nicht. Die habe ich testweise mal gesetzt und siehe da: Bäm! Wie das flutscht! Maan!

P.s. was ich mich dabei eh schon immer fragte, ist, warum das Caching per Standard überhaupt so unaggressiv bzw. gefühlt überhaupt nicht vorhanden ist. Die Karte ist doch eh nur zum runterladen von Daten, da will ich doch nicht nachschauen, ob mein gestern eingetragener Hundekotbeutelspender sichtbar ist. Imho reichen da die Tiles von vor einer Woche oder einem Monat.

Im Folgenden beschreibe ich wie wir Alternativrouten in den Multi-Level Dijkstra Algorithmus der Open Source Routing Machine implementiert haben.

Endprodukt: effiziente und plausible Alternativrouten

Unser Fokus beim Designen und Implementieren von Alternativerouten lag dabei auf:

• hoch-qualitative Alternativerouten zu generieren: fuer den Endanwender und fuer Anwendungsfaelle die von vielen Alternativerouten profitieren koennen (z.B. eine Jogging-App bei der Start und Ziel ueber die Woche hinweg gleich bleiben aber die Route sich aendern soll), und
• gleichzeitig fuer schnelle Antworten der Routingengine garantieren zu koennen, die im Bereich von 10-100 ms liegen und damit in das Konzept der Open Source Routing Machine passen wobei pre-processing benoetigt wird aber dafuer extrem effizient und schnelle exakte Routen berechnet werden koennen.

Hier sind die Kriterien nach denen wir die Qualitaet der Alternativerouten beurteilen:

• die Alternativroute soll nicht laenger als x% verglichen zur schnellsten Route sein; das haengt natuerlich auch von der Laenge der Route ab (z.b. ist eine Alternativroute von 13 Minuten okay wenn die schnellste Route 10 Minuten betraegt; 13 Stunden Alternativerouten bei 10 Stunden schnellste Route ist nicht mehr okay fuer den Nutzer)
• die Alternativeroute soll sich um mindestens x% verglichen zur schnellsten Route unterscheiden
• die Alternativeroute soll "lokal optimal" sein: x% der Alternativerouten-Umweg ist wiederum eine schnellste Route

Wir koennen an diesen Parametern nun so drehen dass wir entweder Alternativerouten hoeherer Qualitaet bekomme oder generell mehr Alternativerouten potentiell schlechterer Qualitaet.

Was wir fuer diese Implementierung nicht betrachten:

• wir geben dem Nutzer keine explizite Mischung an Alternativerouten bestehend z.b. aus "Nutze Autobahn" und "Vermeide Autobahn". Dafuer gibt es ein unabhaengiges Feature in der Routing engine.
• wir geben dem Nutzer keine multi-metric Alternativerouten, also keine Alternativerouten basierend z.b. auf Zeit, Distance, und Aehnlichem. Die Alternativerouten basieren auf einer einzigen Metric die von den Profilen und Traffic Daten bestimmt wird.

Hier ist der grobe Ablauf beschrieben wir wir Alternativerouten mitterls der so genannten "Via-Methode" berechnen:

• starte die bi-direktionale Dijktra Vorwaertssuche von s; speichere alle besuchten Knoten
• starte die bi-direktionale Dijktra Rueckwartssuche von t; speichere alle besuchten Knoten
• wenn sich beide Suchraeume treffen (und die Suche normal abgebrochen werden kann, da eine schnellste Route gefunden wurde), lasse beide Suchen "ein bisschen" weiterlaufen
• schneide die zwei Mengen an Knoten: das sind die Knoten fuer die beide Suchraeume sich ueberlappen.
• fuer alle dieser Knoten c kann eine (potentiell schlechte) Alternativeroute erstellt werden ueber die Route (s, c, t)
• evaluiere und filtere diese Alternativerouten Kandidaten basierend auf den oben genannten Kriterien

Im Folgenden schoen zu sehen wie diese Alternativerouten Kandidaten aussehen:

Das Hauptproblem ist nun dass es etliche Alternativerouten Kandidaten gibt die gefiltert werden muessen.

Das Filtern muss also extrem effizient und schnell sein. Aus diesem Grund filtern wir schrittweise, von inexakten groben Filtern am Anfang die z.b. nicht die genaue Geometrie entpacken muessen, zu hoch-qualitativen Filtern die wegen Laufzeitbeschraenkungen auf nur noch wenigen Alternativerouten Kandidaten laufen koennen.

Die initialen Via-Knoten bekommen wir mittels Intertial Flow Graph-Partitioniers (osrm-partition). Der Graph-Partitioniere schneided den Graph rekursiv (und komplett parallelisiert) mittels Dinic's Min-Cut Algorithmus in zwei Stuecke.

Hier ist der Suchraum fuer eine Route Muenchen -- Berlin aus dem wir die Via-Knoten fuer die Alternativerouten Kandidaten entnehmen. Dank des Graph-Partitioniers wissen wir dass alle Routen durch diese Via-Knoten gehen muessen.

Wir koennen dann die untersten Level der Partition verwenden um Alternativerouten Kandidaten zu filtern die "zu aehnlich" sind, ohne dass wir die Geometrien der Routen entpacken muessen (was extrem teuer waere).

Ein weiteres Kriterium fuer die Qualitaet der Alternativerouten ist die so genannte Lokale Optimalitaet. Das Problem das Lokale Optimalitaet versucht zu loesen sind Alternativerouten die kurzfristig einen unzumutbaren Umweg nehmen. Das koennte beispielsweise so aussehen, dass die Alternativeroute von der Autobahn kurz ab geht, nur um dann kurz danach wieder auf die Autobahn zu gehen.

Um fuer Lokale Optimalitaet zu garantieren schauen wir uns die Routen um die Via-Knoten an und nutzen die Heaps der Forwaerts- und Rueckwartssuche um zu testen ob diese Routen selbst schnellste Routen sind.

Die lokale Route ist selbst optimal:

Erst jetzt entpacken wir die Geometrien der Alternativerouten-Kandidaten und ueberpruefen unsere Kriterien auf den detaillierten Routen.

Und zuletzt muessen wir diese Kriterien nicht nur zwischen der schnellsten Route und den Alternativerouten-Kandidaten ueberprufen, sondern sobald wir mehrere Alternativerouten gefunden haben gegen alle paarweise Alternativrouten selbst.

Probier's aus mit der Open Source Routing Machine - wir sind offen fuer Feedback!

Ein besondere Dank geht an Moritz Kobitzsch der eine grosse Hilfe war und mit seinem Doktor in Alternativrouten mit seinem Wissen extrem helfen konnte!

Mehr Details:

• Original ticket
• Original pull request
• Alternative Route Techniques, Moritz Kobitzsch
• Candidate Sets for Alternative Routes in Road Networks
• Algorithmen für Routenplanung: Alternativrouten
• Intertial Flow
• Interactive search space exploration

In der Adresserfassung entstandene Duplikate und Redundanzadressen findet man mit folgender OverPassTurbo Abfrage. http://overpass-turbo.eu/s/yWn

// Die Query findet Mehrfacheinträge von Hausnummern, berücksichtig addr:street, addr:place auf way's und Nodes. Mehrfach eingetragenes Gewerbe wird über eine Namensabfrage ebenfalls angezeigt. Bitte zur Vermeidung unnötiger Serverbelastung, den zu prüfenden Kartenausschnitt manuell festlegen, oder das Fenster nicht zu groß wählen.

Gefundene Duplikate auf Nebengebäuden können wir sofort entfernen. Wurde hingegen eine Nachbaradresse versehentlich als Duplikat gemappt, so setzt man anschließend dort eine Note dass diese Adresse fehlt. Noch besser man versucht die entdeckte Adresslücke sofort wieder mit der korrekten Adresse zu schließen.

Der OverpassTurbo Code kann übrigens auch direkt im Editor JOSM angewandt werden. (code Text ohne Tilen ~~~ in JOSM einfügen)

~~~ // Abfrage doppelter Hausnummern. Nodes und Gebäudepolygone ohne Adressen mit Namen oder Gewerbe. (addr:Place und addr: street wird berücksichtigt). Bitte zur Vermeidung unnötiger Serverbelastung, jeweils einen Kartenausschnitt manuell festlegen, oder das Fenster nicht zu groß wählen.

[bbox:{{bbox}}]; nwr["addr:city"]["addr:housenumber"]; for(t["addr:city"] + " " + t["addr:street"] + " " + t["addr:unit"] + " " + t["addr:flats"] + " " + t["addr:place"]+ " " + t["shop"] + " " + t["addr:housenumber"] + " " + t["name"]+ " " + t["amenity"]+ " " + t["shop"]) { if (count(nodes) + count(ways) + count(relations) > 1) { (._;>;); out meta;/fixed by auto repair/ } }; ~~~

Ref: https://forum.openstreetmap.org/viewtopic.php?pid=695091#p695091 Ref: https://forum.openstreetmap.org/viewtopic.php?pid=700118#p700118

Aus der Wochennotiz:

Bryan Housel, der Entwickler von iD, erklärt auf der Mailingliste Tagging, warum iD bis dato ungenutzte und bis heute undokumentierte Tags ohne Diskussion oder Proposal in seine Vorlagen aufgenommen hat. Der Vorgang findet kein großes Echo und eine Nachfrage, ob noch mehr Tags auf diesem Weg eingeführt wurden, bleibt unbeantwortet.

Kann man sich nicht ausdenken sowas.

Nach langem Hin- und Herüberlegen hab ich mich entschlossen den von mir eingetragenen Weg wieder rauszunehmen, Grund ist einzig allein das abgerutschte Stück, das nur noch recht gefahrvoll zu begehen ist. Was noch hinzu kommt: Dieses Stück ist wohl auch ständigen Veränderungen durch Ausspülung bei Starkregen unterworfen. Ich will dafür nicht die Verantwortung übernehmen. Natürlich könnte ich die Verantwortung auf die auf OSM basierenden Endprodukte (die Renderer) abschieben, denn wenn der Pfad /das kritische Stück überall korrekt wiedergegeben würde, könnte ich wohl damit leben. Ist aber nicht so. Für die meisten Apps/ auf OSM basierenden Karten ist es einfach ein stinknormaler Weg wie jeder andere. Das Kaisertal ist eine Tourismusregion und ich weiss um das Freizeitverhalten mancher Gäste, die einfach ihrem Smartphone nachgehen.

Und sagen wir mal so Besucher hat es geschafft sich bis zu diesem Stück vorzuarbeiten, kommt dann aber nicht weiter, muss er wieder Stunden zurückgehen oder weglos durch Steilgelände einen Abstieg versuchen. Bei anderen Wegen sind die Schwierigkeiten klar ersichtlich von Anfang an. Hier nicht so, obwohl auch schon im ersten Teil anspruchsvolle Passagen kommen.

Ich habe die Linie stehen gelassen, sollte der Pfad also ausgebessert werden kann man sie wieder verwenden.

Wer den Pfad trotzdem wieder einzeichnen will, bitteschön, aber nicht unter meinem Namen/Kürzel.

Warum ich mich immer so ärgere, wenn ich auf solche Kreuzungen treffe? Hier wurde doch alles richtig gemacht, oder? Alle Ways exakt in der Mitte des Straßenabschnittes, den sie repräsentieren, das Luftbild optimal nachgezeichnet.

Warum das doch nicht so optimal ist, sehen wir, wenn wir mal annehmen, wir kommen von Osten und wollen nach Norden. Für unser Navi sieht der Fahrweg so aus: Erst geht es scharf nach rechts, fünf Meter weiter ebenso scharf nach links. Nach diesem ersten Stunt wird ein erholsamer Bogen nach rechts gefahren, an dessen Ende es wieder scharf nach links und dann – jetzt noch eher und fast rechtwinklig – wieder scharf nach rechts geht. Dann noch eine harte S-Kurve mit zweimal 45° Richtungsänderung, und – puh! – wir können wieder durchatmen.

Sorry, das kann’s nicht sein. Real ist das mitnichten so ein vielkurviges Manöver. Real wird das Lenkrad einmal kurz und leicht nach rechts gedreht und dann wieder zurück. Mehr nicht.

In meinem Mappinstil sieht die Kreuzung so aus (bereits mit hervorgehobenen Fahrweg): Ist das nicht eher das, was auch wirklich gefahren wird? Drei kleine Knicke sind noch drin. Lassen sich kaum vermeiden. Aber insgesamt ist das IMHO so dicht wie möglich an der Wirklichkeit, solange wir Straßen als Linien abbilden, also deren Breite irgendwie vernachlässigen. Jedenfalls wird jetzt in OSM wie auch in echt die ganze Zeit sanft nach rechts gefahren, kein Zickzack. Gefällt mir wesentlich besser.

Das mache ich immer so, wenn ich mit einer Kreuzung fertig bin: Ich gehe alle möglichen Durchfahr- und Abbiegevorgänge durch und achte darauf, ob die so realitätsnah wie möglich abgebildet sind – keine zu spitzen Winkel, keine Linkskurven, wo nach rechts gefahren wird (wie oben, das gilt natürlich auch umgekehrt).

Ich höre schon zwei Einwände, deshalb nehme ich sie vorweg:

Die Ways der Rechtsabbiegerampen sind nicht in der Mitte!

Ja. Und? Müssen sie das? Auf der B 56 ist der Way auf der Mittellinie, da fahren wir auch die ganze Zeit fünf Meter daneben lang, ohne dass das jemanden stört. Warum soll das jetzt auf einmal schlimm sein? Hat dir dein Navi schon mal gesagt „Du fährst fünf Meter neben dem Way, fahr bitte fünf Meter weiter links!“? Quatsch. Dein Navi weiß, dass du auf einer Straße fährst, die eine Breite hat, und nicht auf einer Linie, von der du keinen Meter abweichen dürftest. Dein Navi denkt sich den OSM-Way auf deine seitliche Position.

Normalerweise lassen wir die OSM-Ways in der Straßenmitte laufen, richtig. Das ist auch gut so. Aber bei kurzen Abbiegerampen ist das für mich eine Frage der Kompromisse: Lieber lege ich den Way etwas daneben, als ihn in einer Form anbinden zu müssen, die mit dem tatsächlich gefahrenen Abbiegevorgang nicht mehr viel zu tun hat.

Wir müssen (und können!) gar nicht die geographische Lage des Fahrweges zentimetergenau abbilden. Das ginge nur mit einem Way pro Fahrspur. Wir sollten aber seine Form, seinen Verlauf, realistisch abbilden. Die Position der Abbiegung sollte in Vorne-Hinten-Richtung stimmen, damit das Navi im richtigen Moment „jetzt abbiegen“ sagen kann. Wo sie in Links-Rechts-Richtung sitzt, ist dem Navi dabei ziemlich wurscht. Muss es auch, wenn ein einziger Way eine Straße mit mehreren Spuren repräsentiert.

Deine Rechtsabbiege-Ways fahren über durchgezogene Linien, das darf man nicht!

Der erste Teil stimmt. Der zweite auch. Aber sie haben nichts miteinander zu tun! Der Way bedeutet ja nicht „Fahr exakt hier lang“. Wenn er das bedeutete, dann müssten wir vorher auch auf der Mittellinie fahren. Siehe auch letzte Antwort zum Thema exakte Lage.

Natürlich muss der Abbiegeway in OSM an dem Way ansetzen, auf dem man kommt. Aber man beginnt ja nicht auf dieser geographischen Position (also auf der Mittellinie der Straße) mit dem Rechtsabbiegevorgang, sondern viel weiter rechts, und deshalb muss man auch nicht über die durchgezogene Linie fahren, obwohl der Abbiegeway, der zwangsläufig weiter links ansetzen muss, das tut. Der Abbiegeway ist keine exakt festgelegte Fahrlinie, sondern eine abstrahierende Abbildung des Sachverhalts „hier zweigt die Abbiegerampe ab“, und diese abstrahierende Abbildung darf ohne Weiteres über durchgezogene Linien verlaufen. Nur Fahrzeuge dürfen das nicht, sie tun es aber auch nicht, weil sie sich den Abbiegeknoten einfach zehn Meter nach rechts denken, auf ihre seitliche Position.

TL;DR: Sollte ich dich nicht überzeugt haben, solltest du also weiterhin Abbiegerampen lieber mit kurzen, scharf abbiegenden Verbindungsstücken mappen, dann bitte ich dich, diese kurzen Verbindungsstücke (und nur die) mit placement=transition zu taggen, um maschinenlesbar klarzustellen, dass sie nur der datenlogischen Anbindung dienen und keine tatsächlich gefahrenen Wege darstellen.

hui, osmose überrascht mich ja immer wieder ... da änderst einfach mal eine verschobene Kreuzung in einer Stadt, und schwups haste (auch wenn man zunächst dafür selbst nicht verantwortlich ist) 15 Fehler/Warnungen mehr in deiner Liste ...

Hier geht's speziell um den Werratal-Radweg, welcher klar als route=bicycle getaggt ist ... aber manche Wegabschnitte führen über nicht für Fahrrad zugelassene Wege (z.B. diese Brücke mit DE:239, sprich schieben wäre angesagt. Deshalb könnte man einfach mal her gehen und all diese Fehler als "false/positive" melden, oder?

Naja, so einfach ist es ja dann doch nicht. Ich habe mir mal erlaubt die PDFs und GPXs (die wir ja leider nicht primär nutzen dürfen) für den Bereich meiner eigentlich Änderung anzusehen und siehe da, teils mehr als 100m Abweichung. Es schaut fast so aus, als hätten ein paar der Vormapper dieser Relation bewusst eine Stadtführung quer durch die Innenstadt und Fussgängerzone als Sightseeingelement mit eingebaut (sogar teilweise auch noch als role=alternative), die im Original so gar nicht vorgesehen/ausgezeichnet ist.

Hat jemand Lust, den Werratal-Radweg von Anfang bis Ende der offiziellen Beschilderung zu folgen, als GPX aufzuzeichen und zu teilen?

PS: Crossposting im deutschen Forum, falls jemand (mit-)diskutieren möchte.

… es ist mal wieder soweit. Neun lange Jahre bin ich nun schon dabei und immer noch macht es Spaß seine Umgebung auf diese etwas „Andere“ Art kennen zu lernen. Auch wenn aus der Umgebung zwischenzeitlich schon eine kleine Welt geworden ist. Leider sind die Highlights von denen ich hier zu berichten habe, in den letzten Jahren immer weniger geworden.

Zuerst einmal möchte ich mich für die Tipps und Hinweise bezüglich der Seite „Lustige Sachen“ bedanken. Leider haben diese allerdings nicht geholfen. Nun aber zu den Dingen, die mir sonst so aus dem letzten Jahr in Erinnerung geblieben sind.

Es war im Mai, da war ich mal wieder in meiner näheren Umgebung unterwegs, wo ich feststellen musste, dass es hier noch ein Wasserpumpe (eine sogenannte Berliner Plumpe) gibt, die noch nicht in OSM erfasst war. Ich konnte es kaum glauben, denn neu war sie hundertprozentig nicht. Sicher war auch dies ein Grund, warum ich mal meine alten POI bemühte und siehe da, ich fand sie bestimmt fünf Mal. Was ich bis heute nicht weiß, hat sie immer mal wieder jemand gelöscht oder hatte ich sie wirklich nie eingetragen. Das Alter, man vergisst so viel ;-). Seit Mai werfe ich deshalb in unregelmäßigen Abständen immer mal wieder ein Auge auf das Objekt.

Im Sommer war ich unterwegs und wollte die eine oder andere Werbetafel erfassen. Dabei fiel mir auf, dass sich die Zeiten ganz schön verändert haben. Wo früher Autohersteller Ihre Luxuskarossen anboten, kommen einem heute Sprüche von einem namhaften Erotik-Versand entgegen, so zum Beispiel: „Alles für`n Arsch“. Einige Schritte weiter wird mir auf einem sich drehenden Werbewürfel eine kostengünstige Vasektomie, gleich in der Nähe, angeboten. Nach einer kurzen 90 Grad Drehung zeigt mir der gleiche Würfel auch gleich das „passende Versteck“ in dem ich die neu gewonnene Freiheit gleich ausleben kann :-).

Im September hatte ich allerdings auch ein negatives Erlebnis. Zumindest aus meiner Sicht. Wir waren ein paar Tage am Bodensee und somit auch in der Schweiz und Österreich und ich habe keine „Beute“ in Form von POI mitgebracht. Ein wenig schäme ich mich heute noch dafür. Wenigstens ein Briefkasten oder Mülleimer hätte schon drin sein müssen. Also ärgern, ärgern ärgern …

Kurze Zeit später musste ich auch noch mein gutes altes Smartphone gegen ein Neues austauschen. Ich wurde zwar schon eine ganze Zeit belächelt, wenn ich mein fünf Jahre altes Handy aus der Tasche zog. Doch nun war ein Tausch unausweichlich, da kaum noch eine App flüssig auf dem Ding lief. Selbst bei OsmAnd durfte ich nur noch ganz ganz langsam laufen.

Das war es auch schon. Ich werde mich nun auf mein zehnjähriges Jubiläum vorbereiten und verbleibe wie immer bis zum nächsten Jahr hier oder irgendwann in freier Mapper-Wildbahn :-) .

Hallo meine Anfängerfrage !!! Ich versuche mehrere Marker in meine Karte zu setzten und dann verschiedene URL s aufzurufen. Leider fehlen immer verschiedene Marker sporadisch, wenn ich einen neuen Marker einsetze.

Kann mir da geholfen werden !!, nachfolgend mein Code.

Vielen Dank für die Hilfe und Grüße von Günter.

  <!-- div-Element für die Karte einrichten --> var map = L.map('map').setView([1, 1], 1); L.tileLayer('https://{s}.tile.openstreetmap.org/{z}/{x}/{y}.png', { attribution: '© OpenStreetMap contributors' }).addTo(map); var renate = L.marker([1.284990, 103.859305]).addTo(map); renate.bindPopup("Die schönen Momente in Singapore, SingaporeGehe nach Singapore.").openPopup(); // standalone popup //var popup = L.popup() //.setLatLng([1.284990, 103.859305]) //.setContent("Nach Singapore") //.openOn(map); var renate3 = L.marker([47.421994, 10.985362]).addTo(map); renate3.bindPopup("Die schönen Momente in den AlpenGehe zu Impressionen.").openPopup(); // standalone popup //var popup = L.popup() //.setLatLng([47.421994, 10.985362]) //.setContent("Die schönen Momente") //.openOn(map);

var renate1 = L.marker([-22.951590,-43.210487]).addTo(map);
renate1.bindPopup("<b>Die schönen Momente in Brasilien, Rio de Janeiro</b><br><a href='http://www.luhtravel.de/Impressionen/index.html'>Gehe zu Impressionen Singapore</a>.").openPopup();
// standalone popup
//var popup = L.popup()
//.setLatLng([-22.951590,-43.210487])
//.setContent("Die schönen Momente in Rio de Janeiro")
//.openOn(map);
var renate2 = L.marker([40.701519,-74.009226]).addTo(map);
renate2.bindPopup("<b>Die schönen Momente in USA, New York</b><br><a href='http://www.luhtravel.de/Impressionen/index.html'>Gehe zu Impressionen USA</a>.").openPopup();
// standalone popup
//var popup = L.popup()
//.setLatLng([40.701519,-74.009226 ])
//.setContent("Die schönen Momente in USA New York")
//.openOn(map);
var renate4 = L.marker([13.764063, 100.495377]).addTo(map);
renate4.bindPopup("<b>Die schönen Momente in Bangkok</b><br><a href='http://www.luhtravel.de/Impressionen/index.html'>Gehe zu Impressionen</a>.").openPopup();
// standalone popup
//var popup = L.popup()
//.setLatLng([13.764063, 100.495377])
//.setContent("Die schönen Momente")
//.openOn(map);
var renate6 = L.marker([37.825235, -122.478114]).addTo(map);
renate6.bindPopup("<b>Die schönen Momente in,San Francisco</b><br><a href='http://www.luhtravel.de/Impressionen/index.html'>Gehe zu Impressionen San Francisco</a>.").openPop();
// standalone popup
//var popup = L.popup()
//.setLatLng([37.825235, -122.478114])
//.setContent("Die schönen Momente in San Francisco")
//.openOn(map);
    var renate5 = L.marker([21.196468, 94.848871]).addTo(map);
renate5.bindPopup("<b>Die schönen Momente in Myanmar, Bagan</b><br><a href='http://www.luhtravel.de/Impressionen/index.html'>Gehe zu Impressionen Myanmar</a>.").openPop();
// standalone popup
//var popup = L.popup()
//.setLatLng([21.196468, 94.848871])
//.setContent("Die schönen Momente in Myanmar Bagan")
//.openOn(map);

renate6.bindPopup("<b>Die schönen Momente in,San Francisco</b><br><a href='http://www.luhtravel.de/Impressionen/index.html'>Gehe zu Impressionen San Francisco</a>.").openPop();
// standalone popup
//var popup = L.popup()
//.setLatLng([37.825235, -122.478114])
//.setContent("Die schönen Momente in San Francisco")
//.openOn(map);