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?
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.
@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.
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:
Wenn das was wäre, könnten wir das Thema vertiefen.
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.
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.
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.
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.
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…
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
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.
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?
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}}
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.
