Ich hab mich mal am Bus 446 probiert mit der Technik von Post #46. Hab für alle eine ID generiert… und geschaut ob sich aus GTFS und Relation paare sich bilden :). Über die Hälfte hatte auf Anhieb ein paar… dann hab ich mir die restlichen Relationen angeschaut und mit Plan verglichen… einige Fehler gefunden und nicht mehr vorhandene Fahrten. Für die geänderten Relationen eine neue ID erstellt… dann sind nur noch zwei Relationen übrig geblieben die ich neu erstellt hab
Hätte nicht gemeint das es so gut geht mit meiner waghalsigen gerechneten ID ( Es ist nur ein wenig aufwendig alle IDs zu erstellen… für alle GTFS trips und alle OSM Relationen )
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.
@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.
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 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 )
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…
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
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.
ich hab mich mal dem Bus 440 probiert… mit id zu vergleichen… läuft gut ID erstellen hab ich ein wenig vereinfacht… aber ich mach immernoch fehler beim kopieren
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.
… 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 x4 - 5 x3 + 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), …