ÖPNV Bus stop_position

krza · 2017-02-20 14:43:49

Da hilft es nur, nochmal das damalige Proposal zu konsultieren und zu prüfen, was gemeint ist. Aber angeblich werden die Proposals ja auch hin und wieder nach dem Approval noch geändert ...

Weide · 2017-02-20 15:42:50

krza wrote:

Da hilft es nur, nochmal das damalige Proposal zu konsultieren und zu prüfen, was gemeint ist.

Das Original findet man unter
http://wiki.openstreetmap.org/w/index.p … did=625726

krza wrote:

Aber angeblich werden die Proposals ja auch hin und wieder nach dem Approval noch geändert ...

Zu den Linienarten hat nach der Abstimmung jemand light_rail hinzugefügt und dadurch indirekt die Bedeutung von train eingeschränkt. Jetzt steht da, wir hätten das damals beschlossen und Korrekturversuche verschiedener Leute wurden revertet.

Last edited by Weide (2017-02-20 15:43:20)

krza · 2017-02-20 15:53:44

Na okay, dann hält sich das ja in Grenzen. Lässt sich also mit arbeiten. Danke für den Link nochmal.

axelr · 2017-02-21 16:16:21

geri-oc wrote:

Thoschi wrote:
Dieses Durcheinander lässt mich eigentlich nur wieder dafür plädieren, auf bus_stop ganz zu verzichten und sich nur noch auf ptv2 zu konzentrieren oder aber sich wirklich mal dran zu setzen und eine pt-Version zu konzipieren, die alles andere ersetzt und zukunftsfähig ist.
Bin auch der Meinung, wenn etwas bei ÖPNV passieren soll (Aktualität) dann sollte ein "System" anwendungsbereit dokumentiert werden. Somit würden auch schnell alle ptv1 aktualisiert werden. Gibt es überhaupt Nutzer von ptv1?

Es gibt noch wenige sinnvolle Anwendungen für ptv1 - Routen:
- Bürgerbuslinien, die zwar feste Haltestellen, aber keine festen Fahrwege haben, da Haltestellen als Rufbus angefahren werden.
- Bahnlinien bei denen die angefahrenen Bahnsteige nicht bekannt sind.

Dokumentationen existieren, werden aber nicht gelesen. Auf der VRR-Seite ist ein ptv2 Taggingschema datailliert beschrieben.
Meinst du mit Dokumentation solche Darstellungen http://www.roeltgen.com/e150900/ ? Und wo sollten sie stehen ?

Gruß Axel

huby1691 · 2017-02-22 08:43:41

Hallo Axel,

axelr wrote:

Dokumentationen existieren, werden aber nicht gelesen

mein Problem ist, es gibt zu viele, sich zu Teil widersprechende Dokumentationen.

Ich finde es gut, daß du dir die Mühe gemacht hast, verschiedene tagging-Schemata zu vergleichen, mir sind die Erklärungen dazu aber zu knapp, um daraus für mich Schlüsse zu ziehen, welches man anwenden sollte.
Insbesondere die Bildchen auf deiner Wiki-Seite User:Axelr/Bushalte fand ich interessant, konnte sie allerdings nicht entschlüsseln.
Auch deine mir bisher unbekannte Seite http://www.roeltgen.com/e150900/ ist als Grundlage für einen Vortrag sicherlich sehr gut, als schriftliche Dokumentation unzureichend, angefangen mit erst bei Zoom-Faktor 250 lesbaren Schriften in den Zeichnungen bis zur Benennung der Schemata (island: weil auf den britischen Inseln verwendet? tunnel:?).

krza wrote:

Wie wäre es hiermit: Public_transport_schema_development

Die Idee finde ich gut, würde lieber erst einmal auf deutsch arbeiten, um Schwierigkeiten und Mißverständnisse sprachlicher Art auszuschließen.

Viele Grüße
Peter

miche101 · 2017-02-22 09:23:17

Die Erklärung finde ich ganz gut.. um die Unterschiede darzustellen zwischen 1 und 2:
https://wiki.openstreetmap.org/wiki/User:Weide

Welche Punkte mich stören sind zum einen... für jede Variante eine Relation, und diese stop_position... Es mag in komplexeren Haltestellen notwendig sein... aber ein einfachen Verhältnissen braucht man diese glaub ich nicht... vor allem da diese eher geraten ist als wirklich aufgenommen...

Zum Beispiel diese Linie des MVV Nr. 614 müsste man 5 Varianten für die Hinfahrt anlegen und 5 Varianten für die Rückfahrt auch 5 anlegen und eine Master-Relation... das macht 11 Relationen das finde ich ein wenig übertrieben.. da dieser Bus nicht oft fährt.. wahrscheinlich hauptsächlich nur um Schuler aus den Dörfern aufzulesen.. wo gerade vorhanden sind.
http://efa.mvv-muenchen.de/ttb/mvv_19614___H_s17_1.pdf

Weide · 2017-02-22 10:00:48

miche101 wrote:

...und diese stop_position... Es mag in komplexeren Haltestellen notwendig sein... aber ein einfachen Verhältnissen braucht man diese glaub ich nicht... vor allem da diese eher geraten ist als wirklich aufgenommen...

Ja. PTv2 verlangt auch nicht, dass beides gemappt wird. Es verlangt nur, dass beide in die Routen kommen sofern beide vorhanden sind. Das hat den Sinn, dass man zu jedem Haltestellenobjekt einfach die Relationen nachschlagen kann und so die Liste der da haltenden Linienvarianten bekommt. Die meisten Pärchen aus stop und platform existieren nur deshalb, weil jemand irrtümlich angenommen hat, dass man das jetzt eben so machen muss. Ich lösche sowas normalerweise nicht, weil es ja zulässig ist ... aber 90% der Pärchen sind einfach Quatsch und man kann sie nur deshalb nicht vereinfachen, weil sie ja keine Fehler im engeren Sinne sind.

axelr · 2017-02-22 10:07:11

huby1691 wrote:

....Auch deine mir bisher unbekannte Seite http://www.roeltgen.com/e150900/ ist als Grundlage für einen Vortrag sicherlich sehr gut, als schriftliche Dokumentation unzureichend, angefangen mit erst bei Zoom-Faktor 250 lesbaren Schriften in den Zeichnungen bis zur Benennung der Schemata (island: weil auf den britischen Inseln verwendet? tunnel:?)....

Blätter eine Seite zurück, da stehen die Erklärungen. Zweimal 'Strg'+'+' fürs Studium des Kleingedruckten, die Registriernummer brauchst du nicht.

Farben in Bildern:
magenta Routen-Relation (Elemente in der route-relation)
grau Elemente nicht in der route-relation
blau highway-tag
dunkelblau railway-tag

Benennung:
dualnode für Zwei-Knoten-Punkt-Lösung
island für Insellösung, weil für London-Busses dokumentiert und weil nicht kompatibel,
tunnel für Tunnelblick.

Gruß Axel

Maarten Deen · 2017-02-22 11:37:49

miche101 wrote:

Zum Beispiel diese Linie des MVV Nr. 614 müsste man 5 Varianten für die Hinfahrt anlegen und 5 Varianten für die Rückfahrt auch 5 anlegen und eine Master-Relation... das macht 11 Relationen das finde ich ein wenig übertrieben.. da dieser Bus nicht oft fährt.. wahrscheinlich hauptsächlich nur um Schuler aus den Dörfern aufzulesen.. wo gerade vorhanden sind.
http://efa.mvv-muenchen.de/ttb/mvv_19614___H_s17_1.pdf

Wie soll denn sonst die unterschiedliche weglaufe deutlich gemacht werden? Ich hab es früher mal versucht mit eine "Alternative" role, aber das geht auch nicht mehr wenn es mehrere alternativen gibt.

Verstehe mich richtig: machmal stinkt's mir auch für eine einzige Bus eine neue Relation anlegen zu mussen. Und in Deutschland gibt es solche fälle viel öfter als in die Niederlanden.

huby1691 · 2017-02-22 14:22:28

@ axelx: ich habe schon zurückgeblättert, aber die Farbenerklärung fehlte mir zum Verständnis. Ebenso kenne ich die Tastenkombination für Zoom in/out im Browser, aber damit eine Dokumentation beachtet wird, sollte es der Leser m.E. möglichst bequem haben. Deswegen würde ich auch die Beispiele lieber als Bild (mit zusätzlichen Link) haben, außerdem könnte sich im Laufe der Zeit die Karte ändern und dann wäre das Beispiel nicht mehr nachvollziehbar.

@ miche101 / Marten Deen: Bei solchen Linien stehen für mich Aufwand und Nutzen des Anlegens von Relationen in keinem vernünftigen Verhältnis, insbesondere da mit Änderungen bei jedem Fahrplanwechsel zu rechnen ist.
Ich wäre hier zufrieden, wenn alle Haltestellen getaggt wären und man einen Link zur Webseite des Verkehrsunternehmens hätte.

Daraus ergibt sich aber auch die Frage, ob es nicht gut wäre, alle an einer Haltestelle haltenden Linien (wie am Haltestellenmast angeschrieben) in einem entsprechenden Tag aufzuzählen.

Eine unnötig hohe Komplexität ist meiner Ansicht nach dadurch entstanden, daß man versucht hat, Eisenbahn- und Bus-/Straßenbahnlinien in ein übereinstimmendes Schema zu bringen.

miche101 · 2017-02-22 14:36:46

huby1691 wrote:

Eine unnötig hohe Komplexität ist meiner Ansicht nach dadurch entstanden, daß man versucht hat, Eisenbahn- und Bus-/Straßenbahnlinien in ein übereinstimmendes Schema zu bringen.

Seh ich auch so... dazu sind diese Fahrzeuge zu flexibel... um da immer aktuell zu bleiben.

Vielleicht kann man die Fahrweg ja mal automatisch nach routingregeln berechnen lassen Das man nur noch die Abfolge der Haltestellen in einer Relation vorhalten muss..

axelr · 2017-02-22 15:27:54

miche101 wrote:

huby1691 wrote:
Eine unnötig hohe Komplexität ist meiner Ansicht nach dadurch entstanden, daß man versucht hat, Eisenbahn- und Bus-/Straßenbahnlinien in ein übereinstimmendes Schema zu bringen.
Seh ich auch so... dazu sind diese Fahrzeuge zu flexibel... um da immer aktuell zu bleiben.
Vielleicht kann man die Fahrweg ja mal automatisch nach routingregeln berechnen lassen Das man nur noch die Abfolge der Haltestellen in einer Relation vorhalten muss..

public_transport (Öffentlicher Verkehr) ist eben nicht mit railway in ein Schema gebracht worden. Die Bahnsteige und Fahrwege sind nur meist die gleichen.

Mit PTv1 und PTv2 kann man ganz gut umgehen. Ich sehe zwar Vereinfachungsmöglichkeiten, aber keine Notwendigkeit etwas Neues aufzutellen.

Zur eigentlichen Forumsfrage, der Notwendigkeit der stop_position:
Der Ein- Ausstiegpunkt für eine Fußgängernavigation wird durch ein Lot von der stop_position auf die nächstgelegen platform-Linie gebildet. Der Fußpunkt oder das Linienende ist dieser Ein- Ausstiegspunkt und wäre für mich auch die Position für das Haltestellensymbol.

FluxBB bbcode test
Leider wird auf der Mapnik Karte kein Symbol für PTv2 - Haltestellen gerendert. Die Hintergründe sind viel diskutiert, die fehlende Umsetzung ist nicht begreifbar.

Gruß Axel

slhh · 2017-02-23 00:32:03

miche101 wrote:

Vielleicht kann man die Fahrweg ja mal automatisch nach routingregeln berechnen lassen Das man nur noch die Abfolge der Haltestellen in einer Relation vorhalten muss..

PTv3 könnte etwas in diese Richtung gehen. Wir könnten für den Fahrweg atomare Segmente anlegen, die wir aber in der Regel nicht in die Linienrelation aufnehmen. Diese atomaren Segmente würden in der Regel von den Stop-Positionen einer Haltestelle zu denen der nächsten Haltestelle führen. Die Linienrelation würde dann in der Regel nur Haltestellen (vermutlich in Form von Stop-Positionen) auflisten. Die Auswertung hat dann die zu den genutzen Stop-Positionen jeweils aufeinanderfolgender Haltestellen passende atomare Segment zu verwenden, die über die Miglidschaft der Stop Position als from oder to node des atomaren Segments einfach aufzufinden sind. Der Editor könnte ggf. die zu einer Linienrelation fehlenden atomaren Fahrwegsegmente nach Benutzeraufforderung durch Autorouting automatisch erstellen. Für die meisten Segmente wird das korrekte Ergebnisse liefern und in den anderen Fällen kann dann der Benutzer nachkorrigieren.

Ein Ausnahmefall ist, wenn es zwischen einem Paar von Stop-Positionen mehrere verschiedene tatsächlich genutzte Fahrwege gibt, was sehr selten sein dürfte. In diesem Fall wäre zusätzlich ein Via-Node oder das betreffende Fahrwegsegment explizit in die Linienrelation aufzunehmen.

Gibt es Linien die eine Haltestelle ohne Halt durchfahren, sollte diese Haltestelle in der Regel in die Linienrelation mit aufgenommen werden und nur durch eine Rolle als durchfahren gekennzeichnet werden. Dies vermeidet zusätzlich benötigte Fahrwegsegmente und bringt somit eine wichtige Entlastung der Highway-Elemente von übermäßig vielen Relationen.

Die atomaren Segmente müssen nicht unbedingt linear sein, sondern können am Anfang und Ende zu mehreren From- bzw. To-Nodes verzweigt sein. Anhand der in der Linienrelation verwendeten Stop-Positionen, können die aus dem Fahrweg Segment tatsächlich benötigten Ways herausgefiltert werden.

Für Karten-Renderer die ohnehin den lokal vollständigen Datensatz vorliegen haben, sollten kein Problem mit den nötigen Auswertungen haben. Um Linien auf Basis einer Overpass Abfrage darstellen zu können, braucht man entweder eine Browsers-seitige Nachbearbeitung oder eine Erweiterung der Overpass-API um PT-spezifische Ausgangsfilter.

slhh · 2017-02-23 02:39:36

Ein großes Probem von PTv2 ist die bei konsequenter Umsetzung durch Varianten erzeugte Datenflut, die für eine manuelle Pflege ungeeignet ist. Bezüglich Varianten ist PTv2 strukturell zu einfach definiert, was durch die enorme Datenmenge ausgeglichen werden muss und damit zumindest für Menschen die Komplexität deutlich erhöht.

PTv3 sollte daher in der Lage sein, zumindest kleine Variationen innerhalb der Relationen abzubilden, um nicht für jede Untervariante eine separate Routenrelation zu benötigen.

Ein Beispiel wie sowas bei einem Segment aussehen kann:

pio A-Dorf
pio:-B_Gl2 B-Dorf an Gleis 1
+pio:-B_Gl2,-KZ B-Dorf Bahnsteigverlängerung an Gleis 1
alt-pio:+B_Gl2 B-Dorf an Gleis 2
pio C-Dorf

B_Gl2 und KZ sind dabei beliebige Bezeichner für eine Variation, die aktiv ist, wenn sie in der Rolle der Migligschaft des Segments in der Tour aufgeführt sind. Ein minus vor diesem Bezeichner in der Memberrolle deaktiviert den Member wenn die Variation aktiv ist. Ein plus vor diesem Bezeichner in der Memberrolle deaktiviert den Member wenn die Variation inaktiv ist.
Wird ein pio deaktiviert, so wird aus einem unmittelbar nachfolgenden +pio oder alt-pio ein pio.
Wird ein alt-pio deaktiviert, so wird aus einem unmittelbar nachfolgenden +pio ein alt-pio.

Für einen Kurzzug der in B-Dorf auf Gleis 1 fährt wäre diese Rolle dann:
segment:KZ

Damit wird aus obiger Membersequenz:
pio A-Dorf
pio B-Dorf an Gleis 1
pio C-Dorf

Für einen Zug der in B-Dorf auf Gleis 2 fährt wäre diese Rolle dann:
segment:B_Gl2

pio A-Dorf
pio B-Dorf an Gleis 2
pio C-Dorf

Natürlich können auch mehrere Variationen gleichzeitig wirken:
segment:KZ,B_Gl2
Dies hat für den Beispielfall aber das gleiche Ergebnis wie zuletzt.

Weide · 2017-02-23 09:01:54

miche101 wrote:

Vielleicht kann man die Fahrweg ja mal automatisch nach routingregeln berechnen lassen wink Das man nur noch die Abfolge der Haltestellen in einer Relation vorhalten muss..

Sowas ist nur brauchbar, wenn alles andere fehlerfrei und vollständig ist.

Da muss nur jemand bei einem Stück Fahrweg einen kleinen Fehler machen und schon hat man eine Karte mit richtig gut und plausibel aussehendem Unsinn statt einer anständigen Fehlermeldung.

Auch für teilweise erfasste Linien ist so etwas sehr ungünstig.

Und dann gibt es noch Linien, die sich damit überhaupt nicht sinnvoll erfassen lassen wie z.B. die Fährverbindung zwischen Norddeich Mole und Juist. Ob man da 40 Minuten länger fährt oder nicht macht den Unterschied zwischen "alles klar" und "Zug verpasst und ich brauche eine neue Fahrkarte" aus.

miche101 · 2017-02-23 09:03:39

Ich seh immernoch die Zukunft... dass man mit einem Routingprogramm eine Strecke generieren kann die vielleicht noch mit Via-Punkten korrigieren und dann dass Ergebnis als z.B. Relation statisch abspeichert. Würde auch viele potenzielle Fehler vermeiden..

geri-oc · 2017-02-23 09:18:09

Nach dem lesen dieser Beiträge:

Das ist sicher für Spezialisten interessant und richtig dies auch zu diskutieren.

Für einen einfachen unbedarften Dateneinträger sollte eine Haltestelle "einfach" einzutragen sein, meinetwegen mit ergänzenden Schlüsseln wie Bahnsteignummer, Liniennummer, Name, Referenz, ... (neuerdings bei uns mit QR-Code zu Fahrplan/-änderungen). Und bis dahin sollte das "Fußgängerrouting" führen.

Die daraus abzuleitende Relation (Fahrpläne?) sind schon spezieller. Einige werden sicher diese Aufgabe übernehmen. Dort darf aber eine Änderung an einer Haltestelle nicht zum "Chaos" führen.

Ob ein Zug auf Gleis 1 oder 1a oder 2 hält ist oft auch situationsbedingt - genauso die Bushalte. Diese müssten einfach die "Haltestellen" abfragen.

huby1691 · 2017-02-23 09:24:48

Endlich eine Verwendung für die Stop-Position? Würde es nicht genauso funktionieren, wenn die atomaren Segmente den Weg von einer Platform zur nächsten beschreiben würden?
Egal ob Stop oder Platform, an jeder Haltestelle müßten die ways aufgetrennt werden.

Grundsätzliche Frage: Wo sollte die Schnittstelle zwischen OSM-Daten und Fahrplandaten sein?

Ich könnte mir vorstellen, sofern es denn einmal freie Fahrplandaten mit eindeutig zuordnenden Haltepunkten (IFOPT?) gibt, es ausreichen sollte, die Haltestellen und die Fahrwege zwischen den Haltestellen (atomare Segmente) zu taggen.

Ich sehe keinen Sinn darin, dutzende Fahrweg-Relationen in den OSM-Daten zu haben, ohne zu wissen, wann diese bedient werden. Im Eisenbahnbereich kommt es auch immer wieder aus betrieblichen Gründen zu Gleis- und damit auch zu Bahnsteig-wechseln.

Weide · 2017-02-23 09:28:57

axelr wrote:

Der Ein- Ausstiegpunkt für eine Fußgängernavigation wird durch ein Lot von der stop_position auf die nächstgelegen platform-Linie gebildet. Der Fußpunkt oder das Linienende ist dieser Ein- Ausstiegspunkt und wäre für mich auch die Position für das Haltestellensymbol.

Du gehst da von Vorstellungen aus, die nicht PTv2 sind.
In PTv2 gehört zu einem stop nicht unbedingt eine platform. Es können aber auch mehrere dazu gehören.
In PTv2 gehört zu einer platform nicht unbedingt ein stop. Es können aber auch mehrere dazu gehören.
Ob eine platform "nächstgelegen" ist, ist völlig egal.

In dem Bild wird dargestellt, dass die Busse nur nach Norden fahren. Das kann man aus der Haltestellenbeschreibung nicht schließen. Man kann es nicht einmal nach Analyse aller gemappten Routen schließen.

Weide · 2017-02-23 09:38:06

geri-oc wrote:

Für einen einfachen unbedarften Dateneinträger sollte eine Haltestelle "einfach" einzutragen sein, meinetwegen mit ergänzenden Schlüsseln wie Bahnsteignummer, Liniennummer, Name, Referenz, ... (neuerdings bei uns mit QR-Code zu Fahrplan/-änderungen). Und bis dahin sollte das "Fußgängerrouting" führen.

Fast genau das habe im P3-Vorschlag versucht. Die real vorhandenen Objekte sollen einfach als solche gemappt werden -- ohne jede Rücksicht auf ÖPV-Routen. Die ÖPV-Routen dagegen stützen sich nur auf die Punkte des Fußgängerrouting (PIO). Oft fallen diese beiden Sachen zusammen, aber das muss nicht so sein.

seichter · 2017-02-23 10:41:53

Ich habe auch den Eindruck, dass seit ungefähr Oxomoa der Versuch unternommen wurde, den gesamten ÖPNV vom Ruftaxi bis zum ICE mit einem allmächtigen System zu beschreiben. Das wurde dann notwendigerweise so umfangreich, dass der Normalmapper nicht mehr überblickt, wie er relativ primitive Sachen eintragen kann und es lieber ganz bleiben lässt.

Ich plädiere dafür, das Ganze in mindestens zwei Gruppen aufzuteilen:
a) Alles was "on the ground" sichtbar ist und einfach zuzuordnen ist, wie Haltestellen (an Hand der Schilder), Bahnsteige, Gleise.
b) Alle Besonderheiten und komplizierteren Objekte wie Busbahnhöfe, U-Bahn-Ausgänge, kombinierte Strecken in einer Abteilung "für Experten", für die es natürlich einer viel ausführlicheren Beschreibung und Festlegung bedarf.

a) ist natürlich eine Teilmenge von b).

Mit a) und primitiven Relationen, die nur die Reihenfolge der Haltestellen enthalten, kann man z.B. schon einen Netzplan und eine kombinierte Fußgänger-ÖPNV-Navigation erzeugen. Es wäre eine Überlegung wert, ob es sich lohnt, die Linie(n) als (später redundanten) Tag in das Haltestellen-Objekt einzutragen. Das Erzeugen der Linien-Relation wird dadurch jedenfalls erleichtert.

Anders als z.B. bei Wander- oder Fahrradrouten hat beim ÖPNV der exakte Routenverlauf eine geringere Priorität für den Nutzer. Man braucht ihn eigentlich nur für die Darstellung auf der Karte.

geri-oc · 2017-02-23 10:50:18

seichter wrote:

Anders als z.B. bei Wander- oder Fahrradrouten hat beim ÖPNV der exakte Routenverlauf eine geringere Priorität für den Nutzer. Man braucht ihn eigentlich nur für die Darstellung auf der Karte.

Der Vorschlag Haltestellen in (einfache) Routenrelation zubringen, finde ich gut. Dann kann man für die Linie 333 eine Route mit Haltestellen A, B, C, ... anzeigen.
Wichtig wäre schon, wo die Route 333 verläuft - damit kann ich Haltestellen "ohne umsteigen" finden bzw. wo ich auf eine andere Route wechseln muss, wenn ich nach Z möchte.

Maarten Deen · 2017-02-23 10:54:50

slhh wrote:

PTv3 könnte etwas in diese Richtung gehen. Wir könnten für den Fahrweg atomare Segmente anlegen, die wir aber in der Regel nicht in die Linienrelation aufnehmen. Diese atomaren Segmente würden in der Regel von den Stop-Positionen einer Haltestelle zu denen der nächsten Haltestelle führen. Die Linienrelation würde dann in der Regel nur Haltestellen (vermutlich in Form von Stop-Positionen) auflisten. Die Auswertung hat dann die zu den genutzen Stop-Positionen jeweils aufeinanderfolgender Haltestellen passende atomare Segment zu verwenden, die über die Miglidschaft der Stop Position als from oder to node des atomaren Segments einfach aufzufinden sind.

Einen richtigen Top-Down Ansatz.

Es wäre für den Auswertung einfacher die atomaren Segmenten in der Relation auf zu nehmen. Damit weiss man a) das der Segment noch benuzt wird, b) haben Overpass und andere Auswerter weiniger Probleme der Fahrweg zu identifizieren/an zu zeigen und c) kann man nicht-haltende Fahrwege machen indem man nicht der Halt aber doch die Segmenten in der Relation mit aufnimmt.

Ein Problem löst es nicht: es ist noch immer nötig für jede Variante eine Relation zu erstellen. Ich weiss auch nicht ob es weniger aufwand ist die Relationen so an zu legen.

miche101 · 2017-02-23 11:02:58

Was sind "atomaren Segmente"

atomar --> kleines Teilchen.. bzw. Atom das kleinst überhaupt... bei OSM wäre das eine Node ohne Eigenschaften...
Segment --> ein Teilstück... bei OSM... ein Teilstück eine Weges?

Ein Weg mit 2 Nodes ohne Eigenschaften?????????????? Das hört sich toll an aber Sinn gibt das nicht..

geri-oc · 2017-02-23 11:05:52

Maarten Deen wrote:

Ein Problem löst es nicht: es ist noch immer nötig für jede Variante eine Relation zu erstellen. Ich weiss auch nicht ob es weniger aufwand ist die Relationen so an zu legen.

Varianten kann man aus dem "verlinkte Fahrplan" lesen.
M.E. würde schon ein Routenverlauf aus der Abfolge der Haltestellen ausreichen. Wenn z.B. der "Eilbus" zwei, drei Haltestellen nicht anfährt, ist das aus dem "Fahrplan" ersichtlich.

Announcement

#51 2017-02-20 14:43:49

Re: ÖPNV Bus stop_position

#52 2017-02-20 15:42:50

Re: ÖPNV Bus stop_position

#53 2017-02-20 15:53:44

Re: ÖPNV Bus stop_position

#54 2017-02-21 16:16:21

Re: ÖPNV Bus stop_position

#55 2017-02-22 08:43:41

Re: ÖPNV Bus stop_position

#56 2017-02-22 09:23:17

Re: ÖPNV Bus stop_position

#57 2017-02-22 10:00:48

Re: ÖPNV Bus stop_position

#58 2017-02-22 10:07:11

Re: ÖPNV Bus stop_position

#59 2017-02-22 11:37:49

Re: ÖPNV Bus stop_position

#60 2017-02-22 14:22:28

Re: ÖPNV Bus stop_position

#61 2017-02-22 14:36:46

Re: ÖPNV Bus stop_position

#62 2017-02-22 15:27:54

Re: ÖPNV Bus stop_position

#63 2017-02-23 00:32:03

Re: ÖPNV Bus stop_position

#64 2017-02-23 02:39:36

Re: ÖPNV Bus stop_position

#65 2017-02-23 09:01:54

Re: ÖPNV Bus stop_position

#66 2017-02-23 09:03:39

Re: ÖPNV Bus stop_position

#67 2017-02-23 09:18:09

Re: ÖPNV Bus stop_position

#68 2017-02-23 09:24:48

Re: ÖPNV Bus stop_position

#69 2017-02-23 09:28:57

Re: ÖPNV Bus stop_position

#70 2017-02-23 09:38:06

Re: ÖPNV Bus stop_position

#71 2017-02-23 10:41:53

Re: ÖPNV Bus stop_position

#72 2017-02-23 10:50:18

Re: ÖPNV Bus stop_position

#73 2017-02-23 10:54:50

Re: ÖPNV Bus stop_position

#74 2017-02-23 11:02:58

Re: ÖPNV Bus stop_position

#75 2017-02-23 11:05:52

Re: ÖPNV Bus stop_position

Board footer