Nahmd,
Gute Idee, das reduziert die API-Belastung.
Und beim Aufruf von JOSM reicht eine kleine Umgebung des Knotens, und der zieht automatisch die ganze Line mit.
Danke für den Tipp!
Gruß Wolf
Laut JOSM ungefähr: 46.3165842 x 9.4152832 x 49.0882578 x 17.2265625
Georg
Nahmd,
Here we go: http://www.netzwolf.info/kartografie/osm/oeffnungszeiten_at
Wien: http://www.netzwolf.info/kartografie/osm/oeffnungszeiten_at?zoom=12&lat=48.20&lon=16.40
Gruß Wolf
ich glaube, das wäre ein OL Ansatz über den mal mal nachdenken kann.
gruss
walter
p.s.
ich persönlich benutze eine postgresql-db mit gis-addon (postgis). da sind solche geometrischen aktionen ein klacks.
ausserdem brauche ich den osm-(x)api-server nicht dafür.
Vielen Dank, darüber bin ich später auch schon gestolpert. Ich schaue jetzt einfach einmal nach wie weit ich da mit dem nachbauen komme. Allerdings möchte ich nicht Öffnungszeiten sondern eher Haltestellen mit einer Echtzeitauskunft. Mal sehen ob es mir gelingt.
Wie füllst du die Datenbank und gibt es bei dir auch die Möglichkeit nachher alle Relationen auszuwerten? Insbesondere interessiert in welchen Relationen ist dieser Node member und ist diese Relation wiederum member einer anderen Relation.
mit osmosis - NICHT osm2pgsql, das ist eine sackgasse. und der falsche thread dafür.
Nahmd,
Habe gerade gesehen, dass XAPI ohnehin alle Nodes zu den Ways mitliefert. Da kann ich auch den Mittelpunkt nehmen. Außerdem hab ich eine Relation mit opening_hours gefunden (building als Multipolygon), muss also auch die Relationen einbeziehen.
Gruß Wolf
Aus dem JavaScript heraus kann ich wegen der JavaScript-Sicherheitsbeschränkunken keinen Kontakt zum XAPI-Server aufbauen. Mir erschließt sich nicht, wie ein Methode aus der Openlayers-Paket auf dem Server helfen soll?
Ich berechne lieber ein paar Mittelwerte, als dass ich einen GeoDB-Server aufsetze. 
Für meine bescheidenen Zwecke reicht nämlich die gelegentliche XAPI-Abfrage.
Gruß Wolf
hi,
ich hatte nur gedacht, dass du die knoten bereits hättest. dann könnte man eventuell nen polygon raus machen und dann centroid berechnen lassen. alles am client.
hab ich mit ol allerdings nie gemacht - aber für irgendwas in der richtung sollte es ja wohl nützlich sein.
überschneidet sich eventuell mit deiner vorherigen nachrícht.
zum thema postgresql: ist wirklich etwas oversized für deine auswertung.
ich hab mir die mühe nur gemacht a) weil ich das mal machen wollte. b) ich damit eine stabile platform für alle möglichen sache habe. c) ich sql einfach “mag”.
gruss
walter
Fesch, wie der Wiener sagt 
Danke! Hab’ gleich ein paar Fehler in meiner Gegend entdeckt.
Viele Grüße,
Georg
Hallo Netzwolf…
wäre es evtl. möglich, diese Karte auch auf die Schweiz auszuweiten? Wäre echt super 
(ich denke, eine eigene Karte wie z.b. AT wird nicht benötigt, da die CH doch sehr klein ist und diese Daten nicht so ins Gewicht fallen)
Hallo Efred,
Vielleicht ist es ja Sinnvoll die Karte mit Österreich zusammen darzustellen. Das sind wahrscheinlich weniger Daten als als wenn Deutschland erweitert würde.
Du kannst ja einfach zwei Vorschläge für die BBoxen machen. Eine mit Deutschland eine mit Österreich. Ich denke das er es dann ganz schnell umsetzen würde.
Hi viw,
Dein Vorschlag ist doch genau das, was efred geschrieben hat:
… diese Karte auch auf die Schweiz auszuweiten? …
… ich denke, eine eigene Karte … wird nicht benötigt …
Ciao,
Frank
die bbox für DE weiss ich gerade nicht. man müsste aber "nur bis auf 45.78 runtergehen. Dann ist die Schweiz auch komplett mit drin.
alternativ bbox um bei AT anzufügen: 5.93,45.78,17.2265625,49.0882578 (da kommen dann einfach noch sehr viele Daten von Süddeutschland mit rein)
Nahmd,
Man kann die Karten jetzt aufrufen mit “?filter=error”, dann werden nur noch fehlerhafte Nodes angezeigt.
http://www.netzwolf.info/kartografie/osm/oeffnungszeiten_at?filter=error
Der Parameter wird auch durch das Permalink weitergereicht.
Gruß Wolf
Nahmd,
Wenn Bedarf danach besteht, kann ich das Script ergänzen fürs Handling von Zeitpunkten statt Zeitbereichen.
Einzige Erweiterung beträfe die Zeitbereiche: da könnte man einen “Takt” anhängen:
Abfrage zu opening_hours ist:
zu gegebenem Zeitpunkt: evaluiere, ob geöffnet oder auch nicht.
Abfrage zu “Leerungszeiten/Abfahrtszeiten”:
zu gegebenem Zeitpunkt: suche die nächsten (max N) Termine (max H Stunden in der Zukunft).
Gruß Wolf
Aber da braucht man vorher eh noch die Strathaltestelle und die Offset-Zeiten zwischen den Haltestellen der Linie als extra Werte, weil den Fahrplan 1x pro Linenvariante (siehe Omomoa-Schema) erfassen zu müssen ist ja schon genug, dann kommen da noch die Ausnahmen… Die collection_times=* da da noch einfacher.
Nahmd,
Man speichert je Linienvariante:
(1) welche Haltestellen zu welcher relativen Zeit (relativ zur Abfahrt an der Starthaltestelle) bedient werden,
(2) zu welchen Zeitpunkten eine Fahrt startet (und an welchen Tagen).
Ich sprach nur von Punkt 2.
Aber das gehört nicht mehr in diesen Thread.
Gruß Wolf