Neuer Mapper bearbeitet Busrelationen

Weide · 2021-03-22 16:54:58

SafetyIng wrote:

... den Kreisverkehr aufsplitte und nur den befahrenen Teil hinzufüge, den nicht befahrenen nicht, ist das am Ende genauer. Das ist ein Fakt. Und der kann nicht falsch sein. Und nein, das ist keine Meinung.

Doch. Du gehst davon aus, dass der Fahrtwegteil der Relation ausnahmslos die befahrene Strecke angibt. Traditionell bedeutet aber die Angabe eines kompletten Kreisverkehrs nicht, dass der gesamte Kreisverkehr befahren wird. Die Bedeutung eines Datensatzes ist eine Konvention. Bei einer Fläche geben wir z.B. den Rand an, meinen aber nicht die dort angegebene Linie sondern die damit umschlossene Fläche.

SafetyIng wrote:

Aber gleichzeitig erwarte ich, dass diese akzeptanz für (ebenfalls) richtiges Mappen aufgebracht wird und nicht trotzig reagiert wird.

Den Kreisverkehr aufzuteilen ist ebenfalls richtiges Mappen, das ist unstrittig (Die Akzeptanz ist voll und ganz da). Aber es ging doch nicht um den Fall, dass ein Vertreter der "Gesamtkreisverkehr"-Meinung systematisch die Arbeit der "Aufsplitter" kaputtmacht. Es ging um die mangelnde Akzeptanz der "Aufsplitter", die nicht bereit sind, die Sonderrolle kompletter Kreisverkehre als andere Auffassung zu akzeptieren und wo Leute systematisch alle Objekte der anderen Auffassung durch ihre eigene Mappingweise ersetzen. "Wir sind die einzigen, die es richtig machen". Das ist mangelnde Akzeptanz anderer Meinungen.

skyper · 2021-03-22 20:01:54

miche101 wrote:

skyper wrote:
Hauptproblem sind m.M die Unvollständigkeit der Daten an sich und dem fliegenden Wechsel von PTv1 und PTv2 innerhalb einer Region, plus die unterschiedlichen Interessen und Systeme siehe meine Kritik in #78: /viewtopic.php?pid=822957#p822957
Fliegend kann man das nicht mehr nennen... vor fast 10 Jahren wurde PTv2 eingeführt https://wiki.openstreetmap.org/wiki/Pro … _Transport.

Da habe ich mich undeutlich ausgedrückt. Ich meinte die parallel nebeneinander existierenden Systeme PTv1 und v2 und dass eine Linie nach PTv2 und eine andere nach v1 eingetragen ist.

miche101 wrote:

Eher gescheiterten Versuch.

Ich habe die Hoffnung noch nicht aufgegeben. Immerhin haben wir jetzt zum Teil verwendbare Quellen und wenn der Schritt von OSM zu GTFS und nicht andersherum funktionieren soll geht es auch nicht ohne PTv2.

miche101 wrote:

Das Hauptproblem ist der hohe Aufwand von Ptv2... davon muss man weg.. und nicht noch mehr und mehr.

Die einmalige Umstellung auf PTv2 ist ein wenig Aufwand, wobei ich die meiste Zeit immer noch mit den Stops und dem Verbessern der highways verbringe. Die eigentlichen Varianten sind dann nicht viel Aufwand. (Außer der Hürde manchen Fahrplan in fünf tags mit maximal 255 Zeichen zu pressen).

Zum Zeitaufwand bei Updates kann ich Dir wohl frühestens zum Fahrplanwechsel nächste Weihnachten was sagen, oder Corona bring auch dann noch den Fahrplan durcheinander.

miche101 wrote:

Mein Vorschlag => Routing, das würde einen großen Brocken an Arbeit verschwinden lassen.

Mit Punkten allein und unserer bescheiden Datenlage hast Du mich da noch nicht überzeugt.

miche101 wrote:

Ich mach schon den Anfang und lasse einfach die Wegeliste weg.. , plege und warte nur noch die Haltestellenliste und das ist schon viel Arbeit für 2 Landkreise die ich betreue

Zusätzlich zu PTv1 oder verzichtest Du auf die Darstellung bei den meisten ÖPV-Karten?

skyper · 2021-03-22 20:06:29

ToniE wrote:

GerdP wrote:
Nö, die nehmen hier keine Radfahrer mit
Hier auch nicht

Klapprad oder (Vorder-)Rad ausbauen funktioniert, dann ist es Sperrgut und braucht auch kein Zusatzticket.

miche101 · 2021-03-23 17:21:28

skyper wrote:

wenn der Schritt von OSM zu GTFS und nicht andersherum funktionieren soll geht es auch nicht ohne PTv2.

in GTFS ist der Wegeteil optional.. benötigt man nicht kann man haben muss aber nicht. In GTFS ist das dass Shape für jeden Trip.

skyper wrote:

Umstellung auf PTv2 ist ein wenig Aufwand, wobei ich die meiste Zeit immer noch mit den Stops und dem Verbessern der highways verbringe. Die eigentlichen Varianten sind dann nicht viel Aufwand.

ok... ich find das einen riesen Aufwand.

skyper wrote:

Zum Zeitaufwand bei Updates kann ich Dir wohl frühestens zum Fahrplanwechsel nächste Weihnachten was sagen, oder Corona bring auch dann noch den Fahrplan durcheinander.

ja das ist nicht leicht weil man garnicht weiss welche Relation zu weilen Trip gehört.. im MVV wechseln die "IDs" jedes Jahr...

skyper wrote:

Zusätzlich zu PTv1 oder verzichtest Du auf die Darstellung bei den meisten ÖPV-Karten?

ja nach dem bisherigen System. Ich finde hier muss man mal moderere Lösungen zuwenden. Diese vorgekauten Relationen ist zu aufwendig, im Speziellen den Bereich "Bus" weil hier teils bis zu >40 Varianten auf eine Linien kommen.. das ist viel zu viel und müllt OSM zu.

Gruß Miche

streckenkundler · 2021-03-23 17:29:14

miche101 wrote:

Diese vorgekauten Relationen ist zu aufwendig, im Speziellen den Bereich "Bus" weil hier teils bis zu >40 Varianten auf eine Linien kommen.. das ist viel zu viel und müllt OSM zu.

+1
Ich hatte mich hier in Lübben auch mal mit PTv2 etwas beschäftigt. Ich bin zum selben Ergebnis gekommen. Kurzum: man scheitert hier in der Brandenburgischen Pampa an der systematischen Erfassung und Laufendhaltung... und dann kommen immer wieder baubedingte Umleitungen hinzu. Wenn man bei bestimmten Linien alle Varianten in OSM einpflegen würde, hätte man geschätzt 1/5 bis 1/4 des Fahrplans, vielleicht noch mehr...

Sven

miche101 · 2021-03-25 12:39:23

streckenkundler wrote:

+1
Ich hatte mich hier in Lübben auch mal mit PTv2 etwas beschäftigt. Ich bin zum selben Ergebnis gekommen.

Ja, Danke dann bin ich ned alleine Ich werd da Thema auch mal auf Eis legen und in ein paar Jahren vielleicht nochmal schauen.

skyper · 2021-03-29 16:39:12

Weide wrote:

skyper wrote:
... ich kann auf etliche deiner Routingpunkte verzichten ...
Ich hab keine Routingpunkte und bin auch dagegen.
Die von mir genannten Markierungspunkte werden nicht zusätzlich angelegt und erhalten dadurch auch keine neuen Tags.

Ok, für mich sind das immer noch Punkte über die gefahren wird, auch wenn die Punkte schon existieren und ein Endpunkt eines Weges an einer Kreuzung sind. Gut, Du willst damit nur Segmente/Abschnitte markieren.

skyper · 2021-03-29 17:08:37

miche101 wrote:

skyper wrote:
wenn der Schritt von OSM zu GTFS und nicht andersherum funktionieren soll geht es auch nicht ohne PTv2.
in GTFS ist der Wegeteil optional.. benötigt man nicht kann man haben muss aber nicht. In GTFS ist das dass Shape für jeden Trip.

Ja, genau, dieses Shape fehlt bei mir häufig oder ist kaputt bis ungenau. Wirklich exakte Shapes finde ich fast nicht und etliche dieser Shapes sollen laut Lizenz aus OSM-Daten stammen.

In Nicaragua werden so weit ich weiß die GTFS-Daten hauptsächlich aus OSM-Daten erstellt.

miche101 wrote:

skyper wrote:
Umstellung auf PTv2 ist ein wenig Aufwand, wobei ich die meiste Zeit immer noch mit den Stops und dem Verbessern der highways verbringe. Die eigentlichen Varianten sind dann nicht viel Aufwand.
ok... ich find das einen riesen Aufwand.

Das kann an der Arbeitsweise oder an den Linien liegen.

Zuerst kümmer ich mich meistens um die Stops.
Dann fange ich mit den langen Zweigen an. 1. Stops, 2. Wege (`Ctrl+W`).
Weiter Relationen erstelle ich dann mit Duplizieren und Löschen/Kopieren von bestimmten Stop-Sequenzen und Weg-Sequenzen.

miche101 wrote:

skyper wrote:
Zum Zeitaufwand bei Updates kann ich Dir wohl frühestens zum Fahrplanwechsel nächste Weihnachten was sagen, oder Corona bring auch dann noch den Fahrplan durcheinander.
ja das ist nicht leicht weil man garnicht weiss welche Relation zu weilen Trip gehört.. im MVV wechseln die "IDs" jedes Jahr...

Das ist einer meiner großen Kritikpunkte an dem aktuellen GTFS-System.

miche101 wrote:

skyper wrote:
Zusätzlich zu PTv1 oder verzichtest Du auf die Darstellung bei den meisten ÖPV-Karten?
ja nach dem bisherigen System. Ich finde hier muss man mal moderere Lösungen zuwenden. Diese vorgekauten Relationen ist zu aufwendig, im Speziellen den Bereich "Bus" weil hier teils bis zu >40 Varianten auf eine Linien kommen.. das ist viel zu viel und müllt OSM zu.

Ich finde es nicht einfacher eine PTv1-Relation zu pflegen als 20 PTv2-Relationen und habe bisher keine PTv1 gefunden die so komplett richtig war und keine Wege gefehlt haben. Wie soll ich denn jetzt die GTFS-Daten zusammenschmelzen um diese mit PTv1 zu vergleichen. Auf die Shapes kann ich ja nicht zurückgreifen, da nicht gut Qualität und eventuell ehe schon aus OSM stammen (s.o.)?

Alles in allem, hoffe ich, dass PTNA bis Weihnachten/nächstes Jahr mir ein Geschenk macht und GTFS-Datensätze vergleichen kann.

Ciao skyper

ToniE · 2021-03-29 17:55:40

skyper wrote:

miche101 wrote:
skyper wrote:
wenn der Schritt von OSM zu GTFS und nicht andersherum funktionieren soll geht es auch nicht ohne PTv2.
in GTFS ist der Wegeteil optional.. benötigt man nicht kann man haben muss aber nicht. In GTFS ist das dass Shape für jeden Trip.
Ja, genau, dieses Shape fehlt bei mir häufig oder ist kaputt bis ungenau. Wirklich exakte Shapes finde ich fast nicht und etliche dieser Shapes sollen laut Lizenz aus OSM-Daten stammen.
In Nicaragua werden so weit ich weiß die GTFS-Daten hauptsächlich aus OSM-Daten erstellt.

Stimmt:
* "stop_id" in GTFS ist "node/<id>" in OSM
* "route_id" in GTFS ist "relation/<id>" des Route-Masters

skyper wrote:

miche101 wrote:
skyper wrote:
Umstellung auf PTv2 ist ein wenig Aufwand, wobei ich die meiste Zeit immer noch mit den Stops und dem Verbessern der highways verbringe. Die eigentlichen Varianten sind dann nicht viel Aufwand.
ok... ich find das einen riesen Aufwand.
Das kann an der Arbeitsweise oder an den Linien liegen.
Zuerst kümmer ich mich meistens um die Stops.
Dann fange ich mit den langen Zweigen an. 1. Stops, 2. Wege (`Ctrl+W`).
Weiter Relationen erstelle ich dann mit Duplizieren und Löschen/Kopieren von bestimmten Stop-Sequenzen und Weg-Sequenzen.

dito

skyper wrote:

miche101 wrote:
skyper wrote:
Zum Zeitaufwand bei Updates kann ich Dir wohl frühestens zum Fahrplanwechsel nächste Weihnachten was sagen, oder Corona bring auch dann noch den Fahrplan durcheinander.
ja das ist nicht leicht weil man garnicht weiss welche Relation zu weilen Trip gehört.. im MVV wechseln die "IDs" jedes Jahr...
Das ist einer meiner großen Kritikpunkte an dem aktuellen GTFS-System.

bei VAG und MVV und anderen "Kunden" von MentzDV gibt es ja wenigstens noch eine Struktur 19-210-s21-1 == Bus 210, Saison 2021/2022, 1. Version (meine Interpretation, über die "19" weiß ich noch nichts).
Die zieht sich bis in die trips und shapes hinein.

skyper wrote:

miche101 wrote:
skyper wrote:
Zusätzlich zu PTv1 oder verzichtest Du auf die Darstellung bei den meisten ÖPV-Karten?
ja nach dem bisherigen System. Ich finde hier muss man mal moderere Lösungen zuwenden. Diese vorgekauten Relationen ist zu aufwendig, im Speziellen den Bereich "Bus" weil hier teils bis zu >40 Varianten auf eine Linien kommen.. das ist viel zu viel und müllt OSM zu.
Ich finde es nicht einfacher eine PTv1-Relation zu pflegen als 20 PTv2-Relationen und habe bisher keine PTv1 gefunden die so komplett richtig war und keine Wege gefehlt haben. Wie soll ich denn jetzt die GTFS-Daten zusammenschmelzen um diese mit PTv1 zu vergleichen. Auf die Shapes kann ich ja nicht zurückgreifen, da nicht gut Qualität und eventuell ehe schon aus OSM stammen (s.o.)?
Alles in allem, hoffe ich, dass PTNA bis Weihnachten/nächstes Jahr mir ein Geschenk macht und GTFS-Datensätze vergleichen kann.
Ciao skyper

Jetzt setzt du mich aber gewaltig unter Druck

Einen Ansatz habe ich, den werde ich "agil" freigeben (Als Osterei nach Ostern?), auch wenn derzeit noch nicht viel zu sehen ist.
Denn: ich brauche Zeit zum Überlegen, über das weitere Vorgehen kann dann gemeinsam diskutiert werden, ich maße mir nicht an alle Lösungen (jetzt schon) zu kennen, auch ich habe (z.T. übergroße) Scheuklappen.

Neben dem Vergleich von GTFS-Versionen steht auch noch was anderes auf dem Plan.

* Vergleich von OSM-Route-Relationen mit GTFS-Trips ... sofern "gtfs:trip_id:sample" oder "gtfs:shape_id" (und "gtfs:feed") in der Relation angegeben sind.
* * Anzahl Stops
* * Reihenfolge anhand name und stop_name ... großes Problem der Abkürzungen in den GTFS-Daten
* * Abstand zw. OSM-stop/platform und GTFS-Stop ... oder dieses doch lieber in einem eigenen/eigenständigen Haltestellen-spezifischen OSM-GTFS-Vergleich, wie bei MFDZ.de?
* alles unter der Prämisse, dass (CPU-/Execution-)Zeit eine knappe Resource auf dem Server ist (Runterladen und Analyse für unsere Zeitzone dauert derzeit schon ~ 4 Stunden)

Ciao Toni

Last edited by ToniE (2021-03-29 17:57:39)

streckenkundler · 2021-03-29 18:29:59

miche101 wrote:

streckenkundler wrote:
+1
Ich hatte mich hier in Lübben auch mal mit PTv2 etwas beschäftigt. Ich bin zum selben Ergebnis gekommen.
Ja, Danke dann bin ich ned alleine Ich werd da Thema auch mal auf Eis legen und in ein paar Jahren vielleicht nochmal schauen.

Ich hab da auch ein schönes Beispiel hier aus Lübben...

Der Straßenbereich ab hier bis hier wird gerade neu gebaut... Straße Komplett, die "Bogenbrücke" auch neu, die alte Brücke (Baujahr 1948) wir gerade abgerissen (Stand 29.3.2021) Es gibt eine Bauseitige Straßenführung nebst Behelfsbrücke.
Die Bushalstestelle "An der Kupka" existiert defakto zur Zeit nicht, das wird auch noch mindestens bis Ende 2021 oder Anfang 2022 so sein...

Baustelle also Bundesstraße, mit Bushaltestelle, begleitenden Rad-Fußwegen, eine Brücke über ein Hauptgewässer. Der Straßenbau dürfte komplett mit Gründung werden, da der Bereich bis 1945 Wiese war und z.T. mit Kriegsschutt aufgefüllt wurde. Die Brücke soll ihem Namen wieder alle Ehre machen (So sah es aus als sie im Zuge des Kriges gesprengt war: https://www.lr-online.de/imgs/29/6/3/5/ … 411df.jpeg

Wenn man sich das größerräumig anschaut: Das ist einzige Übergang, um von westlich der Spree nach östlich der Spree zu kommen...
In der Folge geht sämtlicher Verkehr über diesen Bereich und es müssten nach Ptv2 alle existerenden Busrouten angepasst werden. Derzeit erfasst sind eh nur ein Teil der Buslinien und die erfassten ist schon eine ganze Latte... Das ist hier nicht wirklich leistbar...

Sven

axelr · 2021-03-29 23:15:33

streckenkundler wrote:

...Ich hab da auch ein schönes Beispiel hier aus Lübben...

Du hast dort einen Note gesetzt mit der Aufforderung zum Stillhalten und Aussitzen der Baustelle.
Die etwa 40 Relationen wären schnell auf die nördliche Schleife verlegt, wenn du klarstellen würdest ob die Behelfsbrücke derzeit eingetragen ist.

miche101 · 2021-03-30 07:09:52

streckenkundler wrote:

Die Bushalstestelle "An der Kupka" existiert defakto zur Zeit nicht, das wird auch noch mindestens bis Ende 2021 oder Anfang 2022 so sein...

Da fängt man am besten garnicht erst an den Fehler hab ich auch schon gemacht. Ein Jahr ist schnell vorbei, dann passt es wieder

streckenkundler · 2021-03-30 07:35:18

axelr wrote:

streckenkundler wrote:
...Ich hab da auch ein schönes Beispiel hier aus Lübben...
Du hast dort einen Note gesetzt mit der Aufforderung zum Stillhalten und Aussitzen der Baustelle.
Die etwa 40 Relationen wären schnell auf die nördliche Schleife verlegt, wenn du klarstellen würdest ob die Behelfsbrücke derzeit eingetragen ist.

Na es werden bei solchen Geschichten von einigen gerne mal Straßensegmente komplett gelöscht... Es wird zwar gebaut, der ganze Abschnitt ist für den Fahrzeugverkehr weiterhin befahrbar und wird befahrbar gehalten.

Ich hab in dem Bereich lediglich erst mal alles was gebaut wird auf construction gesetzt, incl. der Bushaltestelle und deren Elemente und der straßenbegleitenden Wege. Da kommt wieder eine Bushaltestelle hin, wie das dann aussehen wird, wird man sehen, wenn es fertig ist.
Was Straße und Brücke anbelangt... Straße ist in einer temporären Lage, etwas verschoben. Die Behelfsbrücke liegt dicht neben dem (recht bald; =1-2 Tage; ehemaligen) Bestandsbauwerk. Hier hab ich auch lediglich die Straßenachse in die entsprechende Richtung verschoben. Mehr ist hier auch nicht nötig und es wird soviel wie möglich Historie erhalten.

Wie allerdings jetzt die Busrouten geführt werden, kann ich nicht sagen, Ob über Gubener Straße - Hauptstraße - Lohmühlengasse oder Gubener Straße - Hauptstraße - Kirchstraße - Poststraße... Es kann auch sein, daß einige Linien weiterhin über die Straße "An der Kupka" fahren, ohne Schleife.
Ich muß auch noch mal schauen, die Hauptstraße ist in einem Teilabschnitt deswegen auch Einbahnstraße, ich weiß nur nicht ab wo...

Ich kann jetzt aus dem Kopf auch nicht sagen, ob die Bushaltestelle "Gubener Straße" weiterhin aktiv ist und/oder ob die vor einiger Zeit außerbetrieb genommene Haltestelle Lohmühlengasse wieder reaktiviert wurde... Seit der Eintragung der Buslinien und Heute hat sich sehr viel verändert. Es kann sogar so sein, daß einige Linien komplett überarbeit werden müssten... Mit der Komplexität von PTv2 sitzt man da Tage mit kaum sichtbaren Ergebnissen...

Sven

streckenkundler · 2021-03-30 07:37:23

miche101 wrote:

Da fängt man am besten garnicht erst an den Fehler hab ich auch schon gemacht. Ein Jahr ist schnell vorbei, dann passt es wieder

+1
Wie eben erläutert... ich habe alles was gerade gebaut wird, erst mal auf construction gesetzt... Den Rest wird man sehen...

Pfad-Finder · 2021-03-30 12:22:03

OT: Aus Nutzerperspektive reichen mir im ländlichen Raum die Haltestellen. Linien sind für mich belanglos, da am Wochenende (also wenn ich fahre) sowieso alles anders ist. Schön wäre es, wenn man "auf dem Garmin" oder anderen handelsüblichen Karten-App auf einen Blick erkennen könnte, ob an einer bestimmten Haltestelle ein Plusbus fährt (1h-Takt Mo-Fr, 2h-Takt auch am WE). *Ich* würde ja einfach so etwas wie "name=Lübben, Markt +" machen, aber für Anhänger der Reinen Lehre ist das bestimmt Teufelszeug.:cool:

ToniE · 2021-03-30 14:41:55

Ja, das '+' in Name ist uncool.

Für den Fall, dass man keine Routen-Relationen hat ...

"route_ref" an der Haltestelle, aber das wertet wohl kaum jemand sichtbar aus.

Beispiel: "route_ref" = "210;221;241"

wenn dort die Busse 210, 221 und 241 halten. Die "reine Lehre" sagt: Trennsymbol ist das Semikolon ohne Blanks

mmd · 2021-03-30 17:32:38

ToniE wrote:

alles unter der Prämisse, dass (CPU-/Execution-)Zeit eine knappe Resource auf dem Server ist (Runterladen und Analyse für unsere Zeitzone dauert derzeit schon ~ 4 Stunden)

Interessehalber, was läuft da so lange? Sind das die Queries auf https://github.com/osm-ToniE/ptna-networks ?

ToniE · 2021-03-30 17:59:54

mmd wrote:

ToniE wrote:
alles unter der Prämisse, dass (CPU-/Execution-)Zeit eine knappe Resource auf dem Server ist (Runterladen und Analyse für unsere Zeitzone dauert derzeit schon ~ 4 Stunden)
Interessehalber, was läuft da so lange? Sind das die Queries auf https://github.com/osm-ToniE/ptna-networks ?

Auch, aber nicht nur ...

https://ptna.openstreetmap.de/en/statistics.php

mmd · 2021-03-30 21:37:56

Danke. Zu den Perl-Auswertungen kann ich nicht wirklich etwas sagen, für den anderen Teil würde etwas exklusive Rechenzeit sehr weiterhelfen. Alle 115 Queries, die ich im Repo entdeckt habe, laufen hier im Test in 15 Min. durch, jeweils bis zu 6 Queries gleichzeitig. Falls das Thema mal akut werden sollte...

ToniE · 2021-03-31 08:08:37

Danke für die Info.

Bei dem momentanen Ablauf von Overpass-Query, Analyse, Overpass-Query, Analyse, ... bekomme ich nur sehr selten "Quota-Probleme" mit dem Overpass-API-Server ... das passt schon.
Bzgl. Quota-Probleme mit Overpass-API-Server:
* ich pausiere 1 min und versuche es nochmals und gebe danach aber (für diesen Verbund) auf (und gehe zum nächsten Verbund)
* am Ende eines (Zeitzonen-spezifischen) Durchlaufs mache ich noch einen Durchlauf für alle Analysen, wo ich Quota-Probleme mit Overpass hatte (d.h. XML-Datei ist leer) - sofern es weniger als 10 Probleme gab. Bei mehr als 10 Problemen gehe ich von einem systematischen Problem aus und stoppe.

mmd wrote:

für den anderen Teil würde etwas exklusive Rechenzeit sehr weiterhelfen

"exklusive Rechenzeit", d.h. bevorzugte Behandlung auf dem Overpass-API-Server?

mmd wrote:

Zu den Perl-Auswertungen kann ich nicht wirklich etwas sagen

Zur Perl-Auswertung: die ist im Laufe der Jahre chaotisch gewachsen und eher als Ergebnis eines Lernprozesses zu sehen. Ein Redesign wäre u.U. auch unter Performanceaspekten hilfreich - aber die Zeit fehlt, ich mache das nur nebenbei (zumindest bis Ende September).

ToniE · 2021-03-31 08:16:01

mmd wrote:

Alle 115 Queries, die ich im Repo entdeckt habe, laufen hier im Test in 15 Min. durch, jeweils bis zu 6 Queries gleichzeitig. Falls das Thema mal akut werden sollte...

Ich hatte schon mal über eine lokale Instanz des Overpass-API auf dem Server nachgedacht, quasi nur via 127.0.0.1 erreichbar.

Aber das würde vermutlich die Grundlast (über 24h/d) auf dem Server erhöhen, nur um einen Peak zw. 02:00 und 06:00 bewältigen zu können.

skyper · 2021-03-31 15:29:29

ToniE wrote:

bei VAG und MVV und anderen "Kunden" von MentzDV gibt es ja wenigstens noch eine Struktur 19-210-s21-1 == Bus 210, Saison 2021/2022, 1. Version (meine Interpretation, über die "19" weiß ich noch nichts).
Die zieht sich bis in die trips und shapes hinein.

Die "19" sollte eine Klassifizierung des Fahrzeugs bzw. der Linien Art sein. Leider verwendet jede Gesellschaft ihr eigenes System. Bei der VAG-FR steht "11" für Tram, "10" für Bus, "13" für Bussonderverkehr und "14" für Linientaxi/AST.

In der Struktur steckt ja schon die Jahreszahl, damit ändert sich die Id zwangsläufig jährlich. Das ist ja auch nicht das größte Problem, aber das die Shapes keine eindeutige Nummerierung haben und der entsprechende Part nicht konstant bleibt, verstehe ich nicht.

ToniE wrote:

skyper wrote:
Alles in allem, hoffe ich, dass PTNA bis Weihnachten/nächstes Jahr mir ein Geschenk macht und GTFS-Datensätze vergleichen kann.
Ciao skyper
Jetzt setzt du mich aber gewaltig unter Druck

Ach, brauchst Du etwa etwas Druck?

ToniE wrote:

Einen Ansatz habe ich, den werde ich "agil" freigeben (Als Osterei nach Ostern?), auch wenn derzeit noch nicht viel zu sehen ist.
Denn: ich brauche Zeit zum Überlegen, über das weitere Vorgehen kann dann gemeinsam diskutiert werden, ich maße mir nicht an alle Lösungen (jetzt schon) zu kennen, auch ich habe (z.T. übergroße) Scheuklappen.

Da freue ich mich ja auf die Eiersuche. Cool

ToniE wrote:

Neben dem Vergleich von GTFS-Versionen steht auch noch was anderes auf dem Plan.
* Vergleich von OSM-Route-Relationen mit GTFS-Trips ... sofern "gtfs:trip_id:sample" oder "gtfs:shape_id" (und "gtfs:feed") in der Relation angegeben sind.
* * Anzahl Stops
* * Reihenfolge anhand name und stop_name ... großes Problem der Abkürzungen in den GTFS-Daten
* * Abstand zw. OSM-stop/platform und GTFS-Stop ... oder dieses doch lieber in einem eigenen/eigenständigen Haltestellen-spezifischen OSM-GTFS-Vergleich, wie bei MFDZ.de?
* alles unter der Prämisse, dass (CPU-/Execution-)Zeit eine knappe Resource auf dem Server ist (Runterladen und Analyse für unsere Zeitzone dauert derzeit schon ~ 4 Stunden)

Da hast Du ja ne ganz schön lange ToDo-Liste erstellt. Klingt super. Hätte ich doch Weihnachten 2022 schreiben sollen.

skyper · 2021-03-31 15:38:25

Um nochmal zum eigentlichen Thema zurückzukommen: ID hat es schon wieder getan und es war keine ungeübte Person (https://www.openstreetmap.org/changeset/101906436).

Ist es wirklich so schwer bei gerade verlaufenden Strecken ohne jegliche Schleifen die Ordnung zu erhalten?

mmd · 2021-03-31 19:24:19

ToniE wrote:

"exklusive Rechenzeit", d.h. bevorzugte Behandlung auf dem Overpass-API-Server?
...
Ich hatte schon mal über eine lokale Instanz des Overpass-API auf dem Server nachgedacht, quasi nur via 127.0.0.1 erreichbar.
Aber das würde vermutlich die Grundlast (über 24h/d) auf dem Server erhöhen, nur um einen Peak zw. 02:00 und 06:00 bewältigen zu können.

Als geteilte Resource wird das mit den öffentlichen Servern eher schwierig mit dem exklusiven Modus. Der Gedanke ging da schon in Richtung eigene Instanz. Die Updates müssen auch nicht unbedingt kontinuierlich den ganzen Tag über reinlaufen. Stündliche oder sogar tägliche Updates wären auch denkbar. Letzteres würde auch im Rahmen von 15-30 Min. machbar sein.

Solange das aktuelle Verfahren so trägt und im Zeitrahmen machbar ist, ist das auch völlig ok. Es war wie gesagt nur eine Überlegung, welche Alternativen bestehen, um diesen Teil der Gesamtlaufzeit zu drücken.

ToniE · 2021-03-31 20:33:53

mmd wrote:

Die Updates müssen auch nicht unbedingt kontinuierlich den ganzen Tag über reinlaufen. Stündliche oder sogar tägliche Updates wären auch denkbar.

Das hört sich gut an.

Die Zeitzonen-spezifischen Analysen werden so gegen 02:00 oder 03:00 Ortszeit gestartet (Sommer-/Winterzeit wird nicht kompensiert), wenn die lokalen Mapper schlafen.

Jeweils kurz vorher einen Update zu machen würde reichen, der würde auch für uns in UTC+01 für 4 Stunden tragen, keine weiteren stündlichen Updates notwendig.
Stündliche Updates würden aber auch nicht schaden, wären sogar hilfreich, wenn ich eine Analyse tagsüber mal manuell starten will.

Wenn ich es dann noch schaffen könnte, die 166 Analysen in UTC+01 parallel laufen zu lassen, wäre das toll und auch machbar ... aber nicht gut.
Maximal 5 (?) parallele Jobs zuzulassen wäre für den Server durchaus verkraftbar.

Announcement

#126 2021-03-22 16:54:58

Re: Neuer Mapper bearbeitet Busrelationen

#127 2021-03-22 20:01:54

Re: Neuer Mapper bearbeitet Busrelationen

#128 2021-03-22 20:06:29

Re: Neuer Mapper bearbeitet Busrelationen

#129 2021-03-23 17:21:28

Re: Neuer Mapper bearbeitet Busrelationen

#130 2021-03-23 17:29:14

Re: Neuer Mapper bearbeitet Busrelationen

#131 2021-03-25 12:39:23

Re: Neuer Mapper bearbeitet Busrelationen

#132 2021-03-29 16:39:12

Re: Neuer Mapper bearbeitet Busrelationen

#133 2021-03-29 17:08:37

Re: Neuer Mapper bearbeitet Busrelationen

#134 2021-03-29 17:55:40

Re: Neuer Mapper bearbeitet Busrelationen

#135 2021-03-29 18:29:59

Re: Neuer Mapper bearbeitet Busrelationen

#136 2021-03-29 23:15:33

Re: Neuer Mapper bearbeitet Busrelationen

#137 2021-03-30 07:09:52

Re: Neuer Mapper bearbeitet Busrelationen

#138 2021-03-30 07:35:18

Re: Neuer Mapper bearbeitet Busrelationen

#139 2021-03-30 07:37:23

Re: Neuer Mapper bearbeitet Busrelationen

#140 2021-03-30 12:22:03

Re: Neuer Mapper bearbeitet Busrelationen

#141 2021-03-30 14:41:55

Re: Neuer Mapper bearbeitet Busrelationen

#142 2021-03-30 17:32:38

Re: Neuer Mapper bearbeitet Busrelationen

#143 2021-03-30 17:59:54

Re: Neuer Mapper bearbeitet Busrelationen

#144 2021-03-30 21:37:56

Re: Neuer Mapper bearbeitet Busrelationen

#145 2021-03-31 08:08:37

Re: Neuer Mapper bearbeitet Busrelationen

#146 2021-03-31 08:16:01

Re: Neuer Mapper bearbeitet Busrelationen

#147 2021-03-31 15:29:29

Re: Neuer Mapper bearbeitet Busrelationen

#148 2021-03-31 15:38:25

Re: Neuer Mapper bearbeitet Busrelationen

#149 2021-03-31 19:24:19

Re: Neuer Mapper bearbeitet Busrelationen

#150 2021-03-31 20:33:53

Re: Neuer Mapper bearbeitet Busrelationen

Board footer