API? Daten aus OSM in Wiki verwenden

kaffeeringe · 2022-10-10T19:32:20.995Z

Ich kümmere mich um die Technik beim Kiel Wiki. Dort haben wir zu vielen Läden, Restaurants und Cafes ebenfalls Einträge.

Cool wäre es, wenn wir die Daten aus OSM (Kontaktdaten, Öffnungszeiten usw.) automatisch bekommen könnten. Mit Apps wie “Every Door” sind die viel einfach zu aktualisieren. Und wir müssten das als Communities nur einmal machen.
Ich könnte mir aber auch die umgekehrte Verbindung vorstellen: Wir haben Einträge zu allen Straßen und vielen Sehenswürdigkeiten. Die könnte man in OSM verlinken. Klar, wird das nicht dargestellt. Aber das könnte man dann ja mit einer eigenen Karte mal machen. Gibt es daran Interesse?

SafetyIng · 2022-10-10T20:06:19.800Z

kaffeeringe:

Cool wäre es, wenn wir die Daten aus OSM (Kontaktdaten, Öffnungszeiten usw.) automatisch bekommen könnten

Es gäbe mehrere Möglichkeiten:

Man spiegelt die Daten direkt. Z.B. mittels eigener pgsql-Datenbank. Hier wäre beispielsweise auf osm2psql verwiesen.
Du kannst via Overpass-API (z.B. Overpass-API) auch auf die Daten direkt zugreifen und diese damit herunterladen. Eine direkte Abfrage bei jedem Aufruf eures Wikis sehe ich eher kritisch, da hier längere Wartezeiten entstehen und Overpass auch nicht dafür ausgelegt.

Mittels dem 1. Element kannst du auch eine eigene Karte generieren und dann entsprechende Elemente filtern. Auch sind dort idR die OSM-IDs mit verzeichnet, wodurch du direkt Links zu Every-Door, OSMmyBiz oder ähnlich erstellen kannst.

kaffeeringe · 2022-10-11T06:46:33.014Z

@2: Ich hatte auch eher gedacht, dass ich alle paar Monate mal checken lass, ob aktuellere Daten vorliegen und würde die Ergebnisse dann direkt ins Wiki schreiben lassen. Aber noch habe ich keine Ahnung, wie ich das klug machen könnte. Aber Du hast mir ein paar Hinweise gegeben, die ich erst einmal verfolgen würde.

roald-linus · 2022-10-11T13:21:24.344Z

Hi @kaffeeringe,

meiner Meinung ist das gar nicht so leicht, was Du möchtest: praktisch eine dauernd auf die Öffnungszeiten bezogen aktuelle Karte. Das müsste programmiert werden.

Ein andere Möglichkeit wäre eine Overpass-Abfrage und die als iframe einbetten. Ich habe hier ein Beispiel angelegt:

overpass-turbo.eu

overpass turbo

A web based data mining tool for OpenStreetMap which runs any kind of Overpass API query and shows the results on an interactive map.

Wenn das was wäre, könnten wir das Thema vertiefen.

Grüße

Discostu36 · 2022-10-11T13:24:03.627Z

Weil Overpass gerne auch mal überlastet ist, würde ich das nicht im Frontend machen. Lieber auf dem Server ein Script, das 1x täglich die aktuellen Daten von der Overpass-API holt, irgendwo reinschreibt und das Wiki muss sich dann die Daten aus dem Backend holen. Ich weiß nur nicht, wie gut sowas mit Mediawiki umzusetzen ist.

mmd · 2022-10-11T14:08:13.835Z

Discostu36:

Ich weiß nur nicht, wie gut sowas mit Mediawiki umzusetzen ist.

Es gibt da Extensions, die sowas machen und auch Ergebnisse cachen können: https://www.mediawiki.org/wiki/Extension:External_Data

Tordanik · 2022-10-11T14:35:36.805Z

Vielleicht sind ja auch die Erfahrungen der Kollegen aus Tübingen interessant:

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

kaffeeringe · 2022-10-12T09:30:16.120Z

Oh, klasse. Das sieht nach einem Ansatz aus!

kaffeeringe · 2022-10-12T09:38:23.911Z

Ich brauch gar keine Karte. Beispiel:

Im Kiel-Wiki gibt es eine Seite für die Forstbaumschule.
Es gibt dieses Objekt in OSM, das super viele Daten enthält.

Ich würde jetzt gerne die Daten aus OSM in der Infobox rechts anzeigen lassen. Dann muss die im Wiki niemand mehr pflegen. Das ist mit “Every Door” in OSM viel einfacher.

Ich stell mir vor, dass ich in jeder Infobox die ID des OSM-Objekts eintrage und dann diese Daten regelmäßig aktualisiert werden. Das muss natürlich gar nicht bei jedem Aufruf passieren. Deswegen scheint mir die Caching-Extension von @mmd ganz hilfreich zu sein.

@Tordanik: Danke für den Tipp. Ja, so eine Lösung muss man nur einmal entwickeln. Ich schau mal, ob ich da Kontakt aufnehme.

Discostu36 · 2022-10-12T10:10:41.620Z

Auf größerer Skala hat dieses Vorgehen ein Problem: OSM-IDs sind nicht permament. Wenn irgendeiner der POI, die du da abfragst, mal aus irgendeinem Grund ne neue ID kriegt (versehenlich gelöscht und neu erstellt, Node in Way geändert etc.), kommst du nicht mehr an die Daten. Du musst also entweder regelmäßig prüfen, dass die Daten noch da sind, oder die Anfrage über einen Geocoder machen, der dir die ID zurückgibt, z.B.

https://nominatim.openstreetmap.org/search.php?q=Restaurant+Forstbaumschule+Kiel&format=jsonv2

Tordanik · 2022-10-12T16:50:51.052Z

Discostu36:

Du musst also entweder regelmäßig prüfen, dass die Daten noch da sind, oder die Anfrage über einen Geocoder machen, der dir die ID zurückgibt

Ein berechtigter Hinweis, aber ich würde an seiner Stelle vermutlich trotzdem die IDs benutzen. Die Lösung mit dem Geocoder macht es halt noch einmal deutlich aufwendiger und ist trotzdem nicht perfekt – da könnte z.B. eine Änderung an der Schreibweise des Namens den Match zerstören.

kaffeeringe · 2022-10-12T17:56:46.267Z

ID genügt. Wir müssen eh wissen, wenn ein Laden geschlossen wird. Die ID zu löschen, wäre ein guter Hinweis und man könnte die das Template so machen, dass es dem Artikel die Kategorie “FIXME” hinzufügt. Wenn man deren RSS-Feed abonniert, ist man immer auf dem aktuellen Stand

Das blödere Problem ist, dass einige Restaurants Nodes und andere Ways sind. Das muss man also auch noch im Template unterscheiden…

mmd · 2022-10-12T19:27:32.988Z

Ich hab hier mal noch ein Beispiel, wie das mit der External Data Extension aussehen könnte, allerdings für den OSM Cal(endar): module_osmcal.lua · GitHub

Es sollte kein größeres Problem sein, die URL so auszutauschen, dass da ein JSON von Overpass API zurückkommt. Also für den Node 6205819529 wäre das https://overpass-api.de/api/interpreter?data=%5Bout%3Ajson%5D%3Bnode%286205819529%29%3Bout%20center%3B

Am besten mal etwas damit herumspielen…

kaffeeringe · 2022-10-12T19:29:24.957Z

Ich habe das hier mal eingebaut: Heinrich der achte – Kiel Wiki
Die Daten in der Infobox kommen aus OSM.

Discostu36 · 2022-10-13T04:46:17.435Z

Cool! Eine Quellenangabe wäre noch schön

highflyer74 · 2022-10-13T06:30:24.206Z

kaffeeringe:

Wir müssen eh wissen, wenn ein Laden geschlossen wird.

Moin! Als Hinweis sei hier gesagt, dass POIs standardmäßig nicht (mehr) gelöscht werden (sollten), wenn sie schließen. Da hat sich das DE:Lebenszyklus-Präfix - OpenStreetMap Wiki etabliert. Insofern kann ein POI trotz weiterhin vorhandener ID nicht mehr vorhanden sein, bzw. nicht mehr der sein, der er vorher war.

kaffeeringe · 2022-10-13T09:47:59.992Z

Ja. Das ist gerade erst einmal ein Proof-of-Concept. Schon um für Editor:innen klar zu machen, wo die Daten geändert werden müssten, wenn sie falsch sind, muss da ein Hinweis dran. Ich grübel noch, wie ich den am besten platziere. Vorschläge?

Discostu36 · 2022-10-13T10:14:27.820Z

grafik

Linker Link auf openstreetmap.org/copyright, “Bearbeiten”-Link auf https://www.openstreetmap.org/edit?editor=id&{{way|node|relation}}={{Way-ID}}#map=18/{{Lat}}/{{Lng}}

SafetyIng · 2022-10-13T10:32:48.309Z

Discostu36:

#map=18/{{Lat}}/{{Lng}}

Das brauchst du eigentlich nicht - oder? Anhand des Ways erkennen jedenfalls JOSM und iD jeweils wo sie sich positionieren müssen…

Discostu36 · 2022-10-13T11:02:32.467Z

Als ich mich zuletzt mit dem Thema beschäftigt habe (das ist ungefähr 2 Jahre her) hat ID immer automatisch auf die Position gezoomt, die ich zuletzt offen hatte, als ich ihn benutzt habe, auch wenn das ausgewählte Objekt nicht in dieser Bonding Box ist.