Wheelmap: Werbung mit OSM-Material im TV

Ich find euren Schritt prima das Problem anzugehen. Mir selbst fehlen da alledings so ein paar technische Informationen.
Rendert ihr die Kacheln selbst und mit welcher Verzögerung?
Wie funktioniert das POI Bestimmen von Flächen nun bei euch?
Wie geht ihr mit dem Meer von zusätzlichen Daten um?
Die Nodes können nicht automatisch mit darunterliegenden Buildings Flächen verschmolzen werden, oder?

Ich denke die Frage werden nicht nur mir kommen, was ich daraus schließe, dass sich hier viele zurückhalten. Wenn du aber wissen willst, was wir von der derzeitigen Lösung halten, müssen wir sie natürlich verstehen. Wäre das nicht ein gutes Thema für einen Blogeintrag, sozusagen, behind-the-scenes?

Ja.

Ich warte auf meinen um 20:45 mit einem wheelchair-Tag neu erstellten Parkplatz:
http://tile2.wheelmap.org/18/137509/85349.png/status
http://www.openstreetmap.org/browse/changeset/10627948
http://wheelmap.org/?a=b&lat=53.0364&lon=8.84035&q=Bremen&zoom=18&layers=BT
Die Kachel wurde bisher nicht aktualisiert und auch noch kein Marker of Wheelmap.org gesetzt.

Nein, das erscheint mir auch wenig sinnvoll, da Flächen inzwischen unterstützt werden, d.h. vorhandene Flächen werden erkannt und mit einem Marker auf Wheelmap.org markiert, welcher dann wie üblich geändert werden kann.

Diesem vorhandenen Parkplatz habe ich mit JOSM einen wheelchair-Tag verpasst und der Marker auf Wheelmap.org war in weniger als 5 Minuten aktualisiert:
http://www.openstreetmap.org/browse/way/43587301
http://wheelmap.org/?lat=51.52584&lon=9.92988&zoom=18&layers=BT

Bei neuen Objekten scheint das deutlich länger zu dauern, siehe oben (Parkplatz 20:45).

Gruß,
Mondschein

Meiner Meinung nach sollte ein Editor entweder automatisch prüfen, ob die Änderung schon in den Daten vorhanden ist, oder aber dem Nutzer die vorhandenen Daten anzeigen und ihm diese Entscheidnung treffen lassen. Objekte nur anhand von veralteten Kacheln halte ich für falsch.

Nein, diese Einträge sind eingefroren und werden manuell in die OSM eingetragen, wenn sie nicht schon drin sind. Es sind ca. 5500 Stück.

Das lag daran, dass wir den Planeten neu importieren, die Daten filtern und aufbereiten mussten. Ab jetzt sollte es genau so schnell gehen, wie auch sonst immer, also max. 5 Minuten. Kontrolliert werden die Änderungen nicht, wenn sie aus einer anderen Quelle kommen.

Nein, wir rendern die Kacheln nicht selber. Wir betreiben aber einen Caching Proxy, der vor den eigentlichen OpenStreetMap Kachel Server geschaltet ist. Die Caching Zeit für die Kacheln beträgt einen Tag.

Wir haben eine Kopie der OSM Datenbank mit osm2psql minütlich synchronisiert. Für jedes Gebäude mit building=* und einem weiteren Tag wie amenity=* usw. berechnen wir eine BoundingBox und dessen geometrischen Mittelpunkt. Der Way mit einer negierten OSM id, seinen Tags und den LatLon Werten des berechneten Mittelpunktes wird dann minütlich in die Wheelmap Produktionsdatenbank importiert. Danach ist der Way von einem Node nicht mehr zu unterscheiden. Einzig eine negative OSM ID weist darauf hin, dass es eigentlich ein Way ist.

Wir arbeiten gerade an einer Lösung, die es ermöglicht Dubletten in Geodaten manuell (visuell) zu identifizieren, und die neuen Daten in die OSM zu schreiben.

Wie meinst du das?

Guter Punkt, ich werde mal versuchen was zusammen zu stellen.

Achso, also muss ich zuerst sicherstellen, dass die entsprechende Kachel schon bei OSM aktualisiert wurde, bevor ich diese bei Wheelmap.org aufrufe, wenn ich diese schnell auf Wheelmap.org sehen möchte (und hoffen, das die Kachel nicht schon vor weniger als einem Tag aufgerufen wurden).

Und wie lange dauert es dann, bis der Marker auf Wheelmap.org angezeigt wird?
Entweder da hängt etwas beim Import in die Produktionsdatenbank oder irgendwo bei der Darstellung des Markers.

Gruß,
Mondschein

Wie gesagt, in der Regel ca. 5 Minuten. Aber hier hängt tatsächlich was. Ich habe den Way 149464503 in der OSM Kopie gefunden, und er liegt dort auch in der Form das mutierten Nodes -149464503 vor. Aber irgendwie wird er nicht in die wheelmap transferiert.

Vielen Dank für den Hinweis, ich gehe der Sache morgen mal auf den Grund.

Gruß,

Christoph

Jetzt ist der Marker da. :slight_smile:

Gruß,
Mondschein

Und die Kachel ist auch aktualisiert worden, so dass man den Parkplatz darunter auch sehen kann. Hab den Fehler gefunden und behoben. In Zukunft werden alle neu angelegten Ways, die für die Wheelmap interessant sind, in der Regel innerhalb von 5 Minuten importiert.

Ich haben hier im Forum jetzt auch meine E-Mail hinterlegt, so dass man mich kontaktieren kann. Bisher war mir das Forum als Austauschkanal nicht so geläufig. Für Fehlermeldungen und Wünsche bzgl. der Wheelmap haben wir ein eigenes “Uservoice” Forum eingerichtet. http://wheelmap.uservoice.com Dort wird auch angezeigt, an welchen Sachen wir gerade arbeiten. Wir hatten gehofft, dass der Fortschritt der wheelmap damit etwas transparenter wird. Allerdings habe ich das Gefühl, das viele Leute aus diesem Forum dort noch nicht nachgeschaut haben.

Gruß, Christoph

Hallo,

ich melde mich mal hierzu, weil ich fuer die Wheelmap den Code aufgesetzt habe, der die Polygon-POIs verarbeitet.

Wheelmap rendert nicht selbst, das ist ja schon gesagt worden.

Das urspruengliche Wheelmap-System konnte ja nur mit Punkt-POIs umgehen, und vom User Interface her war das ja auch voellig OK - irgendwelche Polygone in der Web-Karte haetten da nur verwirrt.

Dieses System funktioniert so, dass die Wheelmap eine - relativ kleine - MySQL-Datenbank hat, in der sich nur die interessanten POIs befinden, und die in kurzen Abstaenden anhand von .osc-Files von OSM aktualisiert wird.

Wir haben uns bei der Polygonverarbeitung fuer einen Ansatz entschieden, bei dem an diesem existierenden System fast nichts veraendert werden muss. Wir haben einen zweiten Server aufgesetzt, auf dem eine relativ normale PostGIS mit osm2pgsql und minuetlicher Aktualisierung per osmosis laeuft, also im Grunde genau die gleiche Technologie wie fuer einen normalen Tile-Server, allerdings mit einer reduzierten osm2pgsql-Style-Datei, so dass wir da z.B. keine Landuse-Flaechen und keine Liniengeometrien und so drin haben. Als zusaetzlicher Kniff sorgt ein PostgreSQL-Trigger dafuer, dass jedesmal, wenn das osm2pgsql irgendwas an der planet_osm_polygons-Tabelle dreht, was uns interessiert (z.B. einen neuen shop=supermarket eintraegt), der Mittelpunkt dieser Geometrie berechnet und in eine separate Tabelle (die heisst bei uns “pseudo_nodes”) geschrieben wird.

Ein einfaches Skript holt nun regelmaessig alle neuen oder geaenderten Eintraege aus der pseudo_nodes ab und erzeugt daraus etwas, das wie ein ganz normales .osc-File aussieht, nur dass die “node IDs” dort negativ sind. Dieses .osc-File kann dann direkt vom Wheelmap-Produktionssystem, das ja nur mit Nodes arbeitet, geladen werden.

Diese Loesung mag auf den ersten Blick etwas kompliziert aussehen, aber sie hat zwei wertvolle Vorteile: Erstens kann das Produktionssystem unveraendert bleiben und muss sich nicht mit Polygongeometrien herumschlagen. Zweitens ist die relativ “teure” Polygonverarbeitung - die ja das Vorhalten aller 1,5 Milliarden Nodes von OSM erfordert, nur fuer den Fall, dass sie ploetzlich zur Konstruktion eines neuen shop=supermarket gebraucht werden - komplett auf einer separaten Kiste und beeintraechtigt nicht die Performance des Produktionssystems; sollte da mal was klemmen, ist der worst case, dass die Updates ins Stocken kommen - nicht aber, dass die ganze Wheelmap langsam wird.

Das Meer sind eigentlich nur die erwaehnten vielen “auf Vorrat” vorgehaltenen Nodes in der Polygon-Aufbereitungs-Datenbank. Was bei der Wheelmap ankommt, also die tatsaechlichen Polygon-Mittelpunkte, ist durchaus handhabbar.

Bye
Frederik

Ich habe keine Einwände.

Werden eigentlich Konflikte behandelt?
Ihr aktualisiert zwar minütlich die Daten, aber trotzdem könnte es passieren, dass ein Objekt bei OSM gelöscht wurde, in eurer OSM-Datenbank aber noch vorhanden ist und dass genau dann jemand den wheelchair-Tag über Wheelmaps.org ändern oder hinzufügen möchte.
Was passiert dann?

Gruß,
Mondschein

Wir nehmen die Änderung entgegen und legen sie auf eine Warteschlange. Wenn ein Worker diese Änderung abarbeitet, holt er sich über die OSM API die aktuelle Version des Nodes/Ways, der zu ändern ist.

  • Ist der Knoten zu diesem Zeitpunkt nicht mehr da (gelöscht), wird der Job verworfen.
  • Sollte sich der Knoten in der Zwischenzeit durch einen dritten geändert haben, werden diese Änderungen nicht rückgängig gemacht. Wir wenden unsere Änderungen auf der neuesten Version des Knoten an, und speichern sie dann über die API in der OSM
  • Sollte sich der Knoten zeitgleich in wheelmap und extern extern geändert haben, und die änderungen identisch sind, wird der job auch verworfen

Sehe ich das recht, das hier jetzt jemand sich hinsetzt um die Jobs abzuarbeiten und nicht mehr ein Bot die Daten in die Datenbank einspielt?

Hört sich sehr vernünftig an.

Nein, sicher nicht. :slight_smile:

Gruß,
Mondschein

Nein, die worker, die die Änderungen in die wheelmap Eintragen sind Programme, die regelmässig ausgeführt werden. Einzig die 5500 Orte (siehe weiter oben), die wir seit Oktober 2011 gesammelt haben, werden in Zukunft von Menschen in die OSM eingetragen, wenn sie noch nicht enthalten sind.

Das könnten wir doch eigentlich als Community machen und entsprechend der Bundesländer aufteilen? Müsst ihr euch doch nicht mit rumplagen, wäre aber natürlich wichtig, das diese Informationen nochmal gegengecheckt werden.

Flugsimulator X-Plane 10 setzt auf Openstreetmap als Datenbasis.

http://www.golem.de/news/spieletest-x-plane-10-flugsimulator-mit-openstreetmap-und-vielen-rechnern-1202-89668-5.html

st

Das klingt für mich nach einem guten Vorschlag. Aber wer ist denn genau wir? Und wie müssten wir die Daten anliefern, damit sie gut zu verarbeiten sind. Und wie können wir sicherstellen, welche Datensätze abgearbeitet wurden? Wir müssen sie ja hinterher aus der wheelmap löschen, wenn der echte Node/Way in der OSM vorhanden ist.

Freu mich auf Feedback. Vielleicht kriegen wir die mittlerweile 5611 Nodes schnell in die OSM. Wir werden nämlich mittlerweile sehr oft gefragt, wann denn die Orte endlich überprüft wurden.

Update:

Ich werde nächste Woche für die Sozialhelden einen JOSM Workshop halten, damit jeder der Sozialhelden über genug wissen verfügt, die Orte in der OSM anzulegen, ohne Duplikate zu erzeugen.

Gruß, Christoph

Wir eben. :slight_smile:
Jeder der mitmachen möchte.

Direkt als OSM-Datei wäre gut.
Wenn euch das nicht möglich erscheint, dann wird sich jemand finden, der das entsprechend umwandelt.

Da gibt es verschiedene Möglichkeiten.
Bei uns ist es üblich, eine Wiki-Seite einzurichten.
Die Daten werden dann in handliche Pakete (Einteilung jeweils möglichst in zusammenhängende Gebiete) aufgeteilt und wer will, sucht sich dann ein oder mehrere Pakete aus und schreibt das ins Wiki, damit es nicht versehentlich zu mehrfachen Bearbeitungen eines Paketes kommt.
Ist ein Paket fertig bearbeitet, so wird das entsprechend im Wiki vermerkt.
Sollten Probleme mit einzelnen POIs auftreten, so könnte man das ebenfalls im Wiki vermerken.

Das hängt natürlich davon ab, wie viele Mapper dabei mithelfen.

edit:
Ist das aus OSM-Sicht eigentlich ein Import?

Gruß,
Mondschein

Wir hatten sowas schon mal gemacht. Finde es nur gerade nicht, glaube das ging um Postleitzahlen oder Mc Donalds oder sowas. Die Frage ist, was konkret gemacht werden müsste. Wenn das nur neue Objekte wären, wären .OSM Dateien natürlich super. Wenn das nur Beschreibungen a la “hier ist eine Bank” ist, wäre auch KML voll ok. Das kann sich dann jeder in JOSM laden und per Hand in die DB nachtragen. Das müsste dann in handlichen Paketen zerlegt sein, etwa per Bundesland und eine Wikiseite, wo die Leute den aktuellen Abarbeitungsstand hinterlegen könnten. Das wäre es, vorrausgesetzt es finden sich genügend, die auch mitmachen :slight_smile:

P.S. Ist der Workshop öffentlich? Vielleicht gibt es auch noch ein paar frische Mapper in Berlin, die ebenfalls von Potlatch zu JOSM wechseln sollen? Könnten wir auch vielleicht nochmal in der Wochennotiz darauf hinweisen.