OpenStreetMap

Diary Entries in German

Recent diary entries

Für wen und in welcher Situation genau wird Open Street Map nützlich?

Posted by larsmi on 16 January 2019 in German (Deutsch)

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?

minspeed...

Posted by MKnight on 3 January 2019 in German (Deutsch)

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

und wieder mal die VAG

Posted by q_un_go on 23 December 2018 in German (Deutsch)

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.

Location: Gewerbegebiet Haid, St. Georgen, Schlatthöfe, Freiburg im Breisgau, Regierungsbezirk Freiburg, Baden-Württemberg, 79111, Deutschland

ÖPNV vs OSM vs Realität

Posted by MKnight on 13 December 2018 in German (Deutsch)

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

Bing Maps Fussgängerrouting auf OSM-Daten...

Posted by MKnight on 4 December 2018 in German (Deutsch)

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

https://www.openstreetmap.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?!

Austria vs Australia in Maperitive

Posted by goiserer on 2 December 2018 in German (Deutsch)

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

JOSM OpenStreetMap, editing using a gaming mouse

Posted by addresshistory*org on 2 December 2018 in German (Deutsch)

Gaming hardware improves speed and precision. Use also gaming hardware, so OpenStreetMap gets better. https://youtu.be/TJtHlC0qVew

Ref: https://addresshistory.wordpress.com/2018/12/04/empfehlung-besseres-mappen-mittels-gaming-hardware/

JOSM, ungewolltes Auslösen der Funktion (Automatisches Zentrieren)

Posted by addresshistory*org on 1 December 2018 in German (Deutsch)

Manchmal kommt man als JOSM Anwender in die Situation, dass sich scheinbar wie aus dem Nichts bislang unbekannte Funktionen aktivieren. So verfolgt mich seit Jahren wiederholt ein sehr lästiges Phänomen. Plötzlich verschiebt sich beim Zeichnen von Linien, der Kartenhintergrund, Auslöser scheinbar willkürlich. Bislang habe ich mir nur nur so zu helfen gewusst, indem ich JOSM jeweils komplett deinstalliert, und anschließend wieder Neu installiert habe. Bei der JOSM Apple Version hilft ein Deinstallieren auch nichts, hier hat bislang nur das Rücksetzen sämtlicher JOSM Einstellungen geholfen. Nach gefühlt der fünfzehnten JOSM Neu Installation, bin ich nun diesem Phänomen genauer nachgegangen, und bin auf eine JOSM Tastenkombination Strg+Umschalt+F gestoßen, diese Funktion aktiviert ein automatisches Nachführen des Arbeitsbereiches (Auto Center), und lässt sich durch erneutes Betätigen der Tastenkombination Strg+Umschalt+F wieder ausschalten. Warum sich diese Funktion immer wieder von selbst aktiviert, ist mir ein Rätsel, ich habe dieses Problem für mich nun erkannt und gelöst, aber vielleicht geht es anderen Usern ebenso wie mir. Daher mein Impuls diese Erfahrung in meinem Blog zu veröffentlichen.

Wie üblich: bitte hier auf die Kommentar Funktion verzichten. Wer möchte, kann mir eine Nachricht senden, oder meinen Blog im OSM- Forums Bereich kommentieren.

Maps of Openstreetmap on T-Shirts

Posted by Obelixx on 30 November 2018 in German (Deutsch)

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

radrevier.ruhr: Eingabehilfen in JOSM 2. Teil: Namen statt OSM-ids

Posted by hfwri on 28 November 2018 in German (Deutsch)

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>

radrevier.ruhr: Eingabehilfen in JOSM 1. Teil: grafische Darstellung

Posted by hfwri on 28 November 2018 in German (Deutsch)

Ü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] (https://www.openstreetmap.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;}

radrevier.ruhr: mein Anfang

Posted by hfwri on 28 November 2018 in German (Deutsch)

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: https://www.openstreetmap.org/user/vmarc

Mir hat das sehr geholfen und auch viele Anregungen gegeben.

Bus-Stations in Málaga Centro

Posted by Lübeck on 26 November 2018 in German (Deutsch)

There is a big construction in Málaga Centro.

I mapped the positions of bus-stations two weeks ago

Map of Málaga Centro

Alternative Link of map: https://www.openstreetmap.org/#map=18/36.71740/-4.42329

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

look at https://www.openstreetmap.org/changeset/64898122#map=16/36.7153/-4.4250

regards Jan

Spass mit Mapillary...

Posted by MKnight on 24 November 2018 in German (Deutsch)

Bilder sagen mehr als tausend Worte: [Mapillary-"Pfad" an der Uni] (https://www.picflash.org/viewer.php?img=v15azkq6ye60kpe.png)

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.

Stadtteilgrenzen in Frankfurt am Main

Posted by Nmxosm on 23 November 2018 in German (Deutsch)

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 https://www.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 https://wiki.openstreetmap.org/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 https://www.osm.org/changeset/64667223 und https://www.osm.org/changeset/64745199

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

Location: Innenstadt, Altstadt, Frankfurt am Main, Regierungsbezirk Darmstadt, Hessen, 60311, Deutschland

Sind Multipolygon-Relationen besser? – eine Erwiderung auf einen Forenbeitrag

Posted by Nakaner on 22 November 2018 in German (Deutsch)

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.

Es gibt Diskussionen und mehr als nur absolut vage [1] Pläne, mittelfristig den Datentyp Node teilweise abzuschaffen, damit Ways nur noch eine Liste an Koordinatenpaaren enthalten. Im Zuge dieser Diskussion sind auch Entwickler von Software für verschiedene OSM-Anwendungsfälle gefragt worden, ob sie Nodes überhaupt brauchen. Mir ist keine Antwort bekannt, in der die teilweise Abschaffung der Nodes eine Anwendung verunmöglichen oder sehr erschweren würde. Das zeigt doch, dass unser eigenes Datenmodell nur für die OSM-API-seitige Datenhaltung taugt und praktisch alle anderen Anwendungsfälle aus guten Gründen auf die OSM-Komplexität verzichten können, oder?

Die Nichtnutzung des OSM-Datenmodells für Analysen zeigt, dass dein Argument, man könne mit Multipolygonen die Beziehungen zwischen Flächen ermitteln, keine Bedeutung hat. In den gebräuchlichen Datenhaltungen von OSM-Anwendungen, für die nachbarschaftliche Beziehungen relevant sind, hat eine Fläche keine Liste an Mitglieder-Ways. Außerdem ist eine rein koordinatenbasierte Nachbarschaftsanalyse robuster, wenn ein Mapper für zwei aneinander grenzenden Flächen keine gemeinsamen Nodes verwendet oder absichtlich für einen Verkehrsweg zwischen den beiden eine Lücke lässt.

Es ist Unsinn Flächen der Realität ohne ihre Nachbarn denken zu wollen, genau das passiert aber bei der Nutzung von “closed ways” als Flächenersatz: Sie verletzen in der überwiegenden Zahl der Fälle zwei Gebote aus den “best practices” die das Projekt sich selbst gegeben hat:

  • Bilde die Realität vor Ort ab (“ground truth”).

  • Benutze ein OSM-Objekt für ein Objekt der Realität (“one object, one feature”).

Zu “ground truth” ist der Fakt zu beachten, dass fast alle Flächen keine homogene Flächengrenze besitzen (“closed ways” aber genau das modellieren). Werden mehrere angrenzende Flächen durch “closed ways” modelliert, werden i.d.R. mehrere Flächengrenzobjekte mehrfach modelliert, wodurch eine Verletzung des zweiten Gebots stattfindet - und zwar _regel_mäßig.

Ich lege die On-the-Ground-Regel anders aus. Es geht bei dieser Regel nicht darum, ob man einen Node oder einen Way, Tags oder eine Relation verwendest, sondern darum, ob das, was in OSM erfasst ist, vor Ort so beobachtet werden kann. Sowohl wenn ein Gebüsch als geschlossener Way als auch wenn es als Multipolygon-Relation mit vier Outer-Ways und keinem Inner-Way gemappt ist, ist es vor Ort existent. Es entspricht dann innerhalb der Genauigkeit, mit der sein Rand in OSM abgebildet ist, der Realität.

Die One-Feature-one-Object-Regel verstehe ich völlig anders. Sie wäre verletzt, wenn wir Landnutzung nicht mit Flächen, sondern mit Kanten erfassen würden und nicht Tags an den Flächen, sondern an den Kanten anbringen würden (also landuse:left=meadow + landuse:right=forest statt landuse=meadow am Wiesenpolygon und landuse=forest am Waldpolygon). Die Regel ist meiner Meinung nach dafür gedacht, dass ein Objekt nicht mehrfach erfasst wird. Da wir die Landnutzung als Flächen erfassen und nicht dieselbe Wiese mehrfach erfassen, wird sie nicht verletzt.

Ein Objekt im Sinne der One-Feature-one-Object-Regel ist das Objekt, das die Tags trägt. Ein Haus in OSM, da es aus einem Way und mindestens drei Nodes besteht (also drei OSM-Objekte „zu viel“), verletzt diese Regel nach meiner Auslegung nicht. Genauso wenig verstößt man gegen sie, wenn man eine Multipolygon-Relation nimmt. Der Einsatz einer Multipolygon-Relation steht hingegen mit dem ungeschriebenen Grundsatz [2], Sachen so einfach wie angemessen zu mappen, in Konflikt. Dieser Grundsatz soll sicherzustellen, dass Neulinge die Möglichkeit haben, die Daten bearbeiten zu können, ohne umfangreiche Dokumentation lesen zu müssen.

Um es noch einmal klarzustellen: Ich will Multipolygon-Relationen nicht an sich abschaffen, ich will nur ihren Einsatz auf die Fälle beschränken, bei denen es erforderlich oder angemessen ist. Das sind Flächen mit inneren Ringen [3] sowie Flächen, mit einem sehr langen äußeren Ring und Flächen, die aus mehreren äußeren Ringen bestehen und bei denen das Mappen als zwei separate Polygone gegen die One-Feature-one-Object-Regel verstoßen würde [4].

[1] d.h. etwas konkreter als Träumereien auf einer Mailingliste oder im Forum, wie ich sie seit ich bei OSM bin, von Zeit zu Zeit sehe. https://2018.stateofthemap.org/2018/T107-Modding_the_OSM_Data_Model

[2] Bei OSM gibt es viele ungeschriebene Regeln. Wer gegen sie verstößt, wird gebeten, sie einzuhalten.

[3] Die Begriffe “innere Ringe” und “äußere Ringe” erkläre ich das gerne, wenn das gewünscht wird.

[4] z.B. ein Universitätscampus mit einer großen Straße dazwischen oder ein benannter Wald, der von einer Autobahn zerteilt wird. Diese zwei Beispiele sind aber recht kontrovers.

Notrufsäulen an der Autobahn

Posted by MKnight on 21 November 2018 in German (Deutsch)

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: [Notrufsäule] (https://www.picflash.org/viewer.php?img=lgqv9lzcbnae9m2.png)

In diesem Fall ist es recht eindeutig, wo die fehlende steht. In aller Regel sieht das Luftbild bei einer Notrufsäule so aus, eine Leitplanke endet und zu ihr vesetzt beginnt hinter der Leitplanke eine neue. Geringfügig anders sieht das bei Säulen an Auf/Abfahrten aus, dort sind sie in aller Regel nicht gegenüber, sondern in den “Rasendreiecken” der Verbindungen: [Alternativtext] (https://www.picflash.org/viewer.php?img=p1ahpvzl1rdqety.png) An Park/Rastplätzen sind sie in aller Regel am Ende des Parkplatzes: [Alternativtext] (https://www.picflash.org/viewer.php?img=i16y4jeakk0bk8o.png)

Bei allen drei Beispielen gilt mit sehr grosser Wahrscheinlichkeit: fehlt eine, dann fehlt sie, weil sie noch nicht gemappt ist.

In Thüringen gibt es in OSM aktuell 506 Notrufsäulen an den Autobahnen, leider konnte ich keine offizielle Zahl finden, gegen die man rechnen könnte.

Neue Wege für das Land

Posted by scoutrz on 20 November 2018 in German (Deutsch)

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.

Location: Sande, Lauenburgische Seen, Herzogtum Lauenburg, Schleswig-Holstein, Deutschland

Multipolygone, oder die Unendliche Geschichte

Posted by addresshistory*org on 18 November 2018 in German (Deutsch)

Es ist wieder einmal so weit, ein kommerzieller Tile Vermarkter beglückt die Community erneut mit einer Frage. Frage, nicht wirklich, denn diese ist bereits als selbst erfüllenden Prophezeiung formuliert.

“Wir brauchen feste Regeln für die Verwendung von Multipolygnen!”

https://forum.openstreetmap.org/viewtopic.php?id=64439 Es ist nun nicht so, als ob Multipolygone nicht bereits oft genug diskutiert worden wären. Das Ergebnis aus solchen Diskussionen entsprach bislang offensichtlich nicht vollständig den Wünschen der Tile Verwerter. Nun anstatt eigene Probleme mit Multipolygonen zuzugeben, versuchen Tile Vermarkter uns Mappern die selbst gewünschte Lösung durch wiederholtes Nachfragen suggestiv unter zuschieben.

In Changeset Diskussionen ist man hingegen nicht ganz so zimperlich, da wird aus einem OSM Wiki “Möglichst vermeiden”, Flux ein Nein. https://www.openstreetmap.org/changeset/56911458

Das soll sich nun offensichtlich ändern. Nieder mit den lästigen Multipolygonen. Dass Multipolygone für eine weitere Detaillierung von OSM unerlässlich sind, wird hierbei unter den Tisch gekehrt. Es zählt dass das eigene Produkt -bunte Karten Tiles- klaglos funktioniert.

Ring Polygone sind in der Ersterfassung sehr einfach zu handhaben, erschweren aber später eine weitere Verfeinerung und Detaillierung massiv. Kommende besserer Luftiblder oder Änderungen aus Naturbestandserhebungen, in Ring Regionen einzubringen ist sehr Mühsam. Um Ringe wieder zu trennen, muss man zuerst den richtigen Ring finden, und diesen an zwei Stellen auftrennen, anschließend darauf achten dass man mit darunter liegenden weiteren Flächen Polygonen aufgrund entstehender schwebender Nodes, keine Überlagerung verursacht. Aufgrund meiner Erfahrung ist das bearbeiten von Multipolygon Teppichen hingegen logisch, einfach, und ermöglicht eine wesentlich bessere Qualität. Wir Mapper sollen meiner Meinung nach der Weiterentwicklung von OpenStreetMap Priorität einräumen, an OSM Tiles verdienenden Firmen sollten anstatt auf unser Projekt politisch einzuwirken, besser an Ihren eigenen Renderern arbeiten.

Wir Mappen nicht für deren Renderer.

OAuth auch für Talk

Posted by addresshistory*org on 12 November 2018 in German (Deutsch)

Aus gegebenen Anlass rege ich an, dass sich die talk Plattform in die https://wiki.openstreetmap.org/wiki/OAuth Umgebung einfügen sollte.

ref: https://forum.openstreetmap.org/viewtopic.php?id=64427