ÖPNV Vorentwurf (zurückgezogen)

viw · 2013-07-28 15:14:03

Weide wrote:

seawolff wrote:
Im streckenbasierten Modell muss man ohne Kenntnis des Fahrwegs eine 200m Lücke lassen oder eine der Alternativen raten.
Man muss eine Lücke lassen. Raten ist falsch.
Weide

Das würde den Router vor eine zweite Aufgabe stellen. Nämlich erkennen dass es mehr als einen Weg gibt. Und den gibt es eigentlich immer, aber ab wann wäre er möglicherweise relevant?
Ich finde es wirklich interessant, wenn man das zuverlässich schaffen könnte. Denn vom VBB liegen solche Fahrplandaten mit den Haltestellen ohne viaPunkte vor. Ich denke das man um eine Kontrolle beim einlesen nicht drumherum kommt.

Last edited by viw (2013-07-28 15:17:58)

seawolff · 2013-07-28 23:56:16

viw wrote:

seawolff wrote:
Im streckenbasierten Modell muss man ohne Kenntnis des Fahrwegs eine 200m Lücke lassen oder eine der Alternativen raten.
das ist soweit verständlich. Aber was ist jetzt der korrekte Weg bei der Auswertung? Wird dort jetzt bei der Darstellung geraten? wird dort die Lücke gelassen sobald mehr als eine Alternative gefunden wird? Wie soll man das am Ende unterscheiden wenn der Weg doch geraten wird? Der nächste glauibt doch dort ist alles i.O.

Es gibt in OSM nicht "die korrekte Auswertung".
Eine sinnvolle Variante wäre, in der ÖPNV-Karte den kürzesten, zulässigen Weg zu rendern.
In den Endnutzerkarten sind fehlende Informationen meist nicht erkennbar. Die üblich Mapnikkarte unterscheidet z.B. nicht zwischen Feldwegen mit "tracktype=grade3" und solchen ohne den key "tracktype".

In einer Spezialkarte für Mapper könnte man natürlich darstellen, ob es mehrere alternative, ähnlich gute Routingergebnisse gibt.

seawolff · 2013-07-29 00:23:20

Weide wrote:

seawolff wrote:
Auf der Bahnstrecke Kiel-Plön-... gibt es nur bei der Ausfahrt aus Kiel Hbf. zwei mögliche Fahrwege.
In der Realität oder in unserem Datenbestand?

In diesem konkreten Fall stimmen Realität und Datenbestand überein :-)

Wir können nicht davon ausgehen, dass beides übereinstimmt. Das via-Modell geht doch irgendwie von kompletten Daten aus.

Die ÖPNV-Routen können nicht besser als das Wege- bzw. Gleisnetz sein. Ob man die Routingarbeit dem Mapper aufbürdet oder vom Computer machen lässt, ändert daran nichts.

seawolff wrote:
Im streckenbasierten Modell muss man ohne Kenntnis des Fahrwegs eine 200m Lücke lassen oder eine der Alternativen raten.
Man muss eine Lücke lassen. Raten ist falsch.

In der Theorie ja, in der Praxis tut das niemand. Ich habe solche Lücken jedenfalls noch nie gesehen.

rayquaza · 2013-07-29 00:28:02

seawolff wrote:

viw wrote:
Aber was ist jetzt der korrekte Weg bei der Auswertung? Wird dort jetzt bei der Darstellung geraten? wird dort die Lücke gelassen sobald mehr als eine Alternative gefunden wird? Wie soll man das am Ende unterscheiden wenn der Weg doch geraten wird? Der nächste glauibt doch dort ist alles i.O.
Es gibt in OSM nicht "die korrekte Auswertung".
Eine sinnvolle Variante wäre, in der ÖPNV-Karte den kürzesten, zulässigen Weg zu rendern.

Genau das ist das Problem: Nehmen wir z.B. eine zweigleisige Bahnstrecke mit GWB, bei der das Ggl durch eine Kurve zwischen einem Haltepunkt und einem Bf kürzer ist, auf der ein Zug vom Regelgleis der Strecke im ersten Bf zu einem Gleis links des Ggl im zweiten Bahnhof fährt, also im auf der freien Strecke auf dem Regelgleis. Nun wird hinter dem Hp eine Üst errichtet.

Was wird an Veränderungen in OSM von einem "normalen" Mapper vorgenommen? Vermutlich würde einfach nur das Gleisstück eingefügt. Bei der bisherigen Erfassung der Relationen ist das kein Problem. Bei einer Erfassung mit Via-Punkten würde damit der Fahrweg über das Gegengleis kürzer und als befahren angenommen – Es müsste also zusätzlich zur Ergänzung der Weichen in jeder dort entlangführenden Relation mindestens ein Via-Punkt aufgenommen werden.

Andersrum kann man afaik durch korrekt ausgeführte Änderungen (d.h. z.B. Elternelemente sind bei Bearbeitung geladen) eine Relation nur beschädigen, wenn z.B. die zweigleisige Strecke zu einer eingleisigen wird. Dabei würde ich auch erwarten, dass das passiert – Ich halte es sogar für gut, da sich bei sowas häufiger auch noch mehr am Verlauf ändert.

seawolff wrote:

Die ÖPNV-Routen können nicht besser als das Wege- bzw. Gleisnetz sein. Ob man die Routingarbeit dem Mapper aufbürdet oder vom Computer machen lässt, ändert daran nichts.

Wenn die Routingarbeit ein Mapper macht kann er aber dabei fehlende Wege bemerken und ergänzen (selbst schon oft gemacht) – das kann eine Software nicht so gut…

seawolff wrote:

In der Theorie ja, in der Praxis tut das niemand. Ich habe solche Lücken jedenfalls noch nie gesehen.

Ich hier schon – und zwar nicht nur von mir

Weide · 2013-07-29 06:22:57

seawolff wrote:

In der Theorie ja, in der Praxis tut das niemand. Ich habe solche Lücken jedenfalls noch nie gesehen.

Ich sehe diese Lücken dauernd. In vielen Gegenden. Ich halte das für den Normalfall.

Weide

rayquaza · 2013-07-29 06:41:31

Weide wrote:

rayquaza wrote:
...besonders wenn es keinen wirklichen Mehrnutzen gibt...
Na ja, es ist immerhin eine Liste von 15 angegangenen Problemen und nur einige von ihnen sind auch im PTP lösbar.

Magst du mal ein paar der "nicht lösbaren" benennen? Ich habe deinen Vorschlag jetzt schon ein paar Mal überflogen und noch keines gefunden.

Weide · 2013-07-29 06:44:21

seawolff wrote:

Die ÖPNV-Routen können nicht besser als das Wege- bzw. Gleisnetz sein. Ob man die Routingarbeit dem Mapper aufbürdet oder vom Computer machen lässt, ändert daran nichts.

Die Darstellung finde ich eigenwillig. Der Mapper macht gar kein Routing. Er oder sie sitzt im Bus und zeichnet einen Track und seine Start- und Zielhaltestelle auf.

Vielleicht auch noch unterwegs ein paar Haltestellen, wenn so schnell erkennbar sind. Dann hat man schonmal diese Teilstrecke und einige ihrer Haltestellen (auf der einen Seite). Der nächste kann dann weitere Teile ergänzen. Jetzt kann man so langsam sehen, wo vermutlich noch Haltestellen fehlen und gezielt darauf achten. Das ist der ganz normale Ablauf der Erfassung im Laufe der Zeit und durch mehrere Mapper.

Ich kann mir nicht vorstellen, wie diese Arbeitsabläufe mit dem via-Konzept funktionieren. Bei Haltestellenimporten kann ich es mir vorstellen, aber nicht bei Erfassung durch draußen rumlaufende Mapper.

Weide

Last edited by Weide (2013-07-29 07:36:02)

Weide · 2013-07-29 07:35:33

rayquaza wrote:

Magst du mal ein paar der "nicht lösbaren" benennen? Ich habe deinen Vorschlag jetzt schon ein paar Mal überflogen und noch keines gefunden.

-Haltestellenlisten ermitteln:
Geht bei PTP nur anhand des Namens der Haltestelle. Auch wenn man das Problem löst, dass der oft nirgendwo mehr steht, funktioniert das nicht.

Die O3 (Masterrelation 934912) hält zweimal am Fritz-Gressard-Platz. Wer an der Haltestelle nach den beiden aussteigen will, braucht diese Angabe, sonst drückt er/sie zu früh auf den Knopf.

Die U78(Masterrelation 2003448) hat dagegen bei der Ankunft am Düsseldorfer Stadion Bahnsteige auf beiden Seiten. Gibt man beide an, dann sieht das aus wie zwei Haltestellen.

Die Straßenbahn-Bahnsteige am Wehrhahn (Way 56472677) liegen teilweise auf der Brücke. Gibt man beide an, dann sieht es nach zwei Halten aus.

-Support für die Mapper durch Fehlermeldungen und Karten:
Der Relationstyp bestimmt, welche Bedeutung die Rollen, die Einträge und ihre Reihenfolge haben. In Relationen vom Typ type=route galt vor dem PTP, dass z.B. die leere Rolle an einem Weg eine bidirektionale Nutzung des Weges angibt und eine unidirektionale Nutzung mit "forward" und "backward" angegeben. ("stop" hatte vorher auch eine andere Bedeutung.) Das abweichend zu definieren war ein Fehler und Programme wie http://www.öpnvkarte.de, der OSMI und der JOSM-Validator haben sich davon bis heute noch nicht erholt. Wir hatten vorher bessere Fehlermeldungen und bessere Karten (relativ zum Erfassungsgrad) und wir hätten mit dem PTP vermutlich noch bessere bekommen -- aber die Mischung im gleichen Typ verbaut die Möglichkeiten. Es könnte sehr viel besseren Support für die Mapper geben und wir brauchen ihn dringend, weil sonst nur ein paar Fachleute an den Linien arbeiten.

Weide

rayquaza · 2013-07-29 07:51:50

Weide wrote:

-Haltestellenlisten ermitteln:
Geht bei PTP nur anhand des Namens der Haltestelle. Auch wenn man das Problem löst, dass der oft nirgendwo mehr steht, funktioniert das nicht.
Die O3 (Masterrelation 934912) hält zweimal am Fritz-Gressard-Platz. Wer an der Haltestelle nach den beiden aussteigen will, braucht diese Angabe, sonst drückt er/sie zu früh auf den Knopf.
Die U78(Masterrelation 2003448) hat dagegen bei der Ankunft am Düsseldorfer Stadion Bahnsteige auf beiden Seiten. Gibt man beide an, dann sieht das aus wie zwei Haltestellen.

Ich weiss nicht genau wie es definiert ist – Interpretieren (und mappen) würde ich so: Jedes Element mit der Rolle "stop" bedeutet den Beginn eines neuen Haltes. Die danach folgenden Elemente gehören zu diesem, was durch eine weitere Rolle "stop" oder ein Rollenloses Element abgeschlossen wird.

Mehrere "stop" für einen Halt kommen mEn nicht vor (oder sind zwei Halte an der selben Haltestelle, siehe z.B. Lampertheim Bahnhof) und wenn man nur weiss "hier ist eine Haltestelle" sollte man imo (wie hier schon nebenan geschrieben) trotzdem nur highway=bus_stop erfassen, was dann die Rolle "stop" erhält.

Weide wrote:

Der Relationstyp bestimmt, welche Bedeutung die Rollen, die Einträge und ihre Reihenfolge haben. In Relationen vom Typ type=route galt vor dem PTP, dass z.B. die leere Rolle an einem Weg eine bidirektionale Nutzung des Weges angibt und eine unidirektionale Nutzung mit "forward" und "backward" angegeben. ("stop" hatte vorher auch eine andere Bedeutung.)

Lösbar durch ein Tag, das aussagt "ich bin veraltet, aktualisiert mich", hatten wir ja schon diskutiert.

Weide wrote:

Das abweichend zu definieren war ein Fehler und Programme wie http://www.öpnvkarte.de, der OSMI und der JOSM-Validator haben sich davon bis heute noch nicht erholt.

Der JOSM-Validator zeigt die Meldungen passend zum PTP an. Das finde ich auch gut so, denn die alten Relationen sind eh meist fehlerhaft und sollten repariert und bei der Gelegenheit gleich umgestellt werden.

Weide wrote:

Es könnte sehr viel besseren Support für die Mapper geben und wir brauchen ihn dringend, weil sonst nur ein paar Fachleute an den Linien arbeiten.

Wie schon geschrieben: Wenn du jemanden findest, der das machen will (z.B. jemand der die Relationen gezielt bearbeitet): Schreib ihn an und erkläre es – Das grösste Problem ist imo, dass einige davon einfach noch nichts mitbekommen haben…

Weide · 2013-07-29 08:21:49

rayquaza wrote:

Ich weiss nicht genau wie es definiert ist – Interpretieren (und mappen) würde ich so: Jedes Element mit der Rolle "stop" bedeutet den Beginn eines neuen Haltes. Die danach folgenden Elemente gehören zu diesem, was durch eine weitere Rolle "stop" oder ein Rollenloses Element abgeschlossen wird.

Das geht nicht. "stop" darf genauso entfallen wie "platform", wenn es unbekannt ist. Die leere Rolle ist für Fahrwege reserviert.

rayquaza wrote:

Der JOSM-Validator zeigt die Meldungen passend zum PTP an.

Das sehe ich nicht so. Sehr viele Fehler, die ich so sehe, sind automatisch feststellbar und kaum welche werden angemeckert. Dagegen gibt es Meldungen, wenn die Objekte mit Rollen stop oder platform kein public_transport=xxx haben und das ist falsch, da die PTP-Relationen problemlos mit alten Haltestellen kombinierbar sind und im Fall public_transport=platform bei Nodes kein Äquivalent existiert.
Siehe auch http://josm.openstreetmap.de/ticket/8460 und andere.

Weide · 2013-07-29 08:25:17

Hi,

ich hab mal ein zusätzliches Tag pt2_version=1 für die neuen Relationen (wieder) hinzugefügt. Man muss es nicht schreiben, da es der Default ist. Es geht nur darum, dass verarbeitende Programme es prüfen. Es verhindert, dass künftige Revisionen neue Relationstypen brauchen.

Weide

rayquaza · 2013-07-29 08:34:57

Weide wrote:

rayquaza wrote:
Ich weiss nicht genau wie es definiert ist – Interpretieren (und mappen) würde ich so: Jedes Element mit der Rolle "stop" bedeutet den Beginn eines neuen Haltes. Die danach folgenden Elemente gehören zu diesem, was durch eine weitere Rolle "stop" oder ein Rollenloses Element abgeschlossen wird.
Das geht nicht. "stop" darf genauso entfallen wie "platform", wenn es unbekannt ist. Die leere Rolle ist für Fahrwege reserviert.

Naja, ein bisschen umdefinieren muss man schon, aber das ist imo kompatibel – Wenn man "stop" und "platform" beide weglässt bleibt eh nichts mehr vom Halt übrig. Und überleg nochmal, warum eine leere Rolle die zu einem Halt gehörenden Elemente genauso wie eine Rolle "stop" terminiert

Weide wrote:

rayquaza wrote:
Der JOSM-Validator zeigt die Meldungen passend zum PTP an.
Das sehe ich nicht so. Sehr viele Fehler, die ich so sehe, sind automatisch feststellbar und kaum welche werden angemeckert. Dagegen gibt es Meldungen, wenn die Objekte mit Rollen stop oder platform kein public_transport=xxx haben und das ist falsch, da die PTP-Relationen problemlos mit alten Haltestellen kombinierbar sind und im Fall public_transport=platform bei Nodes kein Äquivalent existiert.
Siehe auch http://josm.openstreetmap.de/ticket/8460 und andere.

Oh, ich dachte eigentlich, dass ich da das Schema schon "grosszügig ausgelegt" hätte (dachte ich aber nicht wegen den JOSM-Warnungen, sondern weil hier ein anderer Benutzer zwanghaft einfach überall stop_positions hinzugefügt hat, auch wenn es nicht stimmte).

Tordanik · 2013-07-29 08:58:28

Weide wrote:

Ich kann mir nicht vorstellen, wie diese Arbeitsabläufe mit dem via-Konzept funktionieren. Bei Haltestellenimporten kann ich es mir vorstellen, aber nicht bei Erfassung durch draußen rumlaufende Mapper.

Du erfasst die Haltestellen und via-Punkte, die du schon kennst. Für die Lücken setzt du TODOs, Notes oder was auch immer du für angebracht hältst. Eben wie bei allen anderen nur grob oder unvollständig erfassten Sachen, wo eine Lücke nicht direkt aus den Daten erkennbar ist. Das Problem gibt es ja keineswegs nur bei Routen und neu ist es auch nicht...

Weide · 2013-07-29 11:59:47

Tordanik wrote:

Du erfasst die Haltestellen und via-Punkte, die du schon kennst.

Besagt das, dass man zwar die Routen brauchen kann, aber sie in Form von via-Punkten statt direkt erfassen soll?

Tordanik wrote:

Für die Lücken setzt du TODOs, Notes oder was auch immer du für angebracht hältst.

TODOs und Notes werden von den Renderern nicht gelesen. Die stellen dann falsche Routen dar.

Tordanik wrote:

Eben wie bei allen anderen nur grob oder unvollständig erfassten Sachen, wo eine Lücke nicht direkt aus den Daten erkennbar ist.

Da ist es doch schön, dass wir jetzt ein Verfahren haben, bei dem sowas nicht passiert.

Es gibt aber auch noch viele andere Sachen. Da trägt jemand eine Haltestelle an der falschen Stelle ein. Die sich daraus ergebende Route will ich auf keiner Karte sehen. Was ist, wenn jemand eine Einbahnstraße falsch einträgt? Wir hatten in Düsseldorf-Wersten eine Sperrung einer Autobahnabfahrt -- aber nicht für die Busse. Es ist doch verständlich, wenn ein Mapper das einträgt und nicht an diese Sonderregelung denkt. Dann werden aber plötzlich Wahnsinnsrouten für die Busse in den Karten auftauchen.

Weide

seawolff · 2013-07-30 00:36:31

Weide wrote:

seawolff wrote:
Die ÖPNV-Routen können nicht besser als das Wege- bzw. Gleisnetz sein. Ob man die Routingarbeit dem Mapper aufbürdet oder vom Computer machen lässt, ändert daran nichts.
Die Darstellung finde ich eigenwillig. Der Mapper macht gar kein Routing.

Der GPS-Track ist meist nicht gut genug, um das richtige Gleise zu identifizieren.

Er oder sie sitzt im Bus und zeichnet einen Track und seine Start- und Zielhaltestelle auf.
Vielleicht auch noch unterwegs ein paar Haltestellen, wenn so schnell erkennbar sind. Dann hat man schonmal diese Teilstrecke und einige ihrer Haltestellen (auf der einen Seite). Der nächste kann dann weitere Teile ergänzen. Jetzt kann man so langsam sehen, wo vermutlich noch Haltestellen fehlen und gezielt darauf achten. Das ist der ganz normale Ablauf der Erfassung im Laufe der Zeit und durch mehrere Mapper.
Ich kann mir nicht vorstellen, wie diese Arbeitsabläufe mit dem via-Konzept funktionieren.

Ganz einfach: der Mapper erstellt eine Relation aus den erkannten Haltestellen. Falls der Bus einen Umweg fährt und der Mapper dort die Haltestelle nicht gesehen hat, setzt er einen via-Punkt auf diesem Umweg.

Falls zwei nicht zusammenhängende Teile einer Buslinie bekannt sind, erfasst man sie einfach in zwei Relationen. Das geschieht schon von allein, da der zweite Mapper im allgemeinen nicht weiß, dass schon ein anderer Teil existiert. Sobald die Teilstrecken zusammenwachsen, kopiert man die Inhalte in eine einzige Relation.

Ich sehe keinen Sinn darin, diese technische Diskussion fortzusetzen. Die ÖPNV-Erfassung in OSM krankt nicht an fehlenden Taggingmöglichkeiten sondern an der Bereitschaft der Mapper, Buslinen zu erfassen und zu pflegen. In Kiel und 25km Umkreis sind im letzten Jahr kaum neue Strecken erfasst worden. Die bestehenden Relationen sind meist wilde Mischungen des alten und des PTP-Schemas. Über eine Innenstadtstraße (Eggerstedtstraße), die schon seit Jahren nicht mehr von Bussen befahren wird, laufen noch 9 Linienrelationen, weil niemand in stundenlanger Detailarbeit die Daten bereinigen will.

Weides Vorschlag hat sicher einige Vorzüge, aber die dreistufigen Relationen erfordern viel Einarbeitung und sind mit den einfachen Editoren (alles außer josm) kaum zu bearbeiten. Ich befürchte, dass sich damit die Breitschaft der Mapper zur ÖPNV-Erfassung nicht erhöht.

Deshalb plädiere ich für ein Schema, dass die Arbeit für die Mapper minimiert.

PS: die Bezeichnung "via-Konzept" finde ich falsch. Die Linien werden im allgemeinen nur über die Haltepunkte definiert. Via-Punkte sind nur in Ausnahmefällen nötig, um eine korrekte Kartendarstellung zu erreichen. "Punktbasiertes Modell" passt besser.

rayquaza · 2013-07-30 01:43:24

seawolff wrote:

Ich sehe keinen Sinn darin, diese technische Diskussion fortzusetzen. Die ÖPNV-Erfassung in OSM krankt nicht an fehlenden Taggingmöglichkeiten sondern an der Bereitschaft der Mapper, Buslinen zu erfassen und zu pflegen. In Kiel und 25km Umkreis sind im letzten Jahr kaum neue Strecken erfasst worden. Die bestehenden Relationen sind meist wilde Mischungen des alten und des PTP-Schemas. Über eine Innenstadtstraße (Eggerstedtstraße), die schon seit Jahren nicht mehr von Bussen befahren wird, laufen noch 9 Linienrelationen, weil niemand in stundenlanger Detailarbeit die Daten bereinigen will.

Sehe ich auch so. Deshalb finde ich, dass (zumindest erstmal) Neuerungen nur in Form von Erweiterungen des aktuellen PTP-Schemas erfunden werden sollten. Ansonten müssten sich von den eh schon Wenigen, die sich darum kümmern wollen würden, deutlich mehr Nutzer in ein neues Schema einarbeiten, was die Erfassung nochmal lange behindert.

slhh · 2013-07-30 01:47:20

Weide wrote:

Der Relationstyp bestimmt, welche Bedeutung die Rollen, die Einträge und ihre Reihenfolge haben. In Relationen vom Typ type=route galt vor dem PTP, dass z.B. die leere Rolle an einem Weg eine bidirektionale Nutzung des Weges angibt und eine unidirektionale Nutzung mit "forward" und "backward" angegeben.
Weide

Meines Erachtens könnte man dieses Problem durch einen zusätzlichen Key für die Route-Relation lösen, der die Interpretation der Reihenfolge bestimmt (z.B. route:type=* oder sequential=*). Unterschieden werden sollten:

Route:type=orderless oder sequential=no: Ungeordnete und damit ungerichtete Interpretation. Durch durchgehende Verwendung von forward und backward Rollen kann dennoch eine gerichtete Route definiert sein. Die Member können sortiert oder unsortiert sein.
Route:type=sequential oder sequential=yes: Sequenzielle und damit gerichtete unidirektionale Interpretation wie für PTP. Forward und backward Rollen wären prinzipiell damit kompatibel, jedoch ist ihre Anwendung als zusätzliche wegbezogene Einschränkung aufgrund der insgesamt unidirektionalen Interpretation der gesamten Relation völlig unnötig, da man Wege einfach weglassen würde, wenn sie in dieser Relationsrichtung nicht nutzbar sind.
Route:type=sequential_reverse oder sequential=reverse: Dito, jedoch umgekehrte Reihenfolge. Die könnte man z.B. bei PT die Erstellung der Gegenrichtung auf Basis einer Kopie erleichtern.
man könnte definieren, das diese Art von einem Bot, der API oder einem Editor automatisch in den positiv gerichteten Typ konvertiert werden kann.
Route:type=sequential_bidirectional oder sequential=bidirectional: Dito, jedoch bidirektionale Deutung. Hier könnte bei Bedarf wieder forward und backward als Wegrichtungs-abhängige Einschränkung genutzt werden. Da dies eher unübersichtlich ist könnte man z.B. ein "+" und "-" Präfix für die Rollen definieren, um diese stattdessen für positive oder negative Sequenzrichtung einzuschränken.
Für Bus-Routen in eher ländlichen Gebieten, wo baulich getrennte Fahrbahnen selten sind, oder für eingleisige Bahnen könnte dies auch eine Vereinfachung bringen. Ebenso könnte dieser Typ bei Fahrradrouten etc. sinnvoll sein.

Weide · 2013-07-30 06:45:07

Ich schätze die Lage jetzt so ein: Die Chancen, dass der Vorschlag durchkäme und sich dann durchsetzen würde, sind gering. Es ist aber kein sinnvolles Ziel, noch ein Schema neben die anderen zu stellen und die Taggingarten weiter aufzusplitten. Ich ziehe den Vorschlag daher zurück und werde ihn nächste Tage wieder von der User-Seite entfernen -- falls jemand daran weiterarbeiten will, müsste er/sie rechtzeitig kopieren.

Weide

Netzwolf · 2013-07-30 07:35:40

Moins,

mich hat die Diskussion an das hier erinnert. Streiche Informatiker, setze OSMler.

Gruß Wolf

wambacher · 2013-07-30 09:59:31

Weide wrote:

Ich schätze die Lage jetzt so ein: Die Chancen, dass der Vorschlag durchkäme und sich dann durchsetzen würde, sind gering. Es ist aber kein sinnvolles Ziel, noch ein Schema neben die anderen zu stellen und die Taggingarten weiter aufzusplitten. Ich ziehe den Vorschlag daher zurück und werde ihn nächste Tage wieder von der User-Seite entfernen -- falls jemand daran weiterarbeiten will, müsste er/sie rechtzeitig kopieren.
Weide

Pragmatische Lösung. Wenn (d)eine Idee so breit getreten wird, dass man selber nicht mehr weiß, wo es lang gehen soll, lässt man es besser.
Schade - aber wohl nicht anders zu machen.

Ergebnis für mich: Falls ich jemals noch einen Bus-Route anfassen sollte, lass ich die Haltepunkte weg.

Gruss
walter

Geogast · 2013-07-30 10:15:05

Weide wrote:

Ich schätze die Lage jetzt so ein: Die Chancen, dass der Vorschlag durchkäme und sich dann durchsetzen würde, sind gering. Es ist aber kein sinnvolles Ziel, noch ein Schema neben die anderen zu stellen und die Taggingarten weiter aufzusplitten. Ich ziehe den Vorschlag daher zurück und werde ihn nächste Tage wieder von der User-Seite entfernen -- falls jemand daran weiterarbeiten will, müsste er/sie rechtzeitig kopieren.
Weide

Danke auf jeden Fall für die ganze Mühe und das Überlegen!
Ich fänd es schade, wenn du deine Überlegungen einfach löschen würdest. Vielleicht ist die Diskussion in 2 oder n Jahren ja ganz woanders und es kann dann noch nützlich sein. Oder eine Unterseite zur User-Seite?

Announcement

#76 2013-07-28 15:14:03

Re: ÖPNV Vorentwurf (zurückgezogen)

#77 2013-07-28 23:56:16

Re: ÖPNV Vorentwurf (zurückgezogen)

#78 2013-07-29 00:23:20

Re: ÖPNV Vorentwurf (zurückgezogen)

#79 2013-07-29 00:28:02

Re: ÖPNV Vorentwurf (zurückgezogen)

#80 2013-07-29 06:22:57

Re: ÖPNV Vorentwurf (zurückgezogen)

#81 2013-07-29 06:41:31

Re: ÖPNV Vorentwurf (zurückgezogen)

#82 2013-07-29 06:44:21

Re: ÖPNV Vorentwurf (zurückgezogen)

#83 2013-07-29 07:35:33

Re: ÖPNV Vorentwurf (zurückgezogen)

#84 2013-07-29 07:51:50

Re: ÖPNV Vorentwurf (zurückgezogen)

#85 2013-07-29 08:21:49

Re: ÖPNV Vorentwurf (zurückgezogen)

#86 2013-07-29 08:25:17

Re: ÖPNV Vorentwurf (zurückgezogen)

#87 2013-07-29 08:34:57

Re: ÖPNV Vorentwurf (zurückgezogen)

#88 2013-07-29 08:58:28

Re: ÖPNV Vorentwurf (zurückgezogen)

#89 2013-07-29 11:59:47

Re: ÖPNV Vorentwurf (zurückgezogen)

#90 2013-07-30 00:36:31

Re: ÖPNV Vorentwurf (zurückgezogen)

#91 2013-07-30 01:43:24

Re: ÖPNV Vorentwurf (zurückgezogen)

#92 2013-07-30 01:47:20

Re: ÖPNV Vorentwurf (zurückgezogen)

#93 2013-07-30 06:45:07

Re: ÖPNV Vorentwurf (zurückgezogen)

#94 2013-07-30 07:35:40

Re: ÖPNV Vorentwurf (zurückgezogen)

#95 2013-07-30 09:59:31

Re: ÖPNV Vorentwurf (zurückgezogen)

#96 2013-07-30 10:15:05

Re: ÖPNV Vorentwurf (zurückgezogen)

Board footer