You are not logged in.

#26 2020-05-19 07:49:48

miche101
Member
Registered: 2008-12-16
Posts: 1,089

Re: PTNA - News: ÖPNV-Analyse

ToniE wrote:

Was fehlt (mir) noch?

jetzt ist die Relation-Analyse dem GTFS fast gleich auf wink Jetzt wäre noch ein GPX download mit und ohne Shape noch fehlen.. und die Möglichkeit des Routings

Eventuell könnte man bei der Relations-Analyse gefundenen Fehler auch in der Karte darstellen hmm

Offline

#27 2020-05-19 08:02:10

miche101
Member
Registered: 2008-12-16
Posts: 1,089

Re: PTNA - News: ÖPNV-Analyse

...obwohl der Radschluss wäre geschafft wenn man aus den OSM Daten einen GTFS Feed generieren kann smile ...aber wir nähern uns..

bei GPX... wäre wpt <= OSM platform(wenn nicht vorhanden, sollte nicht sein wink dann stop_position), rte-Teil <= OSM stop_position, bzw. wenn nicht vorhanden Platform. Prüfen anhand des name=*  wink

Offline

#28 2020-05-19 11:27:57

ToniE
Member
From: Ottobrunn, Bayern, Germany
Registered: 2016-06-13
Posts: 510

Re: PTNA - News: ÖPNV-Analyse

... über diese Dinge kann man reden smile

Im Moment bin ich gerade fertig geworden einen / zwei Fortschrittsbalken zu realisieren und den Code so umzustellen, dass der Browser nicht blockiert, wenn's mal etwas länger dauert.

Jedes Member wird durch eine Funktion analysiert, die durch einen setTimeout( handleMember, 0 /* msec Pause */, ++index ) am Ende einer solchen Analyse für das nächste Member gestartet wird.

Dadurch bleibt der Browser offen für Mouse-, Keyboard-, ... und andere Events. Viel langsamer wird's dadurch insgesamt nicht, aber "bedienbar" big_smile

S 1 in München geht noch recht flott

ICE von Hamburg über Berlin nach München dauert mit 1315 Ways schon recht lange, aber der Browser und das Map-Fenster können noch bedient werden und man kann der Liste der Ways beim Wachsen zusehen wink

Aber, wie schon einmal geschrieben: für große Relationen braucht man Geduld, bei kleineren merkt man kaum eine Verzögerung.

Last edited by ToniE (2020-05-19 11:36:22)


Alle Edits meiner Kommentare sind (nur) Typofixes, wenn nicht explizit anders angegeben.

Offline

#29 2020-05-20 17:40:12

miche101
Member
Registered: 2008-12-16
Posts: 1,089

Re: PTNA - News: ÖPNV-Analyse

ToniE wrote:

dass der Browser nicht blockiert, wenn's mal etwas länger dauert.

...a ja des Problem kenn ich das muss man asynchron laden smile

aus:

request.open( "GET", url, false );

wird:

request.open( "GET", url, true );

In der Funktion wird dann geregelt.. was passiert wenn sich er Status änder....

request.onreadystatechange = function() {

bzw. was passiert wenn es fertig geladen ist:

if ( request.status === 200 ) {

smile Der Balken ist gut cool

Offline

#30 2020-05-20 18:05:24

ToniE
Member
From: Ottobrunn, Bayern, Germany
Registered: 2016-06-13
Posts: 510

Re: PTNA - News: ÖPNV-Analyse

Die GET-requests sind eigentlich nicht das Problem.

Den ersten (großen) GET request ans API von OSM mache ich tatsächlich asynchron. Der dauert meist so zw. 50 und 150msec und liefert fast alles was ich an Nodes, Ways und so weiter brauche - bis auf (Plattform-)Relationen.

Die weiteren kleineren GET-requests mache ich dann synchron, weil's von der Programmablauflogik so am einfachsten ist.
Hierbei sind in der Regel Platform-Relationen nachzuladen (wenig Daten), das synchrone Laden ist nicht so kritisch.

Kritisch war die z.T. recht lange Analyse, d.h. das Abarbeiten der Member-Liste der route-Relation - nachdem die Daten schon da sind.
Diese Arbeit wurde in einer langen for-Schleife gemacht, bei der der Browser bzgl. dieses Fensters blockiert ist.

Durch das setTimeout( function(), 0, parameter-der-function ) erfolgt lediglich eine kurze Unterbrechung des JS-Programms (re-scheduling), so dass der Browser Mouse-, Keyboard-, und andere Events bearbeiten kann. Dadurch kann man den Browser im Fenster wieder bedienen (in die Karte rein-zoomen, ...) während die Analyse weiter läuft.

Pro Timeout bearbeite ich mittlerweile 5 Member (nicht mehr nur einen), was insgesamt etwas schneller läuft, ohne die Bedienbarkeit des Browsers zu sehr zu stören. Das hatte ich auch mit 50, 20 und 10 Member versucht, aber das war beim Rein-Zoomen in die Karte dann nicht mehr flüssig.

Der Balken ist ein HTML5 feature "<progress id="analysis" value=x max=100></progress> <span id="analysis_data">x<</span> %" und 'x' wird mittels JS aktualisiert.

Zusatz: der Balken funktioniert nur, wenn man asynchron (d.h. bei mir mit setTimeout) arbeitet.

Last edited by ToniE (2020-05-20 18:11:03)


Alle Edits meiner Kommentare sind (nur) Typofixes, wenn nicht explizit anders angegeben.

Offline

#31 2020-05-20 18:20:25

miche101
Member
Registered: 2008-12-16
Posts: 1,089

Re: PTNA - News: ÖPNV-Analyse

ToniE wrote:

Die weiteren kleineren GET-requests mache ich dann synchron, weil's von der Programmablauflogik so am einfachsten ist.
Hierbei sind in der Regel Platform-Relationen nachzuladen (wenig Daten), das synchrone Laden ist nicht so kritisch.

ok.. drum.. is ja irre... klingt sehr kompliziert hmm

Offline

#32 2020-05-20 18:30:11

ToniE
Member
From: Ottobrunn, Bayern, Germany
Registered: 2016-06-13
Posts: 510

Re: PTNA - News: ÖPNV-Analyse

miche101 wrote:

Den ersten (großen) GET request ans API von OSM mache ich tatsächlich asynchron. Der dauert meist so zw. 50 und 150msec und liefert fast alles was ich an Nodes, Ways und so weiter brauche - bis auf (Plattform-)Relationen.

Um präzise zu sein: - bis auf die Member der (Plattform-)Relationen.

Die brauche ich aber um sie zu zeichnen und um an eine lat/lon-Koordinate zu kommen (1. Node oder 1. Node vom 1. Way der Relation)

miche101 wrote:

ok.. drum.. is ja irre... klingt sehr kompliziert hmm

Schon irgendwie, spannend allemal bis es funktioniert. Man muss sich loslösen vom sequentiellen Abarbeiten des Codes ...
Für die synchronen GET-requests ist mir auch gerade was eingefallen Richtung asynchron.

Last edited by ToniE (2020-05-20 18:30:32)


Alle Edits meiner Kommentare sind (nur) Typofixes, wenn nicht explizit anders angegeben.

Offline

#33 2020-05-24 10:43:43

miche101
Member
Registered: 2008-12-16
Posts: 1,089

Re: PTNA - News: ÖPNV-Analyse

Wieder was interessantes gefunden: Hier darf der Bus gegen Einbahnstr. fahren smile

Stimmt das tagging so:
https://www.openstreetmap.org/way/255282608

Offline

#34 2020-05-24 11:31:39

ToniE
Member
From: Ottobrunn, Bayern, Germany
Registered: 2016-06-13
Posts: 510

Re: PTNA - News: ÖPNV-Analyse

miche101 wrote:

Wieder was interessantes gefunden: Hier darf der Bus gegen Einbahnstr. fahren smile

Stimmt das tagging so:
https://www.openstreetmap.org/way/255282608

Korrekt, zumindest was PTNA angeht.


Alle Edits meiner Kommentare sind (nur) Typofixes, wenn nicht explizit anders angegeben.

Offline

#35 2020-06-02 14:20:36

ToniE
Member
From: Ottobrunn, Bayern, Germany
Registered: 2016-06-13
Posts: 510

Re: PTNA - News: ÖPNV-Analyse

Update:

Drei neue Features sind fertig:

1. in den CSV-Daten kann nun ein Verweis auf die GTFS-Daten (von PTNA) hinterlegt werden:

210;bus;;Brunnthal, Zusestraße;Neuperlach Süd U S;Verkehrsbetrieb Ettenhuber GmbH;DE-BY-MVV;19-210-s20-1

Dazu wird der GTFS-Feed benannt (hier "DE-BY-MVV") sowie die GTFS-route_id zu dieser Linie (hier "19-210-s20-1").
Daraus wird ein Link "GTFS" auf die GTFS-Analyse von PTNA in der Titelzeile der Linie generiert.
Die Daten hierzu können mit dem Button "Download als CSV-Liste für PTNA" GTFS-Feed-spezifisch abgerufen werden (Beispiel für DE-BY-MVV).


2. "gtfs:*" (und "gtfs_*") tags in den Relationen

diese werden in der Spalte "Anmerkungen" ausgegeben.


3. In der Spalte "Relation (id=)" wird ein Link auf die GTFS-Analyse von PTNA generiert wenn:

* bei Route-Master als GTFS-Info "gtfs:route_id" abgegeben ist
* bei Route als GTFS-Info "gtfs:trip_id" bzw. "gtfs:route_id" angegeben ist (in dieser Reihenfolge ausgewertet)

Als GTFS-Feed (Link zu den Daten) wird entweder "operator:guid" oder "network:guid" oder die Auswerteoption "--gtfs-feed=" hergenommen (in dieser Reihenfolge ausgewertet).


Die Punkte 2. und 3. sind derzeit erst für DE-BY-MVV und DE-BW-RFV freigeschaltet ... die anderen kommen in Kürze

Gesteuert wird Punkt 2. durch die Option: "--show-gtfs". Punkt 3. wird durch die Option: "--link-gtfs" ermöglicht.


Hinweis:

"route_id" und "trip_id" können sich von GTFS-Version zu GTFS-Version ändern. Beim MVV ändern sie sich definitiv im Dezember, mit dem Fahrplanwechsel.
Dabei ändern sich manchmal, aber nicht zwangsläufig auch die Routen der Busse, ... (Ausschreibungen laufen beim MVV meist für 3 oder 5 Jahre).
In wie weit das Mappen von "route_id", trip_id", "shape_id", ... in OSM sinnvoll ist? Entscheidet selbst, mir hat's schon viel geholfen.


Ausblick:

Eine weitere Option "--check-gtfs" ist in Arbeit: sie wird prüfen ob

* "gtfs:route_id" für Route-Master und alle Member-Routes identisch ist, ob
* "gtfs:trip_id" unter allen Member-Routen eindeutig ist, ob
* eine entsprechende Route-ID/Trip-ID in der GTFS-Analyse zum GTFS-Feed zu finden ist,
* wenn eine Trip-ID in den GTFS-Daten gefunden wird kann geprüft werden,
** ob alle Haltestellen in der Relation enthalten sind,
** mit korrekten Name (was immer "korrekt" meint),
** in der richtigen Reihenfolge, ...
** bis hin zu Auswertung evtl. vorhandener Shape-Daten gegenüber dem gemappten Fahrweg, ...

Last edited by ToniE (2020-06-02 14:23:20)


Alle Edits meiner Kommentare sind (nur) Typofixes, wenn nicht explizit anders angegeben.

Offline

#36 2020-06-03 13:37:29

miche101
Member
Registered: 2008-12-16
Posts: 1,089

Re: PTNA - News: ÖPNV-Analyse

ToniE wrote:

* bei Route als GTFS-Info "gtfs:trip_id" bzw. "gtfs:route_id" angegeben ist (in dieser Reihenfolge ausgewertet)

Bei z.B.: Bus 561 finde ich es das es das ganze ganz schön aufbläht und unübersichtlich wird... man könnte vielleicht die Spaltenbreite erhöhen hmm oder weg lassen..


'check_date' =
 '2020-05-04'
'gtfs:route_id' = '19-561-
s20-1'
'gtfs:trip_id' = 
'17.T0.19-561-s20-1.7.H'
'gtfs:trip_id:like' = 
'%19-561-s20-1.7.H'

Der Link zum GTFS find ich gut :-)

Offline

#37 2020-06-03 14:07:49

ToniE
Member
From: Ottobrunn, Bayern, Germany
Registered: 2016-06-13
Posts: 510

Re: PTNA - News: ÖPNV-Analyse

miche101 wrote:
ToniE wrote:

* bei Route als GTFS-Info "gtfs:trip_id" bzw. "gtfs:route_id" angegeben ist (in dieser Reihenfolge ausgewertet)

Bei z.B.: Bus 561 finde ich es das es das ganze ganz schön aufbläht und unübersichtlich wird... man könnte vielleicht die Spaltenbreite erhöhen hmm oder weg lassen..


'check_date' =
 '2020-05-04'
'gtfs:route_id' = '19-561-
s20-1'
'gtfs:trip_id' = 
'17.T0.19-561-s20-1.7.H'
'gtfs:trip_id:like' = 
'%19-561-s20-1.7.H'

Der Link zum GTFS find ich gut :-)


Stimmt, aber könnten wir das für eine Übergangszeit noch drin lassen (läßt sich durch wegnehmen von --show-gtfs leicht wieder entfernen)?

An den Spaltenbreiten möchte ich bewusst nicht drehen, da komme ich irgendwann in Teufels Küche und weiß nicht mehr wo, was, wie gedreht werden sollte.

Bei uns mit MVV wegen fehlender Shape-Daten nicht relevant, für DE-BW-RVF z.B. aber schon:

* bei Route als GTFS-Info "gtfs:trip_id", "gtfs:shape_id" bzw. "gtfs:route_id" angegeben ist (in dieser Reihenfolge ausgewertet)

Last edited by ToniE (2020-06-03 14:10:01)


Alle Edits meiner Kommentare sind (nur) Typofixes, wenn nicht explizit anders angegeben.

Offline

Board footer

Powered by FluxBB