You are not logged in.

#76 2020-04-16 19:47:44

seichter
Member
Registered: 2011-05-21
Posts: 2,901

Re: PTNA - News: GTFS-Analyse

streckenkundler wrote:

Schreibt mal bitte beim VBB https://ptna.openstreetmap.de/results/D … lysis.html Potsdam mit s und nicht mit z... Potsdam mit z zu schreiben, tut den Augen etwas weh...

Potsblits - diese Buchstabenvertauscher!
SCNR

Offline

#77 2020-04-16 20:10:12

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

Re: PTNA - News: GTFS-Analyse

streckenkundler wrote:

Kleine Anmerkung in Sachen verdrehte Bachstuben... ähm Buchstaben....

Schreibt mal bitte beim VBB https://ptna.openstreetmap.de/results/D … lysis.html Potsdam mit s und nicht mit z... Potsdam mit z zu schreiben, tut den Augen etwas weh...

Ansonsten... gab es nicht auch gtfs-Daten zu Buslinien in Brandenburg? ...oder habe ich in der Auswertung nur zu flüchtig geschaut?

Sven

"Mea culpa" oder so ähnlich zum Punkt 1.

Zu Punkt 2: Die Struktur der Auswertung stammt von mir und ist unter https://wiki.openstreetmap.org/wiki/Ver … VBB-Routes im OSM-Wiki zu finden - kann entsprechend von jedem (orts-)kundigen angepasst werden - was ich mir auch wünschen würde.

Kann sein, dass die "fehlenden" Busse aus Brandenburg unter Abschnitt 2.7.3 (https://ptna.openstreetmap.de/results/D … tml#A2.7.3) oder Abschnitt 4.3 (https://ptna.openstreetmap.de/results/D … .html#A4.3) zu finden sind.

Ich habe angefangen nach Städten zu sortieren, genauer gesagt nach 'Operator', bei denen sich die Stadt herleiten ließ.
Da sind unter 2.7.3 sicherlich auch Operator-Werte wie 'Regionale Verkehrsgesellschaft Dahme-Spreewald mbH', 'Uckermärkische Verkehrsgesellschaft mbH', 'Busverkehr Oder-Spree GmbH' und 'Havelbus Verkehrsgesellschaft mbH' bei denen ich mich hier von München aus schwer tue diese einem Ort oder so zuzuordnen.

Wie oben gesagt: ... im OSM-Wiki zu finden - kann entsprechend von jedem (orts-)kundigen angepasst werden.

Toni


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

Offline

#78 2020-04-16 20:15:19

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

Re: PTNA - News: GTFS-Analyse

seichter wrote:
streckenkundler wrote:

Schreibt mal bitte beim VBB https://ptna.openstreetmap.de/results/D … lysis.html Potsdam mit s und nicht mit z... Potsdam mit z zu schreiben, tut den Augen etwas weh...

Potsblits - diese Buchstabenvertauscher!
SCNR

Meine Signatur auf dem Smartphone:

"vom Smartphone gesendet, kann daher Tepfihler und Dank Autokorrektur auch mehr würzige Formulierungen enthalten."

Last edited by ToniE (2020-04-16 20:15:41)


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

Offline

#79 2020-04-16 20:29:34

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

Re: PTNA - News: GTFS-Analyse

miche101 wrote:

Hab für alle eine ID generiert..

miche101 wrote:

Hätte nicht gemeint das es so gut geht mit meiner waghalsigen gerechneten ID lol ( Es ist nur ein wenig aufwendig alle IDs zu erstellen.. für alle GTFS trips und alle OSM Relationen )

Hört sich gut an, ich verstehe hier aber nicht was mit 'ID' gemeint ist und wie die berechnet wird. Sind das die 'gerundeten' lat/lon-Dinger?

Den Post #46 habe ich - glaube ich - wohl verstanden.

Gruß
Toni


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

Offline

#80 2020-04-16 20:39:10

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

Re: PTNA - News: GTFS-Analyse

@Miche: BTW: zum Thema JOSM und Overpass-API und ...

Ich hatte überlegt, aus einem JavaScript heraus ein Reihe von HTTP-GET localhost:8111/load_and_zoom... an JOSM zu senden (synchron) um so die engere Umgebung der Haltestellen in den JOSM zu laden.

Auch hier wieder eine Frage der Menge der Anfragen. Vor Allem, wenn man auf diese Weise noch alle, jeden 2. oder jeden 5. Shape-Punkt laden will.

Da überlastet man schnell mal das API und zwischen zwei GETs 100msec oder mehr zu warten verlangsamt das ganze zu sehr.

Hat irgendwer Erfahrungen mit solch einem Ansatz?


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

Offline

#81 2020-04-16 21:14:04

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

Re: PTNA - News: GTFS-Analyse

ToniE wrote:

Hört sich gut an, ich verstehe hier aber nicht was mit 'ID' gemeint ist und wie die berechnet wird. Sind das die 'gerundeten' lat/lon-Dinger?

Den Post #46 habe ich - glaube ich - wohl verstanden.

ja genau... also ich versuche über eine lat lon Liste... einen möglichst kurzen Wert du erhalten. Problem ich möchte GTFS und OSM vergleichen.... die Haltestellen haben nur ungefähr eine ähnliche Position...

jetzt nimm ich einen vierstelligen lat und lon wert.. und runde... ( Das Runden kann mal einen ausreißer verursachen hmm wenn Gtfs auf und OSM z.B. abgerundet werden würde... aber wie oft kommt das vor... bei Bus 446 kein einziges mal.. fehlt mir der erfahrungswert )

Andere methode die ich mir gedacht habe bis jetzt nur die erste lat lon vierstellig zu nehmen und dann nur die bewegungsrichtung (1-4 oder 1-8) pro Haltestelle zu nehmen aber wäre unschärfer aber... auch eine idee wink )

Bereichnung ist bis jetzt

x = runden(lat * 100; 0)

man könnte auch die eine zweite "id" machen mit einem anderen mulipikator um das runden Problem zu umgehen... und dadurch eine übereinstimmung finden

x = runden(lat * 120; 0 ) / 120 * 100


...ich kürze die Liste damit ab das ich den kleinsten lat bzw. lon von allen werten abziehe



Aber aber... man könnte auch alle genauen lat/lon in eine Liste ausgeben und dann wird das vergleichen halt aufwendiger... das man erst die anzahl der werte vergleicht und dann alle einzelwerte voneinander abzieht und die abweichung vergleicht..

Offline

#82 2020-04-16 21:31:44

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

Re: PTNA - News: GTFS-Analyse

ToniE wrote:

Ich hatte überlegt, aus einem JavaScript heraus ein Reihe von HTTP-GET localhost:8111/load_and_zoom... an JOSM zu senden (synchron) um so die engere Umgebung der Haltestellen in den JOSM zu laden.

nein sowas hab ich noch nicht gemacht... da müsste man mehrere URLs virtuell Klicken und dann werden viele Dinge geladen.

Ich mach eigentlich nur noch den Ansatz aus Post #45 ... ich verroute die Punkte... lade ein gpx runter.. erstelle dann aus dem gpx und den Punkte automatisch eine (riesige) Overpass Abfrage, wobei das ja keine Abfrage ist die öfters gemacht wird... sondern nur einmalig. In sofern hab ich da kein schlechtes Gewissen dabei. Da werden dann nur wenig zuviel geladen... muss nur beim teilen aufpassen, wenn notwendig... Dann geht alles sehr schnell smile

Offline

#83 2020-04-17 07:40:54

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

Re: PTNA - News: GTFS-Analyse

Das Runden hier z.B.: fast ein Problem..

https://www.openstreetmap.org/node/562952831

lat:  48,1949448

hätte die Mvv hier: 49,195000 dann würde es anders gerundet, aber hat sie nicht smile

lat: 48.1949190164032

https://ptna.openstreetmap.de/gtfs/DE/s … -s20-1.7.H

Offline

#84 2020-04-17 12:12:32

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

Re: PTNA - News: GTFS-Analyse

miche101 wrote:

.. erstelle dann aus dem gpx und den Punkte automatisch eine (riesige) Overpass Abfrage, wobei das ja keine Abfrage ist die öfters gemacht wird... sondern nur einmalig.

Der Ansatz ist auch besser als 20-50 HTTP-GET Requests an JOSM zu senden ... ohne Frage.

Das 'riesige' hatte mich aufgeschreckt und  ... ist die Overpass-Abfrage nicht ein GET, d.h. URL-encoded und somit von der Länge limitiert.
Oder kann man das auch per POST machen?

Dann hätten wie eine gute Lösung via Overpass-Query und JOSM und für z.B. 30 Stops und > 100 Shape-Punkte anwendbar.


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

Offline

#85 2020-04-17 12:26:36

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

Re: PTNA - News: GTFS-Analyse

aso... man kann mit josm die overpass Abfrage direkt ausführen... aber über HTTP-GET/POST Requests k.A. hmm

Offline

#86 2020-04-17 12:30:45

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

Offline

#87 2020-04-17 15:18:23

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

Re: PTNA - News: GTFS-Analyse

..doch geht cool

mit Overpass kann man Exportieren und da gibt es eine Möglichkeit, über import?url= smile

http://127.0.0.1:8111/import?url=http%3A%2F%2Foverpass-api.de%2Fapi%2Finterpreter%3Fdata%3Dnode%255Bamenity%253Ddrinking_water%255D(41.88480278838879%252C12.481091022491455%252C41.89520166275077%252C12.50291347503662)%253Bout%2520meta%253B

Offline

#88 2020-04-17 15:50:38

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

Re: PTNA - News: GTFS-Analyse

miche101 wrote:

..doch geht cool

mit Overpass kann man Exportieren und da gibt es eine Möglichkeit, über import?url= smile

http://127.0.0.1:8111/import?url=http%3A%2F%2Foverpass-api.de%2Fapi%2Finterpreter%3Fdata%3Dnode%255Bamenity%253Ddrinking_water%255D(41.88480278838879%252C12.481091022491455%252C41.89520166275077%252C12.50291347503662)%253Bout%2520meta%253B

Genau das ist das Problem: wie lang darf der String oben sein. 255 Byte, ... 8K ....? Denn das ist ja ein GET-request.

Es gibt Angaben, dass FF 8K (in der Adressleiste) unterstützt, dass einige Webserver (Apache, ...?) auch 8K unterstützen.

Der String oben bedeutet ja, dass JOSM zunächst den Web-Server spielt, die URL (?url=...) aber eigentlich an overpass-api.de weitergibt.

https://overpass-api.de/command_line.html wrote:

"Overpass API accepts both HTTP GET and HTTP POST requests."

Also bleibt JOSM und die Frage, ob JOSM POST requests akzeptiert - schon mal ein Schritt weiter. Denn dann könne die Queries wirklich "riesig" sein.

Kann ich ja mal ausprobieren.


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

Offline

#89 2020-04-17 16:26:48

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

Re: PTNA - News: GTFS-Analyse

ToniE wrote:

Also bleibt JOSM und die Frage, ob JOSM POST requests akzeptiert - ...
Kann ich ja mal ausprobieren.

Nope: "501 not implemented"


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

Offline

#90 2020-04-17 16:42:11

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

Re: PTNA - News: GTFS-Analyse

schade... dann braucht man doch einen manuellen Schritt wink

Offline

#91 2020-04-17 16:53:33

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

Re: PTNA - News: GTFS-Analyse

ich hab mich mal dem Bus 440 probiert.. mit id zu vergleichen.. läuft gut smile ID erstellen hab ich ein wenig vereinfacht... aber ich mach immernoch fehler beim kopieren roll

https://greymiche.lima-city.de/440_bus.ods

(Gelb ist was kein paar gefunden hat... mehrere Tabellen! smile )

Offline

#92 2020-04-18 10:55:34

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

Re: PTNA - News: GTFS-Analyse

ToniE wrote:
miche101 wrote:

..doch geht cool

mit Overpass kann man Exportieren und da gibt es eine Möglichkeit, über import?url= smile

http://127.0.0.1:8111/import?url=http%3A%2F%2Foverpass-api.de%2Fapi%2Finterpreter%3Fdata%3Dnode%255Bamenity%253Ddrinking_water%255D(41.88480278838879%252C12.481091022491455%252C41.89520166275077%252C12.50291347503662)%253Bout%2520meta%253B

Genau das ist das Problem: wie lang darf der String oben sein. 255 Byte, ... 8K ....? Denn das ist ja ein GET-request.

Es gibt Angaben, dass FF 8K (in der Adressleiste) unterstützt, dass einige Webserver (Apache, ...?) auch 8K unterstützen.

Der String oben bedeutet ja, dass JOSM zunächst den Web-Server spielt, die URL (?url=...) aber eigentlich an overpass-api.de weitergibt.

https://overpass-api.de/command_line.html wrote:

"Overpass API accepts both HTTP GET and HTTP POST requests."

Also bleibt JOSM und die Frage, ob JOSM POST requests akzeptiert - schon mal ein Schritt weiter. Denn dann könne die Queries wirklich "riesig" sein.

Kann ich ja mal ausprobieren.

Wie bereits geschrieben: JOSM akzeptiert kein POST.

Aber ich werde mich mal an die maximale akzeptierte Länge der Query ran tasten und einen Button auf der Seite machen, mit dem man sich (möglichst viele) kleine Umgebungen der Haltestellen und Shape-Punkte via Overpass in JOSM laden kann.

So nach dem Motto: 8K werden von JOSM akzeptiert, minus 500 byte Overpass-Drumherum = 7.5K.
Pro Punkt 75 byte macht ungefähr 100 Punkte, deren Umgebung man runter laden könnte.
Bei 20 Haltestellen und 400 Shape-Punkten wären das alle Haltestellen und jeden 5. Shape-Punkt ... alles nur sehr grobe Schätzung.


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

Offline

#93 2020-04-18 12:15:54

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

Re: PTNA - News: GTFS-Analyse

ToniE wrote:

Aber aber... man könnte auch alle genauen lat/lon in eine Liste ausgeben und dann wird das vergleichen halt aufwendiger... das man erst die anzahl der werte vergleicht und dann alle einzelwerte voneinander abzieht und die abweichung vergleicht..

... was mit einfällt: was nun kommt ist Blödsinn oder bietet zumindest keine brauchbare Lösung, habe ich beim Schreiben bemerkt

es gibt da in Excel ein Add-In ("Solver", aber man muss ja auch nicht Excel nehmen), mit dem man bei gegebenen x,y-Werten (lat,lon) versuchen kann eine Formel zu erstellen, deren Graph möglichst nah an allen Punkten vorbei läuft - sprich: die Standardabweichung ist möglichst klein.

Im einfachsten Fall per Linearer Regression z.B. f(x) = 2 x + 3

oder sehr komplex z.B.: f(x) = 3 x**4 - 5 x**3 + 2 x**2 + 3 x + 3

und vergleichen kann, ob bei GTFS-Points und OSM-Points die selbe Funktion herauskommt.

... und nun gehen die Pferde mit mir durch ... und werfen mich ab ...

Hindernisse: das funktioniert nur, wenn sich der Bus irgendwie nur von West nach Ost bewegt, keine Schleifen bildet, ...
Es sei denn, man sortiert die (lat/lon)-Paare streng nach aufsteigendem 'lat', wodurch man aber die Charakteristik der Buslinie (Reihenfolge der angefahrenen Haltestellen) komplett verändert und sich zwei Buslinien u.U. wiederum kaum von einander unterscheiden würden.

Na ja: wie gesagt Blödsinn oder im besten Fall keine Lösung.


Generell zum dem Thema: Ich hatte eher an Anzahl und 'Name' der Haltestellen gedacht: mit/ohne Ortsname, normalisiert (d.h. str. -> straße), ...


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

Offline

#94 2020-04-18 12:37:11

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

Re: PTNA - News: GTFS-Analyse

miche101 wrote:
ToniE wrote:

    Die 5 (?) angegebenen Zeiten würde ich dann nach Uhrzeit aufsteigend sortieren und die Gesamtanzahl mit angeben.

Ja passt smile Beim 463 werden einige Varianten nur einmal am Tag gefahren... da ist es halt besonders schwierieg.. Als Fahrer des Busses muss ja des voll blöd sein immer verschiedene Routen einzuschlagen hmm

Ist fertig, ohne Limit auf 5, d.h. es werden alle angegeben.

Ich bin mit der Lösung aber nicht so recht glücklich, da die Zeit der Aggregierung (Vorbereitungsphase, bevor ich die Daten veröffentliche) nun beim MVV von 21 Min auf 41 Minuten gestiegen ist.

So weit so gut und nicht so tragisch.

Aber beim VBB dauert diese Phase derzeit schon 16 Stunden, dann 32 Stunden (?) ist schon recht viel - selbst wenn ich alle Schritte weiter automatisieren werde.


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

Offline

#95 2020-04-18 13:00:10

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

Re: PTNA - News: GTFS-Analyse

ToniE wrote:

Ist fertig, ohne Limit auf 5, d.h. es werden alle angegeben.

Hab ich schon gesehen... hab es gleich genutzt um die Uhrzeiten bei den zwei Relationen zu aktualisieren smile Die Sekunden Angabe bräuchte ich nicht wink

ToniE wrote:

Aber beim VBB dauert diese Phase derzeit schon 16 Stunden, dann 32 Stunden (?) ist schon recht viel - selbst wenn ich alle Schritte weiter automatisieren werde.

Ja das ist schon krass hmm ...sind das so viel Daten sad

ToniE wrote:

Generell zum dem Thema: Ich hatte eher an Anzahl und 'Name' der Haltestellen gedacht: mit/ohne Ortsname, normalisiert (d.h. str. -> straße), ...

Ja kann man auch probieren.. aber alleine beim MVV gibts es schon viele kreative Abkürzungen neutral .. lat/lon sind mir die Namen erst einmal egal und sogar ungefähr die Position kontrolliert  wink

ToniE wrote:

Im einfachsten Fall per Linearer Regression z.B. f(x) = 2 x + 3

oder sehr komplex z.B.: f(x) = 3 x**4 - 5 x**3 + 2 x**2 + 3 x + 3

und vergleichen kann, ob bei GTFS-Points und OSM-Points die selbe Funktion herauskommt.

... und nun gehen die Pferde mit mir durch ... und werfen mich ab ...

ja es gibt mehr als einen Weg nach Rom smile Meine Zielsetzung ein möglichst/relativ kleines Ergebnis was ich einfach vergleichen kann. Bis jetzt funktioniert es ganz gut cool Hab jetzt noch kleine Verbesserungen an den zwei Seiten gemacht.. um mir noch ein paar Klicks und Tastendrucke zu sparen smile

Offline

#96 2020-04-18 15:34:20

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

Re: PTNA - News: GTFS-Analyse

miche101 wrote:
ToniE wrote:

Ist fertig, ohne Limit auf 5, d.h. es werden alle angegeben.

Hab ich schon gesehen... hab es gleich genutzt um die Uhrzeiten bei den zwei Relationen zu aktualisieren smile Die Sekunden Angabe bräuchte ich nicht wink

ToniE wrote:

Aber beim VBB dauert diese Phase derzeit schon 16 Stunden, dann 32 Stunden (?) ist schon recht viel - selbst wenn ich alle Schritte weiter automatisieren werde.

Ja das ist schon krass hmm ...sind das so viel Daten sad

ToniE wrote:

Generell zum dem Thema: Ich hatte eher an Anzahl und 'Name' der Haltestellen gedacht: mit/ohne Ortsname, normalisiert (d.h. str. -> straße), ...

Ja kann man auch probieren.. aber alleine beim MVV gibts es schon viele kreative Abkürzungen neutral .. lat/lon sind mir die Namen erst einmal egal und sogar ungefähr die Position kontrolliert  wink

ToniE wrote:

Im einfachsten Fall per Linearer Regression z.B. f(x) = 2 x + 3

oder sehr komplex z.B.: f(x) = 3 x**4 - 5 x**3 + 2 x**2 + 3 x + 3

und vergleichen kann, ob bei GTFS-Points und OSM-Points die selbe Funktion herauskommt.

... und nun gehen die Pferde mit mir durch ... und werfen mich ab ...

ja es gibt mehr als einen Weg nach Rom smile Meine Zielsetzung ein möglichst/relativ kleines Ergebnis was ich einfach vergleichen kann. Bis jetzt funktioniert es ganz gut cool Hab jetzt noch kleine Verbesserungen an den zwei Seiten gemacht.. um mir noch ein paar Klicks und Tastendrucke zu sparen smile

Zu 1.) die Sekunden nehme ich noch raus. die Zeiten sind aber unabhängig davon ob nur Mo-Fr oder nur Sa+So oder jeden Tag ... also ein wenig Vorsicht.

zu 2.) ja das sind 'ne Menge Daten, die bei der Aggragation wegfallen ... nachdem ich erkannt habe, dass sie redundant sind: ein Bus, der alle 10 Minuten fährt von 04:48 bis 26:08 (02:08 des Folgetages) hat für jede Fahrt eine eigene Trip-ID und für jede Trip-ID gibt es eine Folge von Haltestelleneinträge (immer die gleiche), die angefahren werden und all diese Trip-IDs unterscheiden sich eigentlich nur bzgl. der Abfahrzeiten - für OSM eigentlich irrelevant. Da kann man eine Menge Holz vernichten.

zu 3.) Ja, das Kreativität bei den Namen ist grenzenlos. "Fürstenfeldb." und Fürstenfeldbr." und "Höhenkirchen-S.", "Höehenkirchen-Sie.", "Höhenkirchen-Sieg.". Bei einigen Dingen habe ich den Verdacht, dass hier auf Teufel-komm-raus versucht wird auf 16 Zeichen (oder so) zu reduzieren. lat/lon ist wohl die bessere Methode.

zu 4.) Da hast du Recht. Bei allem sollte im Hinterkopf bleiben, dass es einfach anzuwenden ist und Ausreißer möglichst erkannt werden und warum das ein Ausreißer ist, verständlich und nachvollziehbar bleibt.


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

Offline

#97 2020-04-18 17:20:36

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

Re: PTNA - News: GTFS-Analyse

hab was lustiges gefunden:

https://ptna.openstreetmap.de/gtfs/DE/s … s20-1.29.R
https://ptna.openstreetmap.de/gtfs/DE/s … s20-1.30.R

Diese zwei Unterscheiden sich nur in Schlacht bei der Position lat/lon lol

Offline

#98 2020-04-18 17:48:29

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

Re: PTNA - News: GTFS-Analyse

Jetzt Bus 413 smile

Weiter verbessert smile Meinen Relation zu GPX hab ich noch um ein paar rolen erweitern müssen hmm
https://greymiche.lima-city.de/413_bus.ods

Gruß Miche

Offline

#99 2020-04-18 17:54:48

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

Re: PTNA - News: GTFS-Analyse

miche101 wrote:

hab was lustiges gefunden:

https://ptna.openstreetmap.de/gtfs/DE/s … s20-1.29.R
https://ptna.openstreetmap.de/gtfs/DE/s … s20-1.30.R

Diese zwei Unterscheiden sich nur in Schlacht bei der Position lat/lon lol

Wobei der obere rein fahr-technisch nicht passt, falsch ist?


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

Offline

#100 2020-04-18 18:21:09

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

Re: PTNA - News: GTFS-Analyse

Ja des glaub ich auch... Wäre ungeschickt...

Offline

Board footer

Powered by FluxBB