Jeder Mapper kennt das: Auf der grünen Wiese wird gebaut. Ob Supermarkt oder Wohnsiedlung, die Gebäude wollen erfasst werden. Sie sind garantiert auf keinem Luftbild zu sehen, sollten aber in die Datenbank, möglichst positionsgenau. Wie machen wir das?

Wie schön wäre es, man könnte einfach mit laufendem GPS-Tracking das Gebäude entlang seiner Außenwände umlaufen und hätte den exakten Umriss. Aber der nicht mehr ganz grüne Mapper weiß: Das geht nicht. Abgesehen davon, dass kein Bauleiter es gern sieht, wenn irnkwelche Leute auf seiner Baustelle rumlaufen, wird das auch messtechnisch nichts. Gerade das Gebäude, das wir vermessen wollen, stört den Empfang so stark, dass die Spur wild von links nach rechts springt und nicht zu gebrauchen ist. Das können wir vergessen.

Ich vermesse so was anders: mit Fluchtlinien.

Beispiel: Wir nehmen an, auf diesem Acker werden zwei Marktgebäude errichtet. Erstmal nehme ich Fotos von der Baustelle auf, um eine grobe Vorstellung zu haben (die kann ich hier nicht zeigen, weil es die Baustelle nicht gibt).

… See full entry

Ich habe in letzter Zeit viel über die Datenqualität bei Open Street Map gelesen. Es gibt sehr viele Möglichkeiten die Qualität aufgrund verschiedener Werte, Ziele, Erwartungen und Zusammenhänge zu messen, die wir als Benutzer haben, wenn wir mit Open Street Map arbeiten.

Mich beschäftigt vor allem die Frage, aus welchem Grund genau Open Street Map für wen und in welcher Situation nützlich wird. Könnt ihr mir das beantworten?

Beim Updaten “meiner” Statistiken fiel mir eine kleine Diskussion zu minspeed wieder ein, und, dass ich es für sehr unzufriedenstellend halte, dass wir hier ein Tagging haben, was für 2 völlig unterschiedliche Sachverhalte herhalten muss:

• Mindestgeschwindigkeit, die gefahren werden muss (beschildert mit Zeichen 275) oder (!):
• Mindestgeschwindigkeit, die bauartbedingt gefahren werden kann (implizit bei Autobahnen)

Wikipedia beschreibt imho richtig:

Auf Autobahnen und Kraftfahrstraßen bzw. Autostraßen gibt es keine Mindestgeschwindigkeit, soweit eine solche nicht durch ein entsprechendes Verkehrszeichen angeordnet ist. 
Zwar dürfen Autobahnen und Kraftfahrstraßen/Autostraßen nur von Kraftfahrzeugen bzw. Motorfahrzeugen benutzt werden, [...] eine Vorgabe, wie schnell tatsächlich zu fahren sei, ist damit jedoch nicht verbunden. 

Damit die Statistik nicht zu kurz kommt: - minspeed kommt in aller Regel im Rudel mit bicycle, foot, horse und access daher. Leider wird immer snowmobile, boat, ski und dergleichen vergessen.

Ich prangere das an!!111eins

www.vag-freiburg.de - anders als freimobil.com nun mit Kartenmaterial von Openstreetmap.

Und auch keine Tracker mehr, keine Webfonts (oder blockiere ich die und seh das dann nicht)? in puncto Datenschutz state of the art, indem viel unnützes Zeugs nun weg ist.

Ich bin positivst überrascht.

Neulich so: ÖPNV im Ort schreibt mir per OSM, ob ich Bock hätte, die zu einem bestimmten Problem zu beraten und mir mal deren IT/Routing-Lösungen anschauen mag. Ich so: Geil!

Heute hatte ich einen Termin, und das war sehr fruchtbar. Das Letzte zuerst: mein Ansprechpartner hat mir zugesichert, einen riesigen Sack voll Daten bei mir abzukippen unter der vorläufigen Abmachung, diese nur zum Vergleich zu verwenden, aber er die uneingeschränkte (OSM)Nutzung erfragt. Uneingeschränkte Nutzung der Daten ist kompliziert, da es da schon diverse Neins gab.

Die Neins wurden erklärt, dass die Entscheider Probleme damit haben, dass die Routen etc. fehleranfällig wären. (Konkret ging es dabei allerdings um die Fahrpläne, nicht die Routen)

Das zweitletzte als nächstes: Routenrelationen interessiert den ÖPNV (bzw deren Software) aktuell überhaupt nicht. Die Software (trapeze group/LIO) nutzt OSM für proprietäres Routing, die eigentlichen Routen kommen (wenn ich das richtig verstanden habe) per kml rein.

Die Beratung, nunja, die war recht kompliziert. Also nicht die Beratung, sondern die Software. Die sah so nach 100.000+ Euro aus, klar, dass die Scheisse ist. Ich hab mir die Routing-Software angeschaut und erklären lassen, und da gabs diverse Dinge am Routing.

• Wenn jmd. (in OSM) irgendwo eine Baustelle aufmacht und eine Umleitung erstellt, dann ist das ganze System kaputt. Das GPS der Busse ist fest mit der Route der Busse verknüpft und wenn die Stadt und OSM sagt: da ist eine Baustelle und DA ist eine Umleitung, dann kollabiert das, weil die (über OSM liegende) kml sagt: wir sind hier falsch.
• das wirklich schlimme dabei: das trapeze/LIO-dingens ist eine enterprice-suite und funktioniert scheinbar auch so. Wenn die per GPS überwachte OSM-Route nicht mit der KML übereinstimmt, dann hat der Bus weder Einnahmen-statistik noch Ansagen auf dem Passagierdisplay.

P.s. Ich fand das Treffen sehr angenehm

hat sich da schon mal wer ausgekotzt?

Aufgefallen ist mir, dass auf Bing Maps Tonnen an Wegen nicht vorhanden sind.

Bilder sagen mehr als 1000 Worte:

https://binged.it/2Sz5v8L

vs

osm.org/directions?engine=graphhopper_foot&route=50.98200%2C11.35230%3B50.98250%2C11.37810#map=15/50.9822/11.3653

Das Beispiel hab ich rausgesucht, weil hier ein Weg in der Ansicht ist, der (in OSM) die identischen Eigenschaften mit einem Weg hat, der nicht in der Ansicht ist (auf Bing direkt rechts von A fehlt dieser)

Hat da jmd. nen Reim drauf? Warum werfen die Wege weg? Ich sehe in meinem Extrembeispiel nichts, was das rechtfertigen könnte. (und bei allen anderen Wegen auch nicht.)

Die OSM-Daten da sind meiner Einschätzung recht frisch, im schlimmsten Fall 2 Jahre alt.

P.s. Ich finds total dufte, dass MS unsere Daten verwendet, aber in DER Art ist das doch eine Katastrophe?!

Ich schreib das mal lieber deutsch, damit es keine internationalen Verwicklungen gibt ;-)

Als ich einen Kartenausschnitt als Collada-File aus Maperitive exportieren wollte, da klappte das nicht. Im Text unter dem Kartenausschnitt sah ich dann den mutmaßlichen Grund: da stand nicht “Austria” sondern “Australia” ! Die Koordinaten waren aber in Ordnung.

https://www.deepl.com/de/translator

May I sell self-designed T-shirts showing maps from Openstreetmap?

Wie schon bei den Kartenstilen, geht man hier ähnlich vor: Inhalt in einer Datei mit Endung .xml speichern. JOSM starten, F12 drücken, Gitter-Icon wählen und dann Objektvorlagen wählen und die Datei einlesen. Um den folgenden Code zu verstehen, mir ist das noch nicht ganz gelungen, sollte man sich mit https://josm.openstreetmap.de/wiki/TaggingPresets#name_templatedetails beschäftigen.

Die Vorteile sind:

• bei allen Fahrradknotenpunkten wird jetzt die id durch den Text Knoten mit den Inhalten der Tags ref und name angezeigt.
• bei allen Routenrelationen wird der Inhalt von network, gefolgt vom Inhalt von ref angezeigt. Damit lassen sich Routen, die von einem bestimmten Knoten ausgehen, leichter finden.

Der Code:

<!-- ACHTUNG: nach Aenderung ist Neustart von JOSM notwendig? -->
     <presets>
     <item name="Cycle Node Network" type="relation"
	    name_template="route(?{'{network} '}!{parent() type=network(network=rcn)'?{'{ref}' | ''}'}?{'{ref} '}?{'{note} '}?{'{name}'}"
	name_template_filter="type=route (route=bicycle)">
     </item>

 <item name="Node Network node" type="node"
	name_template="Knoten {rcn_ref} {name}"
	name_template_filter="type:node rcn_ref">
 </item>

 </presets>

Über Edit Help in JOSM bin ich auf weitere nützliche Dinge gestoßen, die mir das Editieren von Fahrradknotenpunktnetzen in JOSM erleichtern.

Hierzu den folgenden Code in einer Datei abspeichern, JOSM starten, F12 drücken, danach das Gitter-Icon auswählen und auf den Tab Kartenstile wählen und die Datei einlesen. Ganz Eilige können auch den Kartenstil “Numbered Cycle Node Networks” von [Polyglot] (osm.org/user/Polyglot) nutzen. Ich habe den Code als Grundlage für die folgenden Zeilen genutzt. Hiermit werden die Routen des Knotennetzes hervorgehoben, die Knoten größer und mit Knotennummern angezeigt.

node[rcn_ref] 
 {text-color: green;
  font-size: 17;
  text: rcn_ref;
  text-halo: #aaffcc;
  text-halo-radius: 2;
  text-position: right;}

relation[type=network][network=rcn] > node
 {text-color: red;
  font-size: 17;
  text: rcn_ref;
  text-halo: #aaffcc;
  text-halo-radius: 2;
  text-position: right;}

relation[type=network][network=rcn][cycle_network="radrevier.ruhr"] > node
 {text-color: white;
  font-size: 17;
  text: rcn_ref;
  text-halo: #aaffcc;
  text-halo-radius: 5;
  text-position: right;}

Ich bin am Tagging von Knoten und Routen in der Relation: Knotenpunktsystem radrevier.ruhr in OSM interessiert.

Zur Qualitätssicherung verwende ich: https://knooppuntnet.nl/en/network/7592211 Die Regeln zur Prüfung verwenden das Taggingschema, das in den Niederlanden und Belgien verwendet wird.

Anmerkung: in den Niederlanden wird bei Routen note=xx-yy verwendet. Wir verwenden hierzu in der Regel ref=xx-yy. Wenn knooppuntnet.nl kein note=xx-yy findet, wird in der Liste der Routen als Name “no-name” angegeben. Das ist aber nicht weiter kritisch, denn die anderen Meldungen helfen, das Netz zu verbessern. Bei radrevier.ruhr sieht das so aus: https://knooppuntnet.nl/en/network-facts/7592211. Danke Marc!

Gut gefällt mir auch die Übersichtskarte des Netzes: https://knooppuntnet.nl/en/network-map/7592211

Und hier derjenige, der die Website entworfen hat: osm.org/user/vmarc

Mir hat das sehr geholfen und auch viele Anregungen gegeben.

There is a big construction in Málaga Centro.

I mapped the positions of bus-stations two weeks ago

Alternative Link of map: osm.org/#map=18/36.71740/-4.42329

there is many work to rebuild the bus-relations and please control my definitions.

look at osm.org/changeset/64898122#map=16/36.7153/-4.4250

regards Jan

Bilder sagen mehr als tausend Worte:

Ok, doch paar Worte: das rote im Süden ist eine Bundesstrasse, das “andere” im Osten ist eine kleine Gasse, die von und zur Uni hin/wegführt.

Hallo,

ich lade alle, die - im Gegensatz zu mir - Erfahrung mit administrativen Grenzen in OpenStreetMap haben, ein, die Grenzen von Frankfurt am Main zu validieren.

Hintergrund:

Nachdem in der Note osm.org/note/1572377 (die leider bisher nicht gelöst ist) darauf hingewiesen wurde, dass von der Stadt Frankfurt ein Datensatz zu den Stadtteilgrenzen in Frankfurt bereit steht, wurde ich neugierig. Bisher hatte ich mich weder mit Shapefiles noch mit Verwaltungsgrenzen beschäftigt. Also habe ich mir das ganze mal angeschaut und bin auf einige Abweichungen der OpenStreetMap-Daten im Vergleich zu dem genannten Datensatz (http://www.offenedaten.frankfurt.de/dataset/frankfurter-stadtteilgrenzen-fur-gis-systeme) gestoßen. Nach einer kurzen Nachfrage bezüglich der Kompatiblität der Lizenzen wurde ich auf osm.wiki/Frankfurt_am_Main/amtliche_Daten_f%C3%BCr_OSM und https://forum.openstreetmap.org/viewtopic.php?id=63700 verwiesen.

Das Anpassen der Stadtteilgrenzen selbst war recht reibungslos, soweit ich das beurteilen kann. Nur an der Nidda musste ich teilweise die Grenzen von der Nidda trennen. Ansonsten gab es kaum Überschneidungen mit anderen Wegen/Straßen/…

Daraus wurde schließlich osm.org/changeset/64667223 und osm.org/changeset/64745199

Über Kommentare in den Änderungssätzen freue ich mich. Vielen Dank.

Im deutschen OSM-Forum hat Benutzer Jochen Kern neulich beschrieben, warum er Multipolygone für die bessere Art der Flächenerfassung hält. Da es die Diskussion dort zu arg auseinanderführen würde, lagere ich meine Erwiderung mal hierher in meinen Benutzer-Blog aus.

Flächen und Flächengrenzen der Realität sind hingegen kontinuierlich, sie fließen ineinander über, selbst dort wo der Mensch Anlagen installiert, um sie sichtbar bzw. unüberwindbar werden zu lassen. Multipolygone werden diesen Aspekt in besonderem Maße gerecht, weil sie diese Beziehungen von Flächen der Realität unmittelbar abbilden.

Dass zwei Flächen aneinander grenzen, lässt sich auch ermitteln, wenn die beiden als geschlossene Ways gemappt sind und sich die Nodes teilen. ST_Intersection der beiden ist dann ein LineString oder MultiLineString. Das OSM-Datenmodell ist für Analysen nur sehr eingeschränkt geeignet, weil es sehr viele JOINs erfordert. Um die Geometrie (Koordinatenliste) eines Ways zu erhalten, muss man in einer zweiten Tabelle die Koordinaten der Nodes nachschlagen. Um die Geometrie einer Multipolygonrelation zu erhalten, muss man zuerst die Ways in der Tabelle der Ways nachschlagen, dann deren Nodes in der Tabelle der Node nachschlagen. Das kostet Performance und aus diesem Grund hat sich für fast alle Anwendungen von OSM-Daten der Simple-Features-Ansatz durchgesetzt, bei dem Linien und Flächen keine Liste an Punkt-IDs, sondern direkt eine Liste der Koordinatenpaare haben.

Der Grund, warum unser Datenmodell praktisch nicht zur Analyse genutzt wird, ist eigentlich nicht, dass es schon in den OSM-Anfangstagen Open-Source-GIS-Software gab, die nach dem Simple-Features-Modell gearbeitet hat, sondern dass der Wechsel von einem Knoten-Kanten-Modell zu einem Simple-Feature-artigen Modell in der GIS-Welt schon vor 20 Jahren (oder etwas länger) erfolgt ist, weil es schlicht und einfach praktische Gründe gibt, eine Abstraktionsebene weniger zu haben.

… See full entry

Ich hab mich die letzten Tage mit Notrufsäulen an den Autobahnen in Thüringen beschäftigt und dabei ist mir aufgefallen, dass zum einen diverse gefehlt haben und zum anderen es gar nicht so schwer ist, diese zu finden. (Also “diese”, die hier in mein spezielles Sieb fallen)

Meine Vorgehensweise:

Ich hole mir via overpass alle Notrufsäulen im Abstand von max 100m zu einer bestimmten Autobahn. Die “laufe ich dann ab” verschiebe die an die nach Luftbild und/oder Mapillary richtige Position. “Alleinstehende” Säulen sind bei dieser Methode ein gutes Indiz, dass dort eine fehlt:

… See full entry

Zu Herzogtum Lauenburg

## Ratzeburger Umland und Dörfer. Sehr interessant ist es, dass ich wieder einige Waldwege gefunden habe, die schon mehr als 20 Jahren gibt, die aber nicht offiziell kartiert sind und das sogar bei allen bekannten Kartendiensten. Selbst die Wanderkarten an Waldwegen zeigen keine Informationen. Demnächst werde ich wieder auf Tour gehen und die Wege tracken.

Warum löschen wir nicht einfach alle Daten, dann meckert auch kein Validator mehr?

Ich geb’s zu: früher verklebte ich reichlich Straßen und Flächen, und als ob das nicht genug wäre, ich hatte in einigen Gegenden wie am Kaiserstuhl und im Glottertal auch schon mal versucht, Flächen in Relationen zu packen.

Mein Sündenregister ist bei 10 Jahren als aktiver Mapper und angesichts der Masse meiner Edits ziemlich groß.

Seit einigen Jahren habe ich meine Meinung zum Verkleben aber geändert und trenne landuse und Wege, habe aber nach wie vor einen horror vacui…

Ich drösele das daher auch ab und an auch schon auf, hab aber noch viel zu tun und es ist keinesfalles meine oberste Priorität, das Sündenregister nun besonders schnell abzubauen. Es gibt nämlich noch so viele unerfasste Adressen auch in Deutschland, dass ich mich bei diesem Streit frage, ob man nichts Besseres zu tun hat…

Nein, liebe JOSM-Programmierer, das ISO-Kürzel gsw steht nicht ausschließlich für Schweizerdeutsch, sondern auch für die im Aussterben befindlichen Dialekte “Elsässisch” und “Alemannisch” in Frankreich und Deutschland. Diese gehören nämlich linguistisch zur selben Dialektfamilie. Diese in JOSM vorgenommene Verengung des Begriffs gsw finde ich etwas verstörend.

Oder um’s uf gsw z’schribe: Nai, liebi JOSM-Programmierer, s’ISO-Chirzel gsw stoht nit usschliesslig fier Schwizerditsch, sundern au fier d’Dialekt “Elsässisch” un “Alemannisch” z’Frankrich un z’Ditschland, wo am Ussterbe sin. Sälli ghöre nämlig zue dr selbe Dialektfamilie. D’Verengig vum Begriff gsw, wie si im JOSM gmacht worre isch, duet mi ewengili verstöre.

name:gsw is daher linguistisch korrekt der Sprachcode, den man im Elsass für die elsässischen Ortsnamen benutzen muss, die an vielen Ortsschildern nun zusätzlich zum amtlichen Namen angebracht sind, (z.B. Schalampi bei Chalampé. Dort heißt die “Avenue de la République” auf Elsässisch übrigens “Kenigswag”, also “Königsweg”: Honni soit, qui mal y pense ;-)

Aber wie ich sehe: Die Blogsoftware hier macht es richtig. Gleichwohl ich annehme, dass den meisten Deutschschweizern es unbekannt sein dürfte, dass einheimische Schwarzwälder sie möglicherweise besser verstehen, als ihnen lieb sein kann…