subject:"\[Talk\-de\] Einführung eines neuen Tags \(globaleID\)"

Am Tue, 23 Jul 2013 11:40:51 +0200
schrieb Tracy Kasperczyk kasperc...@mentzdv.de:

 Das Ziel im Bahnhof ist also der Bahnsteig und der Punkt, wo man in
 die Bahn einsteigen kann. (Solange wir die Reihung der Züge nicht
 kennen oder deren Haltepositionen rechnen wir mit einem Punkt).

Ich würde da eher mehrere Punkte nehmen, nämlich die Punkte, an denen
man den Bahnsteig verlassen kann. Diese haben zwar oft beträchtlichen
Abstand voneinander, aber die Passagiere steigen auch dort in
der Nähe ein und erfahrene Nutzer dort in der Nähe aus. Das bedeutet,
das das Routing das Optimum dieser Punkte suchen muss und dass bei mehr
als zwei Zugangsmöglichkeiten kein einzelner noch so geschickt
gewählter Punkt dieselben Ergebnisse liefern kann.

Beispiel Hilden Süd, Umsteigemöglichkeiten zwischen dem Bus 785 und der
S1: In vielen Fällen wird die Nutzung der
Bushaltestelle Talstraße/Hilden Süd (westliches Ende der Bahnsteige)
trotz Vorteilen gegenüber der östlichen Bushaltestelle Hilden Süd
S-Bahnhof nicht angeboten.

Nachteilig wäre allerdings, dass nicht jeder Routingalgorithmus damit
klar kommt, dass der Abstand des Bahnsteiges zu A plus dem
Abstand des Bahnsteiges zu B kleiner ist als der kürzeste
Weg von A nach B.

Wilhelm

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Einführung eines neuen Tags (globaleID)

Am Tue, 23 Jul 2013 11:40:51 +0200
schrieb Tracy Kasperczyk kasperc...@mentzdv.de:

 Weitere Datenelemente die wir brauchen, sind die oben erwähnten
 Haltepunkte auf den Schienen oder die Haltepunkte der Busse vor dem
 Bahnhof. Dies Punkte brauchen wir um einen Weg auf die Karte zeichnen
 zu können. Dort ist Anfang oder Ende des Wegs im Fahrzeug und der
 Übergang auf den Fußweg. Das sind bekannte OSM Objekte (
 http://wiki.openstreetmap.org/wiki/Tag:public_transport%3Dstop_position)

Nicht unbedingt. Die stop_positions sind stets Teil des angegebenen
Fahrwegs und damit geometrisch oft von der Einstiegsstelle entfernt.
Nicht baulich von der Straße getrennte Haltebuchten werden nicht als
getrennte Wege eingezeichnet. Als Endpunkte des Fußroutings kommen
stop_positions m.E. nicht in Frage.

Wilhelm

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Einführung eines neuen Tags (globaleID)

Am Tue, 23 Jul 2013 11:40:51 +0200
schrieb Tracy Kasperczyk kasperc...@mentzdv.de:

 Schienen werden von uns nicht angefasst. Das einzige was wir machen,
 wenn zu wenig Schienen eingezeichnet sind, wie es bei U-Bahnlinien
 der Fall ist, dann erweiteren wir diese möglichst nach der genauen
 Lage.

Das bedeutet aber, dass die bisher in einem Way mit mehreren Tracks
gemappten Linien nun richtig auf die einzelnen Ways verteilt werden
müssen. Das gilt auch für diejenigen Linien, zu deren Betreiber ihr
keine Geschäftsbeziehung habt. Das kann in seltenen Fällen eine
vor-Ort-Recherche erzwingen.

Wilhelm
 

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Einführung eines neuen Tags (globaleID)

Am Tue, 23 Jul 2013 11:40:51 +0200
schrieb Tracy Kasperczyk kasperc...@mentzdv.de:

 Objekt: Haltepunkt (Type: Node auf dem Way Schiene)
 
 -  railway = stop (vorher haben wir station getaggt, es war uns nicht
 ganz klar was der unterschied zwischen Station und Stop in diesem
 Fall ist)

Station und stop stammen meines Wissens aus der Zeit, als einzelne
Gleise noch nicht gemappt wurden. Es waren kleine und große Bahnhöfe,
die einfach als Punkt in den Way gesetzt wurden. Als dann Gleise einzeln
gemappt wurden, haben viele Leute die Punkte verdoppelt (falsch, da
dort nicht mehrere Bahnhöfe sind) oder auf einem der Gleise gelassen
(falsch, da der Bahnhof zu beiden Gleisen gehört). Das Problem liegt
m.W. ungelöst rum und wurde durch das Tagging per Public Transport
Proposal gelöst.

 - ref = 1 (Gleisnummer)
 
 - name = Ostbahnhof München

ref bezieht sich meines Wissens auf den Bahnhof. Es ist aber sehr
üblich, dort die Bahnsteignummer unterzubringen.

 - name = Untertürkheim, Bahnsteig 1
 
 - public_transport = platform

Der Name sollte hier Untertürkheim sein. Das ergibt sich aus den
Angaben im Public Transport Proposal (Stichwort optional, wenn). Das
steht aber sogar im Wiki falsch.

 - train = yes

... ist nur für stop_positions vorgesehen.

 In den vorhandenen Daten sind Bahnsteige aus Routinggründen
 häufig zweigeteilt.

Die Routinggründe sehe ich noch nicht. Wenn es sie gibt, dann ist das
ein echtes Problem. Man kann einen Bahnsteig zweiteilen um
Daten hinzuzufügen -- z.B. die Flächen über den Treppen heraus zu
nehmen. Wenn aber jetzt jemand dort schon ein Multipolygon angelegt hat
und die Fläche richtig dargestellt ist, dann ist es eigentlich gegen
die guten Sitten, dort ohne Diskussion mit dem Ersteller etwas zu
ändern.


Man muss auch noch trotz weiterer Unterteilungen Routing betreiben
können; diese Unterteilungen ergeben sich oft, wenn Steige teilweise
auf Brücken liegen.

 Um diese wieder zu vereinigen, werden sie  durch
 eine Relation zusammengefasst. Wir benutzen die Relation stop_area.
 Falls dies nicht gewünscht wird könnten wir auch eine eigene Relation
 anlegen.

stop_area ist der Gesamt-Bahnhof und passt damit nicht. Ich sehe
keinen Grund, eine extra Relation anzulegen.


 Objekt: Aufzug (Type: way)
 
 - highway = elevator
Ways sollte man laut Wiki für Schrägaufzüge nehmen. Normale Aufzüge
gehen mit einem Punkt.

Wilhelm

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Einführung eines neuen Tags (globaleID)

2013-07-27 Diskussionsfäden Martin Koppenhoefer

Am 27. Juli 2013 19:20 schrieb Wilhelm Spickermann o...@spickermann-d.de:

 Station und stop stammen meines Wissens aus der Zeit, als einzelne
 Gleise noch nicht gemappt wurden. Es waren kleine und große Bahnhöfe,
 die einfach als Punkt in den Way gesetzt wurden. Als dann Gleise einzeln
 gemappt wurden, haben viele Leute die Punkte verdoppelt (falsch, da
 dort nicht mehrere Bahnhöfe sind) oder auf einem der Gleise gelassen
 (falsch, da der Bahnhof zu beiden Gleisen gehört). Das Problem liegt
 m.W. ungelöst rum




railway=station auf einer area, die das gesamte (geschätzte soweit man
keine genaueren Informationen hat) Bahnhofsgelände umfasst, also nicht nur
Gebäude sondern auch Gleise und Bahnsteige, ggf. auch Parkplätze, Kneipe
und andere Nebengebäude etc.

Gruß Martin
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Einführung eines neuen Tags (globaleID)

2013-07-27 Diskussionsfäden fly

Am 27.07.2013 19:20, schrieb Wilhelm Spickermann:
 Am Tue, 23 Jul 2013 11:40:51 +0200
 schrieb Tracy Kasperczyk kasperc...@mentzdv.de:
 - train = yes
 
 ... ist nur für stop_positions vorgesehen.

Das ist mir neu und auch nicht verständlich. Warum nicht auch für
platform verwenden ? Kann durch aus Sinn machen.


 In den vorhandenen Daten sind Bahnsteige aus Routinggründen
 häufig zweigeteilt.
 
 Die Routinggründe sehe ich noch nicht. Wenn es sie gibt, dann ist das
 ein echtes Problem. Man kann einen Bahnsteig zweiteilen um
 Daten hinzuzufügen -- z.B. die Flächen über den Treppen heraus zu
 nehmen. Wenn aber jetzt jemand dort schon ein Multipolygon angelegt hat
 und die Fläche richtig dargestellt ist, dann ist es eigentlich gegen
 die guten Sitten, dort ohne Diskussion mit dem Ersteller etwas zu
 ändern.

+1

Und bitte nicht einfach umtaggen und löschen wenn es schon anders
erfasst ist, sondern vor Ort überprüfen bzw eine_n lokale_n Mapper_in
fragen.

Habe schon einige Stellen entdeckt, wo die importierten Daten falsch sind !
Damit sollte wohl vor dem Import erstmal eine Datenprüfung erfolgen. Ich
weiß noch nicht einmal wie aktuell die Importdaten denn sind!

Bekommt OSM denn Spenden von den Unternehmen für gemeldete Fehler ?

cu
fly

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Einführung eines neuen Tags (globaleID)

2013-07-25 Diskussionsfäden Peter Wendorff

Am 25.07.2013 00:00, schrieb Martin Koppenhoefer:
 
 
 Am 24/lug/2013 um 23:02 schrieb Dirk Sohler s...@0x7be.de:
 
 Gerade wenn dieses Routing so
 unlogische, und unerwünschte Sachen wie gesplittete Bahnsteige oder
 Aufzüge als Weg gemappt verlangt.
 
 
 m.E. ist ein Aufzug als way logischer denn als node. :)
In einer 3D-Welt gebe ich dir recht, auf einer 2D-Karte halte ich das
für grenzwertig. Etliche QA-Tools beschweren sich - z.T. zu unrecht -
ohne weitere Prüfung über zwei nodes an der gleichen Position, du willst
auch noch einen way dazwischenlegen...
Das ist aus der Sicht des Graphen ideal, aber nicht notwendig, und aus
Sicht der Bearbeitung grausam mit allen bisher existierenden Editoren.

Nehmen wir an, der Aufzug ist als Node getagged.
a) Router berücksichtigt Aufzüge nicht:
   = Die Verbindung zu allen Wegen auf anderen Stockwerken bleibt
möglich; nur der Aufzug wird nicht genannt. Nicht ideal, weil vor allem
das Stockwerk vermutlich nicht angesagt wird, aber möglich.
b) Router berücksichtigt Aufzüge:
  = alles, was dazu notwendig ist, erfordert die Ansage des Aufzugs mit
from_level und to_level.

Wird der Aufzug dagegen als Way getagged, so muss das trotzdem
berücksichtigt werden beim Routing, denn sonst wird die
Navigationsansage oder -grafik unverständlich:
- Die berechnete Länge des Weges bei Annahme von 2D (das ist das
übliche) ist 0
- Die berechnete Richtung des Weges ist - undefiniert, aber jedenfalls
bestimmt nicht aufwärts oder abwärts, solange nicht Aufzüge
unterstützt werden, was dann auch den Node-Aufzug problemlos werden ließe.

Gruß
Peter
 
 Gruß,
 Martin
 ___
 Talk-de mailing list
 Talk-de@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-de
 


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Einführung eines neuen Tags (globaleID)

2013-07-25 Diskussionsfäden Martin Koppenhoefer

Am 25. Juli 2013 09:48 schrieb Peter Wendorff wendo...@uni-paderborn.de:

 In einer 3D-Welt gebe ich dir recht, auf einer 2D-Karte halte ich das
 für grenzwertig. Etliche QA-Tools beschweren sich - z.T. zu unrecht -
 ohne weitere Prüfung über zwei nodes an der gleichen Position, du willst
 auch noch einen way dazwischenlegen...



Beides hat in bestimmten (raren Ausnahme-)Situationen seine Berechtigung
(für 2 nodes übereinander wird aber wohl die überwiegende Mehrheit auf
schlecht durchgeführte Imports und Editorbugs bzw. Upload-Probleme
zurückzuführen sein, von daher ist es m.E. gut, dass QA-tools hier auf ein
potenzielles Problem hinweisen, vor allem, wenn die nodes keine Layer-tags
haben).



 Das ist aus der Sicht des Graphen ideal, aber nicht notwendig, und aus
 Sicht der Bearbeitung grausam mit allen bisher existierenden Editoren.



+1, mir ging es mehr ums unlogisch ;-)



 - Die berechnete Richtung des Weges ist - undefiniert, aber jedenfalls
 bestimmt nicht aufwärts oder abwärts, solange nicht Aufzüge
 unterstützt werden, was dann auch den Node-Aufzug problemlos werden ließe.



vermutlich doch, wenn der Router gut gemacht ist, die Topologie ist ja
durch die layer-tags der angeschlossenen Wege (und nodes) definiert.

Was das 2D/3D-Thema angeht: OSM ist prinzipiell als Rapresentation der
echten Welt 3D, auch wenn wir bisher eher 2,5 D mappen (2D und
Höhenangaben).


Gruß Martin
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Einführung eines neuen Tags (globaleID)

2013-07-25 Diskussionsfäden rainerU

Am 24.07.2013 03:27, schrieb Tirkon:
 Hier kommt nun ein Problem zu Tage. Unsere Daten sind unter der freien
 Lizenz ODbL verfügbar. 
 http://opendatacommons.org/licenses/odbl/
 Damit das so bleibt, müsste das auch für die von Euch eingepflegten
 Daten gelten. 

Streng genommen reicht eine Zustimmung zur Nutzung dr Daten unter der ODbL nicht
aus. In Punkt 3 der Contributor Terms heißt es:

...or such other free and open licence (for example,
http://www.opendefinition.org/okd/) as may from time to time be chosen by a vote
of the OSMF membership and approved by at least a 2/3 majority vote of active
contributors.

Der Verkehrsbetrieb oder -verbund muss also auch damit einverstanden sein, dass
seine Daten nach einem eventuellen Wechsel zu einer anderen freien und offenen
Lizenz weiter in der OSM-Datenbank bleiben dürfen. Auf der sicheren Seite ist
man, wenn man das Einverständnis des Datenlieferanten hat, dass OSM die Daten
unter den Bedingungen der CT nutzen darf.

Da man dieses Einverständis so explizit meist nicht bekommt, halte ich die
Verfolgbarkeit der Daten für besonders wichtig. So kann man sie später notfalls
wieder löschen, wenn sich herausstellt, dass das alles nicht so gemeint war.

Gruß
Rainer


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Einführung eines neuen Tags (globaleID)

2013-07-25 Diskussionsfäden Tirkon

Henning Scholland o...@aighes.de wrote:

Am 24.07.2013 03:27, schrieb Tirkon:
 Zunächst einmal an die Community. Im Allgemeinen wünschen wir Quellen
 für Importe. Bezogen auf die geografischen Einordnung ist dies aber in
 diesem Falle möglicherweise schwierig, wenn diese Daten überhaupt erst
 mit Hilfe von OSM Werkzeugen erstmals im geografischen Umfeld erfasst
 werden. Wir haben hier möglicherweise eine bisher nie oder kaum
 dagewesene Situation, dass OSM die Erstveröffentlichungsquelle ist und
 damit eine andere Quelle nicht zur Verfügung steht. Dann müssten wir
 uns im Rahmen dieses Imports überlegen, wie die für Importe notwendige
 Zusicherung, diese Daten unter der OSM Lizenz veröffentlichen zu
 dürfen, bewirkt werden kann. Ich denke, hier sollten wir unsere
 Data-Working-Group mit ihren entsprechenden Erfahrungen mit größeren
 Importen um Mithilfe bitten.
Hallo,
die Erlaubnis dazu muss der Urheber der Daten geben, genauso wie bei 
jedem anderen Beitrag zu OSM auch. Oder wo siehst du hier etwas anders?

Nein, hatte ich im gleichen Beitrag weiter unten auch so geschrieben.
Zitat
Hier kommt nun ein Problem zu Tage. Unsere Daten sind unter der freien
Lizenz ODbL verfügbar. 
http://opendatacommons.org/licenses/odbl/
Damit das so bleibt, müsste das auch für die von Euch eingepflegten
Daten gelten. Sofern Daten selbst vor Ort erfasst werden, ist das kein
Problem. Anders ist es, wenn man sich dabei auf Daten Dritter stützt.
Dann müsste das offizielle Einverständnis des Datengebers vorliegen
und es kämen weitere Sonderregeln für Importe zum Tragen, die man hier
nachlesen kann:
http://wiki.openstreetmap.org/wiki/Import/Guidelines
Zitat Ende

(Im ersten Posting habe ich dies versehentlich nicht reinkopiert:)

Der feine Unterschied ist aber, dass OSM möglicherweise die
Erstveröffentlichungsquelle bezüglich der Verortung in der Umgebung
ist. Von daher könnte es dann keine Karte geben, die als Quelle
herangezogen werden kann. Der VRR könnte dann nicht ohne Weiteres
schreiben, dass er die Daten aus der Kartenquelle XY freigibt.

Denn bisher wurde immer die Quelle (Karte oder Datei) genannt, so dass
sich die Bestätigung darauf beziehen konnte. So konnte jeder OSM User
die Äquivalenz des Imports mit dem eingebrachten Datenmaterial und
damit die Richtigkeit der Lizenzfreigabe für dieses Material prüfen.
Wenn es solche Quellen aber nicht gibt, müsste diese Prüfung hier
anders vonstatten gehen. Ich hoffe, der feine Unterschied ist klar
geworden.

Und wie diese Prüfung dann funktionieren soll, sollte IMHO von der
Data Working Group besprochen werden. Wenn die Firma hier im Thread
ihre Quellenlage nicht kundtun möchte, wäre die DWG als offizieller
Vertreter der Foundation möglicherweise ein besserer Ansprechpartner.
Immerhin haben die Firmenmapper schon einen Gutteil in die Datenbank
eingetragen. Aus all diesen Gründen habe ich das hier thematisiert.

http://wiki.openstreetmap.org/wiki/Import_%C3%96PNV_Firma_Mentz_Datenverarbeitung_GmbH


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Einführung eines neuen Tags (globaleID)

2013-07-25 Diskussionsfäden fly

On 25.07.2013 19:46, Tirkon wrote:
 Henning Scholland o...@aighes.de wrote:
 Am 24.07.2013 03:27, schrieb Tirkon:

 http://wiki.openstreetmap.org/wiki/Import_%C3%96PNV_Firma_Mentz_Datenverarbeitung_GmbH

Also wenn zumindest einer der User potlatch2 verwendet, wundert es mich
nicht mehr warum dabei relationen kaputt gehen !

Für solche Aufgaben, braucht mensch einen Editor, der auch mit
Relationen umgehen kann.

my 2 ct

fly

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Einführung eines neuen Tags (globaleID)

2013-07-24 Diskussionsfäden Peter Wendorff

Hallo Michael.
Das ist jetzt schon weit vom eigentlichen Thema entfernt, aber eine
Breite auf einem Weg anzugeben, wenn der Tunnel letztlich 40 Meter
breit ist? Ständig die Breite ändert etc?
Richtig ist: Es gibt bisher keine adäquate Lösung dafür,
aber eine Breite an den Weg zu mappen kann doch auch nicht die Lösung sein.
Wir reden über Tunnel, in denen quer verteilt Fahrkarten- und
Süßigkeitenautomaten, Zeitschriftenläden und Papp-Brötchen-Verkäufer,
Bänke und Mülleimer stehen, die breiter sind als etliche Wohnhäuser (die
selbstverständlich einzeln eingetragen sind).

Die Breite dieser Tunnel ändert sich z.T. stetig, anderswo gibt es Ecken
und Kanten.
Mit Breite-Angaben auf einem (!) way in der Mitte ist da nichts getan,
um das anzugeben.

Wie genau das zu lösen ist, weiß ich auch nicht.
Ich gebe dir sicher recht: Einfach so Flächen zeichnen geht zu schnell
schief.
Aber das einfach abzulehnen, nur weil das jetzt ein Tunnel und nicht ein
von Mauern umgebener Platz an der Oberfläche ist, halte ich für genauso
falsch.

Gruß
Peter

Am 24.07.2013 00:39, schrieb Michael Kugelmann:
 Am 23.07.2013 11:40, schrieb Tracy Kasperczyk:
 Tunnel sind oft schon in den Daten vorhanden. Die sind für uns als
 Wegelemente sehr hilfreich. Allerdings wollen wir auch Karten für den
 Untergrund zeichnen, wenn sehr breite Tunnels nur als Strich daherkommen
 ist das irreführend. Wir brauchen also zusätzlich Flächen.
 -1, absolut dagegen.
 Wir malen keine Karten mit einem Malprogramm sondern wir erfassen
 die Topologie! Da was schon immer so und sollte auch so bleiben. Wenn,
 dann gebt z.B. für einen Weg eine Breite mittels width == xxx an.
 
 Wir sind schon seit einiger Zeit mit der
 Münchner OSM Gruppe in Kontakt und haben viel gelernt.
 :-)
 
 
 Grüße,
 Michael.
 
 
 ___
 Talk-de mailing list
 Talk-de@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-de
 


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Einführung eines neuen Tags (globaleID)

2013-07-24 Diskussionsfäden Henning Scholland


Hallo,
Lösungen gibt es schon für gerichtete Wege, die als Fläche eingetragen 
werden sollen. Diese nennt sich area:highway=normale-highway-Klasse. 
Diese Fläche soll aber immer zusätzlich zu dem Graphen eingetragen werden.


Henning


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Einführung eines neuen Tags (globaleID)

2013-07-24 Diskussionsfäden Henning Scholland


Am 24.07.2013 03:27, schrieb Tirkon:

Zunächst einmal an die Community. Im Allgemeinen wünschen wir Quellen
für Importe. Bezogen auf die geografischen Einordnung ist dies aber in
diesem Falle möglicherweise schwierig, wenn diese Daten überhaupt erst
mit Hilfe von OSM Werkzeugen erstmals im geografischen Umfeld erfasst
werden. Wir haben hier möglicherweise eine bisher nie oder kaum
dagewesene Situation, dass OSM die Erstveröffentlichungsquelle ist und
damit eine andere Quelle nicht zur Verfügung steht. Dann müssten wir
uns im Rahmen dieses Imports überlegen, wie die für Importe notwendige
Zusicherung, diese Daten unter der OSM Lizenz veröffentlichen zu
dürfen, bewirkt werden kann. Ich denke, hier sollten wir unsere
Data-Working-Group mit ihren entsprechenden Erfahrungen mit größeren
Importen um Mithilfe bitten.

Hallo,
die Erlaubnis dazu muss der Urheber der Daten geben, genauso wie bei 
jedem anderen Beitrag zu OSM auch. Oder wo siehst du hier etwas anders?


Henning
für die DataWorkingGroup


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Einführung eines neuen Tags (globaleID)

2013-07-24 Diskussionsfäden Thomas Reincke


Am 24.07.2013 07:35, schrieb Dirk Sohler:

Dass das geht, zeigen diverse Routingprogramme, die ohne Probleme über
Treppen und Aufzüge routen können.


Klar geht das. Allerdings macht es bei immer wiederkehrenden Wegen m.E. 
schon Sinn, diese vorzuberechnen.


Daher würde ich zwischen zwei Wegetypen unterscheiden.
a) Wege zur Haltestelle

Diese sind relativ individuell. Da macht es Sinn, diese individuell 
berechnen.


b) Wege innerhalb von Haltestellen.

Diese sind permanent wiederkehrend und müssen ggf. auch andere 
Parametern als der erforderlichen Wegzeit berücksichtigen.


Z.B. gibt es im Blockverkehr durch örtlich gesichertes Personal 
Umstiege, die auch bei 0 Minuten Übergangszeit erfahrungsgemäß gut 
funktionieren. Auch an anderen Stellen gibt es das.


Zu den Wegen innerhalb von Haltestellen würde ich auch die Wege zu den 
Ein- und Ausgängen bei Bahnhöfen oder U-Bahn-Stationen zählen.


Klar sollte man diese Wege/Zeiten rechnerisch überprüfen und ggf. 
korrigieren.


Bei den vielfältigen Parametern der RMV-Fahrplanauskunft für 
Mobilitätsbehinderte

http://www.rmv.de/baim/bin/jp/query.exe/dn?L=vs_rmv.vs_baimprofile#bDetails

ist dieses m.W. auch der Fall.

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Einführung eines neuen Tags (globaleID)

2013-07-24 Diskussionsfäden Tirkon

Henning Scholland o...@aighes.de wrote:

die Erlaubnis dazu muss der Urheber der Daten geben, genauso wie bei 
jedem anderen Beitrag zu OSM auch. Oder wo siehst du hier etwas anders?

Nein, hatte ich im gleichen Beitrag auch so geschrieben:
Zitat
Hier kommt nun ein Problem zu Tage. Unsere Daten sind unter der freien
Lizenz ODbL verfügbar. 
http://opendatacommons.org/licenses/odbl/
Damit das so bleibt, müsste das auch für die von Euch eingepflegten
Daten gelten. Sofern Daten selbst vor Ort erfasst werden, ist das kein
Problem. Anders ist es, wenn man sich dabei auf Daten Dritter stützt.
Dann müsste das offizielle Einverständnis des Datengebers vorliegen
und es kämen weitere Sonderregeln für Importe zum Tragen, die man hier
nachlesen kann:
http://wiki.openstreetmap.org/wiki/Import/Guidelines
Zitat Ende

Henning
für die DataWorkingGroup
O.K.


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Einführung eines neuen Tags (globaleID)

2013-07-24 Diskussionsfäden Peter Wendorff

Am 24.07.2013 22:07, schrieb Thomas Reincke:
 Am 24.07.2013 07:35, schrieb Dirk Sohler:
 Dass das geht, zeigen diverse Routingprogramme, die ohne Probleme über
 Treppen und Aufzüge routen können.
 
 Klar geht das. Allerdings macht es bei immer wiederkehrenden Wegen m.E.
 schon Sinn, diese vorzuberechnen.
Jetzt aber bitte nicht wieder alles in einen Topf werfen:
Vorberechnen ist nicht in die OSM-Datenbank legen.

Gruß
Peter

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Einführung eines neuen Tags (globaleID)

2013-07-24 Diskussionsfäden Dirk Sohler

Thomas Reincke schrieb:
 b) Wege innerhalb von Haltestellen.
 
 Diese sind permanent wiederkehrend und müssen ggf. auch andere 
 Parametern als der erforderlichen Wegzeit berücksichtigen.
 
 […]
 
 Klar sollte man diese Wege/Zeiten rechnerisch überprüfen und ggf. 
 korrigieren.

Aber was hat hat das in der Geodatenbank von OSM verloren?

Das sollte derjenige, der das anbieten will, idealer weise in einer
eigenen Datenbank verwalten, und bei bedarf mit den OSM-Daten
zusammenführen und ausliefern – Gerade wenn dieses Routing so
unlogische, und unerwünschte Sachen wie gesplittete Bahnsteige oder
Aufzüge als Weg gemappt verlangt.

Grüße,
Dirk

-- 
Local time :: Ortszeit :: DE-HH
2013-07-24T22:59:41+0200


signature.asc
Description: PGP signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Einführung eines neuen Tags (globaleID)

2013-07-24 Diskussionsfäden Martin Koppenhoefer



Am 24/lug/2013 um 23:02 schrieb Dirk Sohler s...@0x7be.de:

 Gerade wenn dieses Routing so
 unlogische, und unerwünschte Sachen wie gesplittete Bahnsteige oder
 Aufzüge als Weg gemappt verlangt.


m.E. ist ein Aufzug als way logischer denn als node. :)

Gruß,
Martin
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Einführung eines neuen Tags (globaleID)

2013-07-23 Diskussionsfäden Wilhelm Spickermann

Am Mon, 22 Jul 2013 16:43:25 +0200
schrieb fly lowfligh...@googlemail.com:

 Hat sich das denn jetzt aufgeklärt oder geht das weiter ?

taoxue hat vorhin mit mir Kontakt aufgenommen und ich habe dazu geraten,
die Sache hier in der Liste zu besprechen. Ich denke, dass wir
akzeptable Lösungen finden können, aber die Sachen müssen jetzt in der
Liste geklärt werden.

Wilhelm

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Einführung eines neuen Tags (globaleID)

2013-07-23 Diskussionsfäden Tracy Kasperczyk

Liebe OSM Gemeinde,

Wir wollen euch noch mal genauer erklären was wir machen.



Der VRR (Verkehrsverbund Rhein-Ruhr) auch tätig als zentraler Koordinator
für das Land Nordrhein Westfalen beabsichtigt als Kartenbasis in Zukunft
auf OSM zu setzen. Das betrifft folgende Produkte

· Die Karten, die Verkehrslinienpläne, die den Fahrplanbüchern
beiliegen und die an den Haltestellen aushängen sollen  aus den OSM Daten
errechnet und im VRR Layout dargestellt werden.

· Die Haltestellenumgebungspläne, die von einigen Betrieben
erstellt und ausgehängt werden, z.B. von der Rheinbahn in Düsseldorf sollen
aus OSM Daten erzeugt werden.

· Die interaktiven Karten die sie z.B. in efa.vrr.de sehen sollen
aus  OSM Daten berechnet werden

· Die interaktiven Karten der VRR App, dieselben wie die aus
efa.vrr.de sollen aus OSM berechnet werden (die Apps wurden schon ca.
1.000.000  mal heruntergeladen)

· Die Fahrten der Verkehrsmittel sollen referenziert mit OSM Daten
(dabei werden die Koordinaten der Fahrwege übernommen) auf diese Karten
gezeichnet werden (siehe auchefa.vrr.de und die Apps)

· Die Fußwege zu den Haltepunkten und bis zum Gleis der
Schienenverkehre sollen auf OSM Daten geroutet werden

· Die Apps sollen Fußwegnavigation auf den OSM Daten unter stützen

· Das Fußwegrouting  soll barrierefreie Wege suchen können (wird
weiter unter erklärt)



Für die Entscheidung des VRR waren Kostengründe maßgebend, aber vor allem
auch der Qualität und der Detailreichtum der OSM Daten hat den VRR
begeistert. Gerade in der Welt des Öffentlichen Verkehrs und des Fuß- und
Radverkehrs gibt es keine vergleichbaren GIS Daten. Gerade beim
Fußweg-Routing versprechen wir uns wesentlich Verbesserungen, da die OSM
Daten weit mehr Fuß- und Radwege und Straßenquerungen enthalten als andere
Datenmaterialien.



Das Datenmaterial, das wir in OSM vorfinden hat vor allem bezüglich der
Wege (Straßen und Schienenwege) aus ausgezeichnete Qualität.

 Einige Daten sind allerdings noch unvollständig für unsere
Aufgabenstellung und diese wollen wir nacherfassen, gerne auch gemeinsam
mit der OSM Gemeinde.



Ein Bereich der Nacherfassung umfasst die Busspuren und die Abbiegeverbote
oder Abbiegeerlaubnisse von Bussen. Wir haben Kontakt zu allen
Verkehrsbetrieben, wir können die Informationen von dort bekommen und
nachpflegen.



Der zweite Bereich umfasst die Bahnhöfe und die Haltestellen der
Schienenverkehre (Straßenbahn, U-Bahn). Es ist das Ziel einen Fußweg bis
von einem beliebigen Punkt im Wegenetz bis zum Bahnsteig und dem Haltepunkt
des Fahrzeugs zu berechnen, anzuzeigen und Navigation auf diesem Weg zu
ermöglichen. Dieser Weg soll auch barrierefrei sein. Was bedeutet das?



Gehen wir von drei typischen Benutzern aus:



Nutzer 1 ist Student, Pendler und in Turnschuhen unterwegs. Er kommt immer
knapp vor der Zugabfahrt. Er geht schnellen Schrittes durch den Bahnhof und
nimmt die Treppen hinauf zum Bahnsteig, damit er nirgends warten muss.



Nutzer 2 ist der Reisende mit Koffer, oder die/der Frau/Mann mit
Kinderwagen. Der Nutzer kann nur mit großer Mühe die Treppen nutzen und
sucht Wege über Rolltreppen zum Bahnsteig.



Nutzer 3 kommt im Rollstuhl. Er ist auf Aufzüge und Rampen angewiesen um
zum Bahnsteig zu kommen, er braucht entsprechende Wege.



Das Ziel im Bahnhof ist also der Bahnsteig und der Punkt, wo man in die
Bahn einsteigen kann. (Solange wir die Reihung der Züge nicht kennen oder
deren Haltepositionen rechnen wir mit einem Punkt).



Bahnsteige, wir nennen sie Plattformen, sind für Menschen mit
Mobilitätseinschrängungenzugänglich oder nicht, weil sie einen Aufzug haben
oder nicht. Es gibt Bahnhöfe, da sind nur einige Plattformen oder nur eine
für Menschen mit Mobilitätseinschrängungen zugänglich. Auch auf der
Plattform kann es mehrere Zugänge geben, oft einen mit Aufzug und
Rolltreppe und andere mit fester Treppe (Beispiel Düsseldorf Hbf).

Wir brauchen also alle Plattformen einzeln und alle Wegelemente im Bahnhof,
ebene Wege, Treppen, Rolltreppen, Rampen und Aufzüge. Diese Wegelemente
müssen „ways“ sein, sonst kann man nicht darüber routen.

Wir haben in den existierenden OSM Daten unterschiedliche Modellierungen
von Plattformen gefunden:

· Einen „way“ der an das Fußwegenetz angebunden ist, eignet sich
bei schmalen Bahnsteigen (Beispiel Stuttgart, Stadtbahnhaltestelle Berliner
Platz/Hohe Straße)

· Eine Fläche die an den Rändern an das Fußwegnetz angebunden ist,
eignet sich bei Seitenbahnsteigen (Beispiel, ….)

· Gesplittete Flächen, notwendig bei Mittelbahnsteigen (Gleise an
beiden Seiten) mit Zugang aus Tunnels oder von Brücken (Beispiel München
Ost)



Keine der drei Modellierungsarten ist unsere Erfindung, statt der
gesplitteten Flächen können man auch mit Flächen mit Löchern arbeiten
(Multipolygonen), das ist aber noch komplizierter und das haben wir noch
nirgends gesehen.

Das Splitten der Bahnsteige in 2 oder mehr Teile hat den Vorteil,

Re: [Talk-de] Einführung eines neuen Tags (globaleID)

2013-07-23 Diskussionsfäden rainerU

Hallo,


Am 23.07.2013 11:40, schrieb Tracy Kasperczyk:
 
 Tracy (taoxue)
 

Inhaltlich kann und will ich nichts beitragen, aber aus meiner Sicht fällt das
Eintragen dieser Daten unter die Import Guidelines [1]. Deshalb, aber auch wenn
man das nicht so sieht, wäre es sinnvoll, die Änderungen an der OSM-Datenbank
unter einem (oder mehreren) dafür vorgesehenen Account zu machen, dessen
Bezeichnung zum Ausdruck bringt, worum es geht, mit einer kurzen Beschreibung
des Projekts in der Profilbeschreibung und ggf. einer Wiki-Seite. Das würde
Mappern, die auf eure Changes stoßen, ungemein helfen und auch manche etwas
ungehalten wirkende Beiträge auf der Liste verhindern.

Gruß
Rainer

[1] http://wiki.openstreetmap.org/wiki/Import/Guidelines


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Einführung eines neuen Tags (globaleID)

2013-07-23 Diskussionsfäden Peter Wendorff

Hallo Tracy,

Am 23.07.2013 11:40, schrieb Tracy Kasperczyk:
 Liebe OSM Gemeinde,
 
 Wir wollen euch noch mal genauer erklären was wir machen.
Das ist super ;)
[...]

  Einige Daten sind allerdings noch unvollständig für unsere
 Aufgabenstellung und diese wollen wir nacherfassen, gerne auch gemeinsam
 mit der OSM Gemeinde.
Das klingt gut.

 Ein Bereich der Nacherfassung umfasst die Busspuren und die Abbiegeverbote
 oder Abbiegeerlaubnisse von Bussen. Wir haben Kontakt zu allen
 Verkehrsbetrieben, wir können die Informationen von dort bekommen und
 nachpflegen.
Das klingt gut - aber nach Import, deshalb bitte die Import-Richtlinien
berücksichtigen, wenn ihr nicht jede Haltestelle selbst kontrolliert dabei.
Eine Alternative ist oft, die Daten öffentlich und für die Nutzung
freigegeben zu hinterlegen, damit man verteilt die Haltestellen anhand
dessen überprüfen kann.

[...]
 
 Das Ziel im Bahnhof ist also der Bahnsteig und der Punkt, wo man in die
 Bahn einsteigen kann. (Solange wir die Reihung der Züge nicht kennen oder
 deren Haltepositionen rechnen wir mit einem Punkt).
 
 Bahnsteige, wir nennen sie Plattformen, sind für Menschen mit
 Mobilitätseinschrängungenzugänglich oder nicht, weil sie einen Aufzug haben
 oder nicht. Es gibt Bahnhöfe, da sind nur einige Plattformen oder nur eine
 für Menschen mit Mobilitätseinschrängungen zugänglich. Auch auf der
 Plattform kann es mehrere Zugänge geben, oft einen mit Aufzug und
 Rolltreppe und andere mit fester Treppe (Beispiel Düsseldorf Hbf).
 
 Wir brauchen also alle Plattformen einzeln und alle Wegelemente im Bahnhof,
 ebene Wege, Treppen, Rolltreppen, Rampen und Aufzüge. Diese Wegelemente
 müssen „ways“ sein, sonst kann man nicht darüber routen.
Fast richtig.
Ein Aufzug muss nicht zwingend ein way sein, um darauf route zu können.
Beispiel:
.x-'
.x und ' seien Nodes,  und  jeweils dazwiscchen ways.
x sei ein Aufzug und als solcher getagged (auf einem Node.
 trägt außerdem level=0, x trägt level=1 (was jeweils das Stockwerk
angibt).
Das Routing mit Berücksichtigung des Aufzugs ist hier problemlos möglich.

Ebene Wege, Treppen, Rolltreppen und Rampen sind üblicherweise ways in
OSM, Aufzüge aber nicht, weil sie kaum eine horizontale Ausdehnung
haben. Technisch ist das aber kein Problem auch im Routing zu
berücksichtigen.

 Wir haben in den existierenden OSM Daten unterschiedliche Modellierungen
 von Plattformen gefunden:
 
 · Einen „way“ der an das Fußwegenetz angebunden ist, eignet sich
 bei schmalen Bahnsteigen (Beispiel Stuttgart, Stadtbahnhaltestelle Berliner
 Platz/Hohe Straße)
stimmt, und sollte für euch kein Problem darstellen.
 
 · Eine Fläche die an den Rändern an das Fußwegnetz angebunden ist,
 eignet sich bei Seitenbahnsteigen (Beispiel, ….)
auch das sollte kein Problem sein zu nutzen.
 
 · Gesplittete Flächen, notwendig bei Mittelbahnsteigen (Gleise an
 beiden Seiten) mit Zugang aus Tunnels oder von Brücken (Beispiel München
 Ost)
Falsch:
Wieso sollte das Splitten notwendig sein?
Die Plattform ist die von den Gleisen (z.B.) 2 und 3. Die linke Seite
bietet den Zustieg zu Gleis 2, die rechte zu Gleis 3. Es bleibt aber
erstmal trotzdem ein Bahnsteig.
Wieso man diesen horizontal aufsplitten muss, verstehe ich nicht.

Wenn ich zu GLEIS (!) 2 route (da fährt der Zug ab), dann route ich (so
machen das bei Adressen auch alle gängigen Router) zum nächsten Punkt,
der erreichbar ist.
Das ist in diesem Fall der Bahnsteig 2/3, und da die linke Seite. Wo ist
das Problem? Warum muss dafür der Bahnsteig gesplittet werden? und vor
allem: Warum in den Rohdaten?

 Keine der drei Modellierungsarten ist unsere Erfindung, statt der
 gesplitteten Flächen können man auch mit Flächen mit Löchern arbeiten
 (Multipolygonen), das ist aber noch komplizierter und das haben wir noch
 nirgends gesehen.
Ich find auch kein Beispiel; logisch wäre es aber meines Erachtens
schon, und es würde mit Multipolygonen auf ein etabliertes OSM-Schema
zurückgreifen, ohne dass neue Erfindungen mit falschen Daten gemacht
werden müssten.
 
 Das Splitten der Bahnsteige in 2 oder mehr Teile hat den Vorteil, dass man
  in der Mitte Aussparungen lassen kann. In diesen Aussparungen können dann
 Treppen, Rolltreppen oder Aufzüge münden, die meist aus dem Fußgängertunnel
 kommen. Damit wir wissen, welche Teile zu einer Plattform gehören fassen
 wir diese Teile in einer Relation zusammen.
Also trennt ihr erst um dann wieder per Relation zu verbinden...
Selbst wenn ihr trennen müsstet (was ich bezweifle), wäre die Relation
unnötig, denn die lässt sich einfach aus der Geometrie herleiten (die
beiden Bahnsteige sind miteinander verbunden über eine gemeinsame Kante).

Meine Empfehlung (darf gerne von anderen noch kommentiert werden) wäre:
Eine Plattform ist eine Plattform und kein Gleis. Eine Plattform gehört
z.B. zu zwei, manchmal auch zu drei oder mehr Gleisen, und das ist
erstmal gar kein Problem.

Ein Gleis ist ein Gleis und hat eine Nummer. Wenn ein Zug auf Gleis 2

Re: [Talk-de] Einführung eines neuen Tags (globaleID)

2013-07-23 Diskussionsfäden Tobias Knerr

Hallo,

da habt ihr euch ja einiges vorgenommen. Leider stoßt ihr bei einigen
Sachen in Bereiche vor, wo sich die OSM-Community noch nicht wirklich
einig ist.

Ich bin mir nicht sicher, wie man da am besten zu einer Klärung kommt.
Aber versuchen wir es erst mal mit ein paar konkreten Hinweisen auf
dieser Liste:

Am 23.07.2013 11:40, schrieb Tracy Kasperczyk:
 Objekt: Rolltreppe (Type: way)
[...]
  Aus dem Wiki: http://wiki.openstreetmap.org/wiki/Escalator

Es gibt ein alternatives Proposal, das im Gegensatz zu dem von euch
verwendeten approved ist. Es beseitigt auch ein paar Probleme bei der
Angabe der Richtung, die fürs Routing ja evtl. auch relevant ist:
http://wiki.osm.org/Proposed_features/Escalators_and_Moving_Walkways

 Objekt: Tunnel (Type: Fläche)
 
  - area = yes
[...]
 - building = yes (es handelt sich um ein Indoor-Elment und soll in der
 Karte angezeigt werden)

Einen Tunnel als building = yes zu kennzeichnen halte ich für sehr
ungewöhnlich und sicher keine etablierte Praxis.

Ich würde eher zu area:highway = footway für diese Fläche raten (unter
Annahme, dass der bestehende Way für den Tunnel als highway = footway
erfasst ist). Der Schlüssel area:highway ist zwar bisher nur ein
Vorschlag, aber das hat vor allem damit zu tun, dass Flächenerfassung
von Straßen und Wegen bei uns generell noch in den Kinderschuhen steckt.

Gruß,
Tobias

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Einführung eines neuen Tags (globaleID)

2013-07-23 Diskussionsfäden Gerhard Hermanns


Hi,

zunächst einmal: Ich finde es großartig, dass sich da etwas zu 
entwickeln scheint (ein Hoch auf den VRR  :-)  )


Ich habe den Thread nur überflogen. Falls das Folgende also schon 
erwähnt wurde oder nicht passt, einfach ignorieren ...


Ich möchte hier kurz einen Querverweis machen auf einen aktuellen Thread 
im OSM-Forum, wo es um ein paar Ideen bzgl. des ÖPNV-Schemas geht [1]. 
Der User Weide hat hier eine Vorversion [2] zu etwas erarbeitet, was mal 
ein Proposal zu einem überarbeiteten public_transport-Schema werden könnte.


Die meisten der Punkte betreffen ÖPNV-Routen, aber es gibt auch 
Ideen/Ergänzungen z.B. zu platform. Möglicherweise gibt es hier 
zumindest an einigen Punkten Synergien? Es wäre schade, wenn diese 
beiden Arbeiten parallel existieren würden ohne voneinander Notiz zu 
nehmen ...



Grüße
Gerhard (Seoman)

[1] http://forum.openstreetmap.org/viewtopic.php?pid=349000#p349000
[2] http://wiki.openstreetmap.org/wiki/User:Weide


Am 23.07.2013 11:40, schrieb Tracy Kasperczyk:

Liebe OSM Gemeinde,

Wir wollen euch noch mal genauer erklären was wir machen.



Der VRR (Verkehrsverbund Rhein-Ruhr) auch tätig als zentraler Koordinator
für das Land Nordrhein Westfalen beabsichtigt als Kartenbasis in Zukunft
auf OSM zu setzen. Das betrifft folgende Produkte

· Die Karten, die Verkehrslinienpläne, die den Fahrplanbüchern
beiliegen und die an den Haltestellen aushängen sollen  aus den OSM Daten
errechnet und im VRR Layout dargestellt werden.

· Die Haltestellenumgebungspläne, die von einigen Betrieben
erstellt und ausgehängt werden, z.B. von der Rheinbahn in Düsseldorf sollen
aus OSM Daten erzeugt werden.

· Die interaktiven Karten die sie z.B. in efa.vrr.de sehen sollen
aus  OSM Daten berechnet werden

· Die interaktiven Karten der VRR App, dieselben wie die aus
efa.vrr.de sollen aus OSM berechnet werden (die Apps wurden schon ca.
1.000.000  mal heruntergeladen)

· Die Fahrten der Verkehrsmittel sollen referenziert mit OSM Daten
(dabei werden die Koordinaten der Fahrwege übernommen) auf diese Karten
gezeichnet werden (siehe auchefa.vrr.de und die Apps)

· Die Fußwege zu den Haltepunkten und bis zum Gleis der
Schienenverkehre sollen auf OSM Daten geroutet werden

· Die Apps sollen Fußwegnavigation auf den OSM Daten unter stützen

· Das Fußwegrouting  soll barrierefreie Wege suchen können (wird
weiter unter erklärt)



Für die Entscheidung des VRR waren Kostengründe maßgebend, aber vor allem
auch der Qualität und der Detailreichtum der OSM Daten hat den VRR
begeistert. Gerade in der Welt des Öffentlichen Verkehrs und des Fuß- und
Radverkehrs gibt es keine vergleichbaren GIS Daten. Gerade beim
Fußweg-Routing versprechen wir uns wesentlich Verbesserungen, da die OSM
Daten weit mehr Fuß- und Radwege und Straßenquerungen enthalten als andere
Datenmaterialien.



Das Datenmaterial, das wir in OSM vorfinden hat vor allem bezüglich der
Wege (Straßen und Schienenwege) aus ausgezeichnete Qualität.

  Einige Daten sind allerdings noch unvollständig für unsere
Aufgabenstellung und diese wollen wir nacherfassen, gerne auch gemeinsam
mit der OSM Gemeinde.



Ein Bereich der Nacherfassung umfasst die Busspuren und die Abbiegeverbote
oder Abbiegeerlaubnisse von Bussen. Wir haben Kontakt zu allen
Verkehrsbetrieben, wir können die Informationen von dort bekommen und
nachpflegen.



Der zweite Bereich umfasst die Bahnhöfe und die Haltestellen der
Schienenverkehre (Straßenbahn, U-Bahn). Es ist das Ziel einen Fußweg bis
von einem beliebigen Punkt im Wegenetz bis zum Bahnsteig und dem Haltepunkt
des Fahrzeugs zu berechnen, anzuzeigen und Navigation auf diesem Weg zu
ermöglichen. Dieser Weg soll auch barrierefrei sein. Was bedeutet das?



Gehen wir von drei typischen Benutzern aus:



Nutzer 1 ist Student, Pendler und in Turnschuhen unterwegs. Er kommt immer
knapp vor der Zugabfahrt. Er geht schnellen Schrittes durch den Bahnhof und
nimmt die Treppen hinauf zum Bahnsteig, damit er nirgends warten muss.



Nutzer 2 ist der Reisende mit Koffer, oder die/der Frau/Mann mit
Kinderwagen. Der Nutzer kann nur mit großer Mühe die Treppen nutzen und
sucht Wege über Rolltreppen zum Bahnsteig.



Nutzer 3 kommt im Rollstuhl. Er ist auf Aufzüge und Rampen angewiesen um
zum Bahnsteig zu kommen, er braucht entsprechende Wege.



Das Ziel im Bahnhof ist also der Bahnsteig und der Punkt, wo man in die
Bahn einsteigen kann. (Solange wir die Reihung der Züge nicht kennen oder
deren Haltepositionen rechnen wir mit einem Punkt).



Bahnsteige, wir nennen sie Plattformen, sind für Menschen mit
Mobilitätseinschrängungenzugänglich oder nicht, weil sie einen Aufzug haben
oder nicht. Es gibt Bahnhöfe, da sind nur einige Plattformen oder nur eine
für Menschen mit Mobilitätseinschrängungen zugänglich. Auch auf der
Plattform kann es mehrere Zugänge geben, oft einen mit Aufzug und
Rolltreppe und andere mit fester Treppe (Beispiel Düsseldorf Hbf).

Wir brauchen also alle

Re: [Talk-de] Einführung eines neuen Tags (globaleID)

2013-07-23 Diskussionsfäden fly

Am 23.07.2013 13:27, schrieb Peter Wendorff:
 Hallo Tracy,
 
 Am 23.07.2013 11:40, schrieb Tracy Kasperczyk:
 Liebe OSM Gemeinde,

 Wir wollen euch noch mal genauer erklären was wir machen.
 Das ist super ;)
 [...]
 
  Einige Daten sind allerdings noch unvollständig für unsere
 Aufgabenstellung und diese wollen wir nacherfassen, gerne auch gemeinsam
 mit der OSM Gemeinde.
 Das klingt gut.
 
 Ein Bereich der Nacherfassung umfasst die Busspuren und die Abbiegeverbote
 oder Abbiegeerlaubnisse von Bussen. Wir haben Kontakt zu allen
 Verkehrsbetrieben, wir können die Informationen von dort bekommen und
 nachpflegen.
 Das klingt gut - aber nach Import, deshalb bitte die Import-Richtlinien
 berücksichtigen, wenn ihr nicht jede Haltestelle selbst kontrolliert dabei.
 Eine Alternative ist oft, die Daten öffentlich und für die Nutzung
 freigegeben zu hinterlegen, damit man verteilt die Haltestellen anhand
 dessen überprüfen kann.
 
 [...]

 Das Ziel im Bahnhof ist also der Bahnsteig und der Punkt, wo man in die
 Bahn einsteigen kann. (Solange wir die Reihung der Züge nicht kennen oder
 deren Haltepositionen rechnen wir mit einem Punkt).

 Bahnsteige, wir nennen sie Plattformen, sind für Menschen mit
 Mobilitätseinschrängungenzugänglich oder nicht, weil sie einen Aufzug haben
 oder nicht. Es gibt Bahnhöfe, da sind nur einige Plattformen oder nur eine
 für Menschen mit Mobilitätseinschrängungen zugänglich. Auch auf der
 Plattform kann es mehrere Zugänge geben, oft einen mit Aufzug und
 Rolltreppe und andere mit fester Treppe (Beispiel Düsseldorf Hbf).

 Wir brauchen also alle Plattformen einzeln und alle Wegelemente im Bahnhof,
 ebene Wege, Treppen, Rolltreppen, Rampen und Aufzüge. Diese Wegelemente
 müssen „ways“ sein, sonst kann man nicht darüber routen.
 Fast richtig.
 Ein Aufzug muss nicht zwingend ein way sein, um darauf route zu können.
 Beispiel:
 .x-'
 .x und ' seien Nodes,  und  jeweils dazwiscchen ways.
 x sei ein Aufzug und als solcher getagged (auf einem Node.
  trägt außerdem level=0, x trägt level=1 (was jeweils das Stockwerk
 angibt).
 Das Routing mit Berücksichtigung des Aufzugs ist hier problemlos möglich.
 
 Ebene Wege, Treppen, Rolltreppen und Rampen sind üblicherweise ways in
 OSM, Aufzüge aber nicht, weil sie kaum eine horizontale Ausdehnung
 haben. Technisch ist das aber kein Problem auch im Routing zu
 berücksichtigen.
 
 Wir haben in den existierenden OSM Daten unterschiedliche Modellierungen
 von Plattformen gefunden:

 · Einen „way“ der an das Fußwegenetz angebunden ist, eignet sich
 bei schmalen Bahnsteigen (Beispiel Stuttgart, Stadtbahnhaltestelle Berliner
 Platz/Hohe Straße)
 stimmt, und sollte für euch kein Problem darstellen.

 · Eine Fläche die an den Rändern an das Fußwegnetz angebunden ist,
 eignet sich bei Seitenbahnsteigen (Beispiel, ….)
 auch das sollte kein Problem sein zu nutzen.

 · Gesplittete Flächen, notwendig bei Mittelbahnsteigen (Gleise an
 beiden Seiten) mit Zugang aus Tunnels oder von Brücken (Beispiel München
 Ost)
 Falsch:
 Wieso sollte das Splitten notwendig sein?
 Die Plattform ist die von den Gleisen (z.B.) 2 und 3. Die linke Seite
 bietet den Zustieg zu Gleis 2, die rechte zu Gleis 3. Es bleibt aber
 erstmal trotzdem ein Bahnsteig.
 Wieso man diesen horizontal aufsplitten muss, verstehe ich nicht.
 
 Wenn ich zu GLEIS (!) 2 route (da fährt der Zug ab), dann route ich (so
 machen das bei Adressen auch alle gängigen Router) zum nächsten Punkt,
 der erreichbar ist.
 Das ist in diesem Fall der Bahnsteig 2/3, und da die linke Seite. Wo ist
 das Problem? Warum muss dafür der Bahnsteig gesplittet werden? und vor
 allem: Warum in den Rohdaten?
 
 Keine der drei Modellierungsarten ist unsere Erfindung, statt der
 gesplitteten Flächen können man auch mit Flächen mit Löchern arbeiten
 (Multipolygonen), das ist aber noch komplizierter und das haben wir noch
 nirgends gesehen.
 Ich find auch kein Beispiel; logisch wäre es aber meines Erachtens
 schon, und es würde mit Multipolygonen auf ein etabliertes OSM-Schema
 zurückgreifen, ohne dass neue Erfindungen mit falschen Daten gemacht
 werden müssten.

 Das Splitten der Bahnsteige in 2 oder mehr Teile hat den Vorteil, dass man
  in der Mitte Aussparungen lassen kann. In diesen Aussparungen können dann
 Treppen, Rolltreppen oder Aufzüge münden, die meist aus dem Fußgängertunnel
 kommen. Damit wir wissen, welche Teile zu einer Plattform gehören fassen
 wir diese Teile in einer Relation zusammen.
 Also trennt ihr erst um dann wieder per Relation zu verbinden...
 Selbst wenn ihr trennen müsstet (was ich bezweifle), wäre die Relation
 unnötig, denn die lässt sich einfach aus der Geometrie herleiten (die
 beiden Bahnsteige sind miteinander verbunden über eine gemeinsame Kante).
 
 Meine Empfehlung (darf gerne von anderen noch kommentiert werden) wäre:
 Eine Plattform ist eine Plattform und kein Gleis. Eine Plattform gehört
 z.B. zu zwei, manchmal auch zu drei oder mehr Gleisen, und das ist

Re: [Talk-de] Einführung eines neuen Tags (globaleID)

2013-07-23 Diskussionsfäden Andreas Neumann

On 07/23/2013 11:40 AM, Tracy Kasperczyk wrote:
 Liebe OSM Gemeinde,

 Wir wollen euch noch mal genauer erklären was wir machen.

 [...]

 Objekt: Aufzug (Type: way)

 - highway = elevator

 - level = -1,0

   Aus dem Wiki: http://wiki.openstreetmap.org/wiki/Elevator

 Tags die schon vorhanden sind werden nicht von uns gelöscht.
Sollte man den Elevator nicht evtl. als Node taggen? Die meisten gehen
kerzegerade nach oben, was auf einer 2d-karte schlecht darstellbar ist.
Die Option way würde ich beibehalten, da es ein paar Fahrstühle gibt,
die schrägen Hochfahren (was aber wohl die Ausnahme sein dürfte)

 Gebäude mit weiteren Flächen:

 Objekt: Tunnel (Type: Fläche)

  - area = yes

 - tunnel = yes

 - level = ...

 - layer = ...

 - building = yes (es handelt sich um ein Indoor-Elment und soll in der
 Karte angezeigt werden)

 - designation = Unterführung

 Es werden die Fußwege auf den Tunnelflächen ebenfalls, erstellt bzw. wenn
 diese schon vorhanden sind, dann werden diese nicht gelöscht bzw. verändert.
Wie bereits  von einigen angesprochen, handelt es sich bei Tunneln nicht
wirklich um Gebäude (ansonsten müssten wir auch jede Brücke und jede
Straße als solches kennzeichnen, was ziemlich unübersichtlich wird.
Besser wäre es highway=footway zu nehmen. Sollte es sich wirklich um
eine Unterführung handeln, dann mit tunnel=yes. Bei Unterführungen, die
abgeschlossen sind und wie ein innerer Bahnhof wirken, wie im neuen
Erfurter Hauptbahnhof, wäre wohl eher indoor=yes angebracht. Aber
darüber kann man streiten.

in meiner Gegend hat sich ziemlich herauskristalisiert, dass man zwar
Flächen von Verkehrsflächen angeben kann, aber immer zusätzlich einen
Way in der Mitte zeichnet, der das Routing ermöglicht. Ansonsten können
die meisten Router nur am Rand der Fläche Routen. Sprich, wenn ihr einen
Tunnel als Area einzeichnet, dann legt in der Mitte noch einen Way an.
Und ganz wichtig. Verbindet den Way auch zu den (Roll-)Treppen und
Aufzügen!

Alternativ zu den Flächen könnte man auch überlegen dem Tunnelway ein
Attribut mitzugeben, dass aussagt, wie breit der Tunnel ist, oder ihr
erfindet, ähnlich dem Flussufer, ein Polygonattribut für
Verkehrsflächenumrandungen.

Bitte gebt immer an, ob Radfahren in den Unterführungen erlaubt ist oder
nicht! Dann könnte man Radfahrer evtl. an den nächsten mit Rad
zugänglichen Zugangspunkt am Bahnhof leiten, ohne ihn durch den ganzen
Bahnhof zu jagen

 [...]

just my 2 cents,
Andreas

-- 
Andreas Neumann
http://stadtplan-ilmenau.de




signature.asc
Description: OpenPGP digital signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Einführung eines neuen Tags (globaleID)

2013-07-23 Diskussionsfäden Dirk Sohler

Tracy Kasperczyk schrieb:
 · Gesplittete Flächen, notwendig bei Mittelbahnsteigen

Nein. Notwendig für EURE Daten, aber generell nicht notwendig, und auch
nicht erwünscht.

Grüße,
Dirk

-- 
Local time :: Ortszeit :: DE-HH
2013-07-23T19:56:12+0200


signature.asc
Description: PGP signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Einführung eines neuen Tags (globaleID) - bitte sofort stoppen

2013-07-23 Diskussionsfäden Michael Kugelmann


Am 22.07.2013 07:16, schrieb Wilhelm Spickermann:

Wenn mein Name oben drüber steht und dann nur Text kommt, der nicht
von mir ist, dann ist das irreführend.
Sorry, ich hatte das Verrutschen um eine Einzug übersehen. Ich 
entschuldige mich dafür.


Aber: Stephan hatte das Ganze sehr allgemein zitiert und auf den ganzen 
Thread Bezug genommen = etwas mehr Gelassenheit würde der ganzen 
Diskussion gut tun...



Grüße,
Michael.


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Einführung eines neuen Tags (globaleID)

2013-07-23 Diskussionsfäden Michael Kugelmann


Am 23.07.2013 11:40, schrieb Tracy Kasperczyk:

Tunnel sind oft schon in den Daten vorhanden. Die sind für uns als
Wegelemente sehr hilfreich. Allerdings wollen wir auch Karten für den
Untergrund zeichnen, wenn sehr breite Tunnels nur als Strich daherkommen
ist das irreführend. Wir brauchen also zusätzlich Flächen.

-1, absolut dagegen.
Wir malen keine Karten mit einem Malprogramm sondern wir erfassen 
die Topologie! Da was schon immer so und sollte auch so bleiben. Wenn, 
dann gebt z.B. für einen Weg eine Breite mittels width == xxx an.



Wir sind schon seit einiger Zeit mit der
Münchner OSM Gruppe in Kontakt und haben viel gelernt.

:-)


Grüße,
Michael.


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Einführung eines neuen Tags (globaleID)

2013-07-23 Diskussionsfäden Martin Koppenhöfer



Am 24.07.2013 um 00:39 schrieb Michael Kugelmann michaelk_...@gmx.de:

 -1, absolut dagegen.
 Wir malen keine Karten mit einem Malprogramm sondern wir erfassen die 
 Topologie! Da was schon immer so und sollte auch so bleiben. Wenn, dann gebt 
 z.B. für einen Weg eine Breite mittels width == xxx 


Wir erfassen ja nicht nur einen Graphen, auch wenn der ziemlich nützlich ist. 
M.E. Ist der Wunsch legitim, auch unterirdische Plätze und Verkehrsräume von 
öffentlichen Gebäuden mit ihren Grenzen aufzunehmen und nicht nur als linearen 
Graph, mit einem Malprogramm sollte man das nicht verwechseln, allerdings ist 
mit derzeitiger Editor-Technik mehr als ein Stockwerk übereinander eigentlich 
nicht effizient bearbeitbar oder verständlich, von daher ist der Einwand auch 
nicht völlig unberechtigt.

Gruß,
Martin


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Einführung eines neuen Tags (globaleID)

2013-07-23 Diskussionsfäden Tirkon

Zunächst einmal an die Community. Im Allgemeinen wünschen wir Quellen
für Importe. Bezogen auf die geografischen Einordnung ist dies aber in
diesem Falle möglicherweise schwierig, wenn diese Daten überhaupt erst
mit Hilfe von OSM Werkzeugen erstmals im geografischen Umfeld erfasst
werden. Wir haben hier möglicherweise eine bisher nie oder kaum
dagewesene Situation, dass OSM die Erstveröffentlichungsquelle ist und
damit eine andere Quelle nicht zur Verfügung steht. Dann müssten wir
uns im Rahmen dieses Imports überlegen, wie die für Importe notwendige
Zusicherung, diese Daten unter der OSM Lizenz veröffentlichen zu
dürfen, bewirkt werden kann. Ich denke, hier sollten wir unsere
Data-Working-Group mit ihren entsprechenden Erfahrungen mit größeren
Importen um Mithilfe bitten.

Tracy Kasperczyk kasperc...@mentzdv.de wrote:

Liebe OSM Gemeinde,

Wir wollen euch noch mal genauer erklären was wir machen.
Sehr gut. :-)

Der VRR (Verkehrsverbund Rhein-Ruhr) auch tätig als zentraler Koordinator
für das Land Nordrhein Westfalen beabsichtigt als Kartenbasis in Zukunft
auf OSM zu setzen. Das betrifft folgende Produkte

Wenn der VRR der zentrale Koordinator für NRW ist, dürfte ihm nicht
entgangen sein, dass Marcel Hövelmann vom Verkehrsverbund Rhein Sieg
sowie Thomas Reincke vom Aachener Verkehrverbund aus ähnlichen
Beweggründen wie ihr, schon Jahre eine gedeihliche Zusammenarbeit mit
OSM pflegen. Ist Euch das bekannt?

Hier der Vortrag der beiden auf unserer D-A-CH Konferenz namens
FOSSGIS 2011:
http://ftp5.gwdg.de/pub/misc/openstreetmap/FOSSGIS2011/FOSSGIS2011-191-de-oepnv_vrs_aav.webm
Hier die neueste OSM Anwendung des VRS, die übrigens immer weiter in
den Bereich des VRR, insbesondere der Rheinbahn hineinreicht. Zum
Beispiel findet man dort den U-Bahnhof Heinrich-Heine-Allee in
Düsseldorf:
http://www.vrsinfo.de/fahrplan/haltestellen-und-linieninformationen.html

Von daher wäre es vielleicht nicht das Schlechteste, mit den beiden
Herren Kontakt aufzunehmen. Sie sind daneben auch OSM-Community
erfahren.

· Die Karten, die Verkehrslinienpläne, die den Fahrplanbüchern
beiliegen und die an den Haltestellen aushängen sollen aus den OSM Daten
errechnet und im VRR Layout dargestellt werden.

· Die Haltestellenumgebungspläne, die von einigen Betrieben
erstellt und ausgehängt werden, z.B. von der Rheinbahn in Düsseldorf sollen
aus OSM Daten erzeugt werden.

Zur Info für die Community: So sehen die Umgebungspläne der Rheinbahn
heute aus, die im Wesentlichen nur für die inneren Stadtteile
Düsseldorfs existieren:
http://www.rheinbahn.de/fahrplan/karten/Seiten/haltestellen.aspx
In den peripheren Stadtteilen Düsseldorfs und in fast allen
umliegenden Städten kann der Fahrgast nicht auf solche Pläne
zurückgreifen. Selbst die Umsteigepunkte mit vielen Linien sind in
deren Plänen derzeit nur durch einen gemeinsamen Punkt gekennzeichnet.

· Die interaktiven Karten die sie z.B. in efa.vrr.de sehen sollen
aus OSM Daten berechnet werden

· Die interaktiven Karten der VRR App, dieselben wie die aus
efa.vrr.de sollen aus OSM berechnet werden (die Apps wurden schon ca.
1.000.000 mal heruntergeladen)

· Die Fahrten der Verkehrsmittel sollen referenziert mit OSM Daten
(dabei werden die Koordinaten der Fahrwege übernommen) auf diese Karten
gezeichnet werden (siehe auchefa.vrr.de und die Apps)

· Die Fußwege zu den Haltepunkten und bis zum Gleis der
Schienenverkehre sollen auf OSM Daten geroutet werden

· Die Apps sollen Fußwegnavigation auf den OSM Daten unter stützen

· Das Fußwegrouting soll barrierefreie Wege suchen können (wird
weiter unter erklärt)

Für die Entscheidung des VRR waren Kostengründe maßgebend, aber vor allem
auch der Qualität und der Detailreichtum der OSM Daten hat den VRR
begeistert. Gerade in der Welt des Öffentlichen Verkehrs und des Fuß- und
Radverkehrs gibt es keine vergleichbaren GIS Daten. Gerade beim
Fußweg-Routing versprechen wir uns wesentlich Verbesserungen, da die OSM
Daten weit mehr Fuß- und Radwege und Straßenquerungen enthalten als andere
Datenmaterialien.

Sehr gut. Ich bin sicher, dass sehr viele in der Community genau dafür
mappen, dass ihre Daten entsprechend nützlich werden können -
insbesondere was die in anderen Karten nicht zu findende
Detailliertheit an Fuß- und Radwegen angeht.

Weitere Datenelemente die wir brauchen, sind die oben erwähnten Haltepunkte
auf den Schienen oder die Haltepunkte der Busse vor dem Bahnhof. Dies
Punkte brauchen wir um einen Weg auf die Karte zeichnen zu können. Dort ist
Anfang oder Ende des Wegs im Fahrzeug und der Übergang auf den Fußweg. Das
sind bekannte OSM Objekte (
http://wiki.openstreetmap.org/wiki/Tag:public_transport%3Dstop_position)

Insbesondere bei den Bussen ist mir nicht klar, wozu ihr die
stop_position braucht. Ein Bus hält etwa am Haltestellenschild bzw. an
der Mitte der Plattform (public_transport=platform) auf seiner in OSM
enthaltenen Route. Warum fällt ihr nicht einfach das Lot

Re: [Talk-de] Einführung eines neuen Tags (globaleID)

2013-07-23 Diskussionsfäden Tirkon

Michael Kugelmann michaelk_...@gmx.de wrote:

Allerdings wollen wir auch Karten für den
 Untergrund zeichnen, wenn sehr breite Tunnels nur als Strich daherkommen
 ist das irreführend. Wir brauchen also zusätzlich Flächen.
-1, absolut dagegen.
Wir malen keine Karten mit einem Malprogramm sondern wir erfassen 
die Topologie! Da was schon immer so und sollte auch so bleiben. 

Hmm
http://wiki.openstreetmap.org/wiki/Tag:waterway%3Driver
aber auch
http://wiki.openstreetmap.org/wiki/Tag:waterway%3Driverbank

Machen wir damit nicht das Eine, ohne das Andere zu lassen?

Wenn, 
dann gebt z.B. für einen Weg eine Breite mittels width == xxx an.
Ginge auch.


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Einführung eines neuen Tags (globaleID)

2013-07-23 Diskussionsfäden Thomas Reincke


Am 23.07.2013 11:40, schrieb Tracy Kasperczyk:

· Die Fahrten der Verkehrsmittel sollen referenziert mit OSM Daten
(dabei werden die Koordinaten der Fahrwege übernommen) auf diese Karten
gezeichnet werden (siehe auchefa.vrr.de und die Apps)


als Overlay oder als Verknüfung zu den OSM-Daten?

Ich Route die Linienwege auf der OSM-Karte. Die dabei entstehenden 
Fahrwege sind jedoch von OSM unabhängig. Eine Verknüpfung findet nicht 
statt.


Wenn ein neuer Kreisverkehr eingerichtet wird oder der Straßenverlauf 
verfeinert wird, bekomme ich das nicht mit. Das wird im Rahmen der 
regelmäßigen Durcharbeitung des Bestandes korrigiert - oder eben auch 
nicht. bei einer technischen Lösung sähe ich einen erheblichen 
Mehraufwand bei einem nur marginalen Mehrnutzen.


Extrem wird es bei den Eisenbahnen, wo inzwischen an vielen Stellen 
jedes Gleis eingezeichnet ist. Eigentlich müsste man dann wirklich den 
genauen Fahrweg über jede Weiche prüfen und darstellen. Diesen Aufwand 
treibe ich nicht.



· Die Fußwege zu den Haltepunkten und bis zum Gleis der
Schienenverkehre sollen auf OSM Daten geroutet werden

· Die Apps sollen Fußwegnavigation auf den OSM Daten unter stützen

· Das Fußwegrouting  soll barrierefreie Wege suchen können (wird
weiter unter erklärt)


Dazu brauche ich m.E. keine Integration der ÖV-Daten in OSM. Wenn es 
ungefähr zueinander passt, reicht das völlig aus.



Für die Entscheidung des VRR waren Kostengründe maßgebend, aber vor allem
auch der Qualität und der Detailreichtum der OSM Daten hat den VRR
begeistert. Gerade in der Welt des Öffentlichen Verkehrs und des Fuß- und
Radverkehrs gibt es keine vergleichbaren GIS Daten. Gerade beim
Fußweg-Routing versprechen wir uns wesentlich Verbesserungen, da die OSM
Daten weit mehr Fuß- und Radwege und Straßenquerungen enthalten als andere
Datenmaterialien.


Diese Gründe waren für uns vor über drei Jahren ebenfalls ausschlaggebend.


Ein Bereich der Nacherfassung umfasst die Busspuren und die Abbiegeverbote
oder Abbiegeerlaubnisse von Bussen. Wir haben Kontakt zu allen
Verkehrsbetrieben, wir können die Informationen von dort bekommen und
nachpflegen.


Schön, aber wozu? Ich würde mir den Linienverlauf als Layer besorgen und 
mit OSM abgleichen, ob er dort fahrbar ist. Busspuren müssen dort rein, 
wo sie baulich eine eigene Fahrbahn sind. Das wird wahrscheinlich fast 
überall der Fall sein.



Der zweite Bereich umfasst die Bahnhöfe und die Haltestellen der
Schienenverkehre (Straßenbahn, U-Bahn). Es ist das Ziel einen Fußweg bis
von einem beliebigen Punkt im Wegenetz bis zum Bahnsteig und dem Haltepunkt
des Fahrzeugs zu berechnen, anzuzeigen und Navigation auf diesem Weg zu
ermöglichen. Dieser Weg soll auch barrierefrei sein. Was bedeutet das?


Ist das so sinnvoll? Wichtig sind die Ausgänge einer U-Bahn-Station. Die 
müssen innerhlb des Haltestellenmodells erfasst sein. Die Wege innerhalb 
des Bauwerks wird festgelegt und durch eine Zeit sowie ggf. die Arten 
der Einschränkungen in der Nutzbarkeit festgelegt.


Die Zeiten hängen von der zurückgelegten Strecke, der Zahl der Stufen 
sowie ggf. technischen Parametern, wie Warte- und Fahrzeit eines 
Aufzuges ab.



Wir brauchen also alle Plattformen einzeln und alle Wegelemente im Bahnhof,
ebene Wege, Treppen, Rolltreppen, Rampen und Aufzüge. Diese Wegelemente
müssen „ways“ sein, sonst kann man nicht darüber routen.


Einmalig, bei der Erstellung. Aber nicht on the Fly bei jeder 
Verbindungsabfrage.



Der VRR macht sich die Entscheidung, auf OSM zu setzen nicht leicht. Man
ist immer noch besorgt, dass Daten, die in die Produktion der
Fahrplanunterlagen und Karten gehen sich kurzfristig unkontrolliert ändern.
Wir bitte deshalb auch die OSM-Gemeinde hier Vorsicht walten zu lassen. Man
kann immer mit uns Kontakt aufnehmen.


Deshalb die eigenen Daten von den Kartendaten trennen.


Es ist nicht nur so das der VRR in Zukunft auf OSM umstellen möchte, es
werden sondern noch weitere Verkehrsverbünde und Betriebe diesem Beispiel
folgen.


Der VRR ist nicht der erste Verbund der das macht...


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Einführung eines neuen Tags (globaleID)

2013-07-23 Diskussionsfäden Dirk Sohler

Thomas Reincke schrieb:
  Wir brauchen also alle Plattformen einzeln und alle Wegelemente im
  Bahnhof, ebene Wege, Treppen, Rolltreppen, Rampen und Aufzüge.
  Diese Wegelemente müssen „ways“ sein, sonst kann man nicht darüber
  routen.
 
 Einmalig, bei der Erstellung. Aber nicht on the Fly bei jeder 
 Verbindungsabfrage.

Vor allem wird hier wieder „wir“ durch „man“ ersetzt, denn „man“ kann
sehr wohl darüber routen.

Dass das geht, zeigen diverse Routingprogramme, die ohne Probleme über
Treppen und Aufzüge routen können.


  Der VRR macht sich die Entscheidung, auf OSM zu setzen nicht
  leicht. Man ist immer noch besorgt, dass Daten, die in die
  Produktion der Fahrplanunterlagen und Karten gehen sich kurzfristig
  unkontrolliert ändern. Wir bitte deshalb auch die OSM-Gemeinde hier
  Vorsicht walten zu lassen. Man kann immer mit uns Kontakt aufnehmen.
 
 Deshalb die eigenen Daten von den Kartendaten trennen.

Das sage ich denen schon seit der ersten Mail :)

Spezialdaten als eigenen Layer bereitstellen, und dort, wo es gewünscht
ist, eben mit den Daten aus OSM zusammenfügen, und ausliefern. Das ist
ja auch wesentlich stressfreier, da nicht unnötig Bahnhöfe gespalten,
oder Aufzüge als Weg gemappt werden müssen.


Grüße,
Dirk

-- 
Local time :: Ortszeit :: DE-HH
2013-07-24T07:31:50+0200


signature.asc
Description: PGP signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Einführung eines neuen Tags (globaleID)

2013-07-22 Diskussionsfäden fly

Am 18.07.2013 16:28, schrieb Martin Koppenhoefer:
 Am 18. Juli 2013 16:23 schrieb Wilhelm Spickermann o...@spickermann-d.de:

 Ich sehe zur Zeit eine ziemliche Aktivität unter mehreren
 Benutzernamen, bei der Bahnsteige der Länge nach gespalten werden.
 Darüber müsste man erstmal diskutieren,

Hat sich das denn jetzt aufgeklärt oder geht das weiter ?

 wenn da keine bauliche Trennung da ist, dann sollte die Diskussion
 eigentlich schon gleich wieder zu Ende sein...

Zumindest eine Diskussion hier im Vorraus hätte ich schon erwartet.

cu
fly


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Einführung eines neuen Tags (globaleID)

2013-07-22 Diskussionsfäden Wilhelm Spickermann

Am Mon, 22 Jul 2013 16:43:25 +0200
schrieb fly lowfligh...@googlemail.com:

  Am 18. Juli 2013 16:23 schrieb Wilhelm Spickermann
  o...@spickermann-d.de: 
  Ich sehe zur Zeit eine ziemliche Aktivität unter mehreren
  Benutzernamen, bei der Bahnsteige der Länge nach gespalten werden.
  Darüber müsste man erstmal diskutieren,  
 
 Hat sich das denn jetzt aufgeklärt oder geht das weiter ?

Ich dachte, es hätte aufgehört, aber gerade kam die Änderungsmeldung
zum Bahnhof Düsseldorf Flughafen rein. 
- die Bahnsteige wurden gesplittet. Darüber kann man streiten.
- je zwei Hälften wurden zu stop_areas zusammengefasst. Das ist falsch.
- der Name der Haltestelle Düsseldorf Flughafen wurde durch
  Bahnsteig n ersetzt. Ist falsch, steht aber so im Wiki.
- Die einzige bisher von mir geprüfte Zuglinie hält jetzt an zwei
  Bahnsteighälften. Das ist falsch.

Aber vielleicht kommt ja noch eine Änderung.

Wilhelm

PS: Ich habe zwei von den Leuten am Anfang (vor der ersten Mail hier)
geholfen, das Splitting bzw. das Neuanlegen von Bahnsteigen richtig
zu machen (obwohl ich eigentlich nichts vom Splitting halte). In einem
Fall war das ziemlich viel Arbeit. Die Dialoge hatten eine angenehme
Atmosphäre -- keiner hat aber was von dem Vorhaben verlauten lassen.

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Einführung eines neuen Tags (globaleID)

2013-07-22 Diskussionsfäden Tirkon

Wilhelm Spickermann o...@spickermann-d.de wrote:

  Ich sehe zur Zeit eine ziemliche Aktivität unter mehreren
  Benutzernamen, bei der Bahnsteige der Länge nach gespalten werden.
  Darüber müsste man erstmal diskutieren,  
 
 Hat sich das denn jetzt aufgeklärt oder geht das weiter ?

Ich dachte, es hätte aufgehört, aber gerade kam die Änderungsmeldung
zum Bahnhof Düsseldorf Flughafen rein. 
- die Bahnsteige wurden gesplittet. Darüber kann man streiten.
- je zwei Hälften wurden zu stop_areas zusammengefasst. Das ist falsch.
- der Name der Haltestelle Düsseldorf Flughafen wurde durch
  Bahnsteig n ersetzt. Ist falsch, steht aber so im Wiki.
- Die einzige bisher von mir geprüfte Zuglinie hält jetzt an zwei
  Bahnsteighälften. Das ist falsch.

Aber vielleicht kommt ja noch eine Änderung.

Nachdem wir hier kürzlich die Diskussion hatten, dass durch
Doppelstreifen getrennte Richtungsfahrbahnen auf autobahnähnlichen
Straßen wegen fehlender baulicher Trennung nicht zu einer Trennung auf
OSM führen sollen, ist ein Splitten von Bahnsteighälften noch weniger
berechtigt. Dort existiert im Unterschied zu den Straßen in der
Realität weder eine Trennungslinie noch eine verbotene Zone noch ein
Übergangsverbot.


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Einführung eines neuen Tags (globaleID)

2013-07-21 Diskussionsfäden Tirkon

Thomas Reincke m...@thomas-reincke.de wrote:

On 11.07.2013 19:18, Toni Erdmann wrote:
 Meine Frage zielt auf:

 public_transport = stop_position
 public_transport = platform

 Haben die zusammen eine oder jeder seine eigene IFOPT-Nummern?

DE:5334:1001 ist die Nummer der Gesamthaltestelle, auch STOP genannt. 
Das passt etwas zu public_transport = stop_area

DE:5334:1001:1 ist die Nummer des Umsteigebereichs, auch AREA genannt. 
Das ist meist eine Zusammenfassung von Objekten mit ähnlichen 
Umsteigeeigenschaften. Achtung, es gibt auch bereichlsoe Haltestellen, 
dann wäre die Nummer DE:5334:1001:0.

DE:5334:1001:1:1 ist die Nummer des in EFA Steig genannten Objekt. Bei 
mir ist das der physikalische Mast. Englisch POINT.
Das passt zu einem punktförmigen public_transport = platform

Zu public_transport = stop_position gibt es m. E. nichts äquivalentes. 
Ich setze die stop_position meist auf das Lot des Mastes auf die Fahrbahn.

Das wäre dann ja inkompatibel zu dem Vorschlag von Tracy Kasperczyk

Zitat von Tracy Kasperczyk:
Für die Plattformen in OSM: de:Landkreisnr:lokale
Haltstellennummer:PlattformNr

Für die Stop_Position in OSM: de:Landkreisnr:lokale
Haltstellennummer:PlattformNr:SteigCode


Bei Dir (also beim Aachener Verkehrsverbund) entspricht Steig der
public_transport=platform, 
bei Tracy Kasperczyk entspricht Steig der
public_transport=stop_position.

Bei Dir ist die PlattformNr ungenutzt,
bei Tracy Kasperczyk entspricht die PlattformNr dem
public_transport=platform.

Du verwendest das Lot von Steig für public_transport=stop_position.
Die PlattformNr erfährt man bei Dir nicht.
 

Das geht ja überhaupt nicht zusammen, oder? Eine Anwendung kann doch
nicht zwischen dem Aachener Verkehrsverbund und beispielsweise dem
Nachbar Verkehrsverbund Rhein-Ruhr unterschiedlich interpretieren.
Denn einmal müsste sie beispielsweise den Steigcode vom
public_transport=platform-node/way und das andere Mal vom
public_transport=stop_position-node holen. 

Vom public_transport=platform-node/way erhält man einmal den Steigcode
und das andere Mal die PlattformNr.

Vom public_transport=stop_position-node erhält man einmal nichts und
das andere Mal den Steigcode.


Zitat von Tracy Kasperczyk:
Wir nehmen die Anregung von Stephan Wolff auf und ändern den Namen in
ref_ifopt

Benutzt Du auch ref_ifopt ?

Wenn diese Nummern bei OSM benutzt werden, wäre es doch sinnvoll, wenn
diese auch OSM-einheitlich verwendet werden.


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Einführung eines neuen Tags (globaleID) - bitte sofort stoppen

2013-07-21 Diskussionsfäden Michael Kugelmann


Am 19.07.2013 19:49, schrieb Wilhelm Spickermann:

Würdest Du bitte weniger irreführend zitieren?

Was ist bitte daran irreführend zitiert? Nichts!


Grüße,
Michael.


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Einführung eines neuen Tags (globaleID)

2013-07-21 Diskussionsfäden Michael Kugelmann


Am 18.07.2013 19:42, schrieb Dirk Sohler:

Man, man, man, müssen wir denen jetzt auch noch hinterherrennen, und
die von ihnen eingebauten, ihren Zwecken dienlichen, Fehler in OSM
wieder korrigieren?
Jetzt bleib bitte auf dem Teppich! Konstruktiv arbeiten und nicht nur 
rumjammern.


Um mal etwas allgemeiner zur Diskussion zu schreiben:
dIe Leute waren mehrfach auf dem Stammtisch in München um Kontakt mit 
der Community aufzunehmen und um Rat zu fragen. Also Vorwürfe von wegen 
die machen alles kaputt und das dient nur einem kommerziellen 
Interesse etc. sind sehr an den Haaren herbeigezogen: die wollen 
wirklich zusammen mit der OSM-Community etwas sinnvolles machen und 
nicht dagegen. (BTW: ich finde das ähnlich zu ein paar anderen 
aktuellen  weltfremde Diskussionen!). Und dass ein kommerzielles 
Unternehmen Community erst lernen muss ist verständlich. Insbesondere 
denke ich, dass die OSM-Community teilweise noch etwas spezieller ist, 
als manche andere FLOS-Community. Für mich ist es nicht verwunderlich, 
dass dabei an der Schnittstelle durch unglückliche Aktionen unnötige 
Reibereien entstehen. Ich kann nur zur Mäßigung - insbesondere 
innerhalb  der Community - aufrufen.
Gleich noch dazu gesagt: die Triebfeder für die mögliche Nutzung der 
OSM-Daten kommt nicht nur aus der Firma (sondern z.B. den 
Verkehsverbünden). Und an statt dass sich die Community freut, dass mit 
den OSM-Roh-/Vektor-DATEN etwas sinnvolles gemacht werden soll wird (von 
einigen) nur rumgejammert: ohhh, der Nachbar hat an meiner schönen 
Sandburg etwas verändert und dazu mein Förmchen benutzt. Denkt doch mal 
bitte nach: bis jetzt werden die OSM-Daten vor allem als 
schnöde/primitive Karte genutzt. Hier bietet sich die Chance, dass die 
OSM-Daten im großen Stil als Roh-/Vektor-Daten verwendet werden. Und 
dabei werden noch die Daten verbessert, was wollt ihr denn mehr...
Noch etwas: das Ganze ist ja von Europa getrieben (EU-Kommision oder 
EU-Rat oder so) = ihr könnt Euch als in Brüssel beschwerden...


Ach ja: gleich noch ein Mantra mit aufzunehmen: wir mappen nicht für die 
Karte. Wenn der Renderer etwas falsch darstellt, dann hat der Renderer 
angepasst zu werden und nicht die Daten schlecht gemacht zu werden dass 
es gut aussieht. Daran erinnern mich auch ein paar Diskussionen...



Grüße,
Michael.


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Einführung eines neuen Tags (globaleID) - bitte sofort stoppen

2013-07-21 Diskussionsfäden Wilhelm Spickermann

Am Mon, 22 Jul 2013 02:19:11 +0200
schrieb Michael Kugelmann michaelk_...@gmx.de:

 Am 19.07.2013 19:49, schrieb Wilhelm Spickermann:
  Würdest Du bitte weniger irreführend zitieren?
 Was ist bitte daran irreführend zitiert? Nichts!

Wenn mein Name oben drüber steht und dann nur Text kommt, der nicht
von mir ist, dann ist das irreführend. 

Wilhelm

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Einführung eines neuen Tags (globaleID)

2013-07-19 Diskussionsfäden Peter Wendorff

Wäre es nicht eigentlich am sinnvollsten, zumindest zusätzlich am Gleis
die Nummer mit anzugeben?
Dann gäbe es
1) Bahnsteig 2/3 für den Bahnsteig zwischen den Gleisen 2 und 3, und
2) Gleis 2 sowie Gleis 3 (bin nicht so im ÖPNV-Mapping drin, evtl. auch
nur auf der stop-position am Gleis)

Wer dann zum Gleis zwei Routen will oder dessen Bahnsteig braucht, der
macht das genauso wie er zu einer Adresse routet, die ja auch neben der
Straße liegt - das sollte eigentlich nicht so ein großes Problem sein.

Gruß
Peter

Am 18.07.2013 22:25, schrieb Thomas Reincke:
 Am 18.07.2013 22:10, schrieb Wilhelm Spickermann:
 Genug der Haarspalterei: Ein Streit darum, ob man Bahnsteige spalten
 kann oder nicht ist nicht übermäßig wichtig. Problematisch wäre es nur,
 ein System einzuführen, das nur mit gespaltenen Bahnsteigen
 funktioniert, denn niemand hat diese Angelegenheiten bisher entschieden.
 
 Der Bahnsteig ist ein Bauwerk. An dem Bahnsteig liegen meist zwei
 Gleise. Die dem Kunden gegenüber kommunizierte Bezeichnung ist meist die
 Nummer des Gleises. An einem Bahnsteig liegen z.B. die Gleise 2 und 3.
 
 
 ___
 Talk-de mailing list
 Talk-de@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-de
 


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Einführung eines neuen Tags (globaleID)

2013-07-19 Diskussionsfäden Henning Scholland


Am 18.07.2013 21:41, schrieb Wilhelm Spickermann:

Bedenken hätte ich -- wenn es denn tatsächlich so sein sollte -- wenn
die Datenstrukturen der Firma solche Trennungen zwingend machen, weil
das Konzept auf eine Gleisnummer pro Bahnsteig beschränkt ist und das
jetzt einfach ohne Abstimmung durchgezogen würde.
Wobei das dann nicht das Problem von OSM ist, sondern das Problem von 
der Firma. ;)


Henning


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Einführung eines neuen Tags (globaleID) - bitte sofort stoppen

2013-07-19 Diskussionsfäden Wilhelm Spickermann

Am Fri, 19 Jul 2013 19:24:42 +0200
schrieb Stephan Knauss o...@stephans-server.de:

 Stephan Wolff writes:
  Am 19.07.2013 17:01, schrieb Wilhelm Spickermann:  
 [...]
 
  Könnte ein Berechtigter diesen User temporär sperren, um weitere
  Schäden zu verhindern?  
 
 Diese ganze Diskussion ist ja erbärmlich.

Würdest Du bitte weniger irreführend zitieren?

Danke 
Wilhelm

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Einführung eines neuen Tags (globaleID)

Hi,

Am Thu, 11 Jul 2013 12:21:45 +0200
schrieb Tracy Kasperczyk kasperc...@mentzdv.de:

 Tracy (taoxue)
 
 i.A. Mentz Datenverabeitung GmbH

Ich sehe zur Zeit eine ziemliche Aktivität unter mehreren
Benutzernamen, bei der Bahnsteige der Länge nach gespalten werden.
Darüber müsste man erstmal diskutieren, denn eigentlich ist es ein
Bahnsteig an dem zwei Gleise liegen. Vermutlich soll eine eindeutige
Zuordnung von Gleis und Bahnsteig erreicht werden. Häufig wird dabei
aber nicht einmal Name und Ref ebenfalls angepasst, was die Frage nach
der Motivation aufkommen lässt. Seid Ihr das und ist das ein Versuch,
OSM dem Datenmodell anzupassen?

MfG
Wilhelm

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Einführung eines neuen Tags (globaleID)

2013-07-18 Diskussionsfäden Martin Koppenhoefer

Am 18. Juli 2013 16:23 schrieb Wilhelm Spickermann o...@spickermann-d.de:

 Ich sehe zur Zeit eine ziemliche Aktivität unter mehreren
 Benutzernamen, bei der Bahnsteige der Länge nach gespalten werden.
 Darüber müsste man erstmal diskutieren,



wenn da keine bauliche Trennung da ist, dann sollte die Diskussion
eigentlich schon gleich wieder zu Ende sein...

Gruß Martin
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Einführung eines neuen Tags (globaleID)

2013-07-18 Diskussionsfäden Dirk Sohler

Martin Koppenhoefer schrieb:
 Am 18. Juli 2013 16:23 schrieb Wilhelm Spickermann
 o...@spickermann-d.de:
  Ich sehe zur Zeit eine ziemliche Aktivität unter mehreren
  Benutzernamen, bei der Bahnsteige der Länge nach gespalten werden.
  Darüber müsste man erstmal diskutieren,
 
 wenn da keine bauliche Trennung da ist, dann sollte die Diskussion
 eigentlich schon gleich wieder zu Ende sein...

Man, man, man, müssen wir denen jetzt auch noch hinterherrennen, und
die von ihnen eingebauten, ihren Zwecken dienlichen, Fehler in OSM
wieder korrigieren?

-- 
Local time :: Ortszeit :: DE-HH
2013-07-18T19:41:25+0200


signature.asc
Description: PGP signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Einführung eines neuen Tags (globaleID)

Am Thu, 18 Jul 2013 19:42:36 +0200
schrieb Dirk Sohler s...@0x7be.de:

 ... müssen wir denen ...


Langsam, wir wissen noch garnichts. Ich hab absichtlich nur gefragt.

Wilhelm

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Einführung eines neuen Tags (globaleID)

2013-07-18 Diskussionsfäden Stephan Knauss


On 18.07.2013 16:28, Martin Koppenhoefer wrote:

wenn da keine bauliche Trennung da ist, dann sollte die Diskussion
eigentlich schon gleich wieder zu Ende sein...


keine Ahnung was da gemacht wurde und wie sinnhaft das ist.

Aber in OSM werden wege immer dann gespaltet wenn die verschiedenen 
Segmente unterschiedliche Tags brauchen.


Kleine Analogie: Ein Tempolimit auf der Autobahn. Da ist keine bauliche 
Trennung auf der Straße, sondern es gelten einfach ab einem Punkt andere 
Limits.


Mit Bushaltestellen habe ich es definitiv schon gesehen dass an einem 
langen Bahnsteig zwei verschiedene Linien gehalten haben. Eine vorne und 
eine Hinten.
Tram Hauptbahnhof, Bus Studentenstadt. Bei genauerem Überlegen ist das 
sogar ziemlich häufig.


Was sagt denn das Tagging dazu?

Stephan



___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Einführung eines neuen Tags (globaleID)

2013-07-18 Diskussionsfäden Henning Scholland


Am 18.07.2013 16:23, schrieb Wilhelm Spickermann:

Hi,

Am Thu, 11 Jul 2013 12:21:45 +0200
schrieb Tracy Kasperczyk kasperc...@mentzdv.de:


Tracy (taoxue)

i.A. Mentz Datenverabeitung GmbH

Ich sehe zur Zeit eine ziemliche Aktivität unter mehreren
Benutzernamen, bei der Bahnsteige der Länge nach gespalten werden.
Darüber müsste man erstmal diskutieren, denn eigentlich ist es ein
Bahnsteig an dem zwei Gleise liegen. Vermutlich soll eine eindeutige
Zuordnung von Gleis und Bahnsteig erreicht werden. Häufig wird dabei
aber nicht einmal Name und Ref ebenfalls angepasst, was die Frage nach
der Motivation aufkommen lässt. Seid Ihr das und ist das ein Versuch,
OSM dem Datenmodell anzupassen?
Ich bin jetzt nicht der ÖPNV-Mapper und habe mich daher auch nicht näher 
mit den aufgekommenden Schemata befasst. Wenn ich mich aber an die 
alten Zeiten zurück erinnere, dann war es durchaus zumindest in meiner 
Region nicht unüblich, die Bahnsteige zu trennen. Wie gesagt, wenn es in 
einem der Schemata verboten wurde, mag es problematisch sein, 
ansonsten sehe ich kein Problem darin, die Bahnsteige zu trennen. In der 
Regel könnte man bei den ganzen Schildern, Sitzgelegenheiten etc. auch 
von einer baulichen Trennung zwischen den Bahnsteigen sprechen.


Henning


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Einführung eines neuen Tags (globaleID)

2013-07-18 Diskussionsfäden Martin Koppenhoefer

Am 18. Juli 2013 19:42 schrieb Dirk Sohler s...@0x7be.de:

 Man, man, man, müssen wir denen jetzt auch noch hinterherrennen, und
 die von ihnen eingebauten, ihren Zwecken dienlichen, Fehler in OSM
 wieder korrigieren?



ich finde es nicht hilfreich, in Kategorien von wir und denen zu
denken, schlussendlich arbeiten wir alle gemeinsam an einer großen Sache
und müssen halt sehen, wie wir unterschiedliche Sichtweisen und Prioritäten
unter einen Hut bekommen. Solche genormten Bezugspunkte, für die man
potentiell in der Zukunft Fahrplandaten, Echtzeitinformationen zum ÖPNV
oder was auch immer bekommen kann, sind grundsätzlich willkommen, denke ich.

Gruß Martin
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Einführung eines neuen Tags (globaleID)

Hi,

Am Thu, 18 Jul 2013 20:30:01 +0200
schrieb Henning Scholland o...@aighes.de:

 Ich bin jetzt nicht der ÖPNV-Mapper und habe mich daher auch nicht
 näher mit den aufgekommenden Schemata befasst. Wenn ich mich aber an
 die alten Zeiten zurück erinnere, dann war es durchaus zumindest in
 meiner Region nicht unüblich, die Bahnsteige zu trennen. Wie gesagt,
 wenn es in einem der Schemata verboten wurde, mag es problematisch
 sein, ansonsten sehe ich kein Problem darin, die Bahnsteige zu
 trennen.

Es ist in keinem verboten und es ist in keinem auch nur problematisch.

 In der Regel könnte man bei den ganzen Schildern,
 Sitzgelegenheiten etc. auch von einer baulichen Trennung zwischen den
 Bahnsteigen sprechen.

Ja, das stört mich auch nicht so sehr. Die dabei gemachten Fehler
und die nicht ausreichende Pflege der betroffenen Relationen sind viel
störender.

Bedenken hätte ich -- wenn es denn tatsächlich so sein sollte -- wenn
die Datenstrukturen der Firma solche Trennungen zwingend machen, weil
das Konzept auf eine Gleisnummer pro Bahnsteig beschränkt ist und das
jetzt einfach ohne Abstimmung durchgezogen würde.

Noch mehr Bedenken hätte ich -- wenn das alles denn tatsächlich so sein
sollte -- wenn Detaillierung ohne die nötigen Arbeiten vor Ort gemacht
würde. Wenn man aus einer einfachen Linie mit einem Knoten als Bahnhof
mehrere Gleise mit mehreren Bahnsteigen macht, dann muss man auch
ermitteln, an welchem dieser Bahnsteige welche bereits vorhandene Linie
hält. Mann kann sie nicht einfach alle an Bahnsteig 1 halten lassen.
(Das ist nicht erfunden sondern passiert, aber es könnten auch alles
Zufälle sein)

MfG
Wilhelm

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Einführung eines neuen Tags (globaleID)

2013-07-11 Diskussionsfäden qunuxy-osmmailingli...@yahoo.com

Am Thu, 18 Jul 2013 20:23:28 +0200
schrieb Stephan Knauss o...@stephans-server.de:

 Mit Bushaltestellen habe ich es definitiv schon gesehen dass an einem 
 langen Bahnsteig zwei verschiedene Linien gehalten haben. Eine vorne
 und eine Hinten.
 Tram Hauptbahnhof, Bus Studentenstadt. Bei genauerem Überlegen ist
 das sogar ziemlich häufig.

Ja. Nur ist Bussteig 5 der Name eines Bussteigs und es ist völlig
normal, dass zwei Bussteige an einer Straße hintereinander liegen.
Gleis 5 ist dagegen der Name eines Gleises und nicht der Name des
Bahnsteigs. Der Bahnsteig wird dann -- nach den da liegenden Gleisen --
meist Bahnsteig 3,4 (Langfassung: Bahnsteig an Gleis 3 und 4) genannt.

Genug der Haarspalterei: Ein Streit darum, ob man Bahnsteige spalten
kann oder nicht ist nicht übermäßig wichtig. Problematisch wäre es nur,
ein System einzuführen, das nur mit gespaltenen Bahnsteigen
funktioniert, denn niemand hat diese Angelegenheiten bisher entschieden.

MfG
Wilhelm

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Einführung eines neuen Tags (globaleID)

2013-07-18 Diskussionsfäden Thomas Reincke


Am 18.07.2013 22:10, schrieb Wilhelm Spickermann:

Genug der Haarspalterei: Ein Streit darum, ob man Bahnsteige spalten
kann oder nicht ist nicht übermäßig wichtig. Problematisch wäre es nur,
ein System einzuführen, das nur mit gespaltenen Bahnsteigen
funktioniert, denn niemand hat diese Angelegenheiten bisher entschieden.


Der Bahnsteig ist ein Bauwerk. An dem Bahnsteig liegen meist zwei 
Gleise. Die dem Kunden gegenüber kommunizierte Bezeichnung ist meist die 
Nummer des Gleises. An einem Bahnsteig liegen z.B. die Gleise 2 und 3.



___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Einführung eines neuen Tags (globaleID)

2013-07-18 Diskussionsfäden Dirk Sohler

Martin Koppenhoefer schrieb:
 ich finde es nicht hilfreich, in Kategorien von wir und denen zu
 denken

Ich auch nicht, aber „wir“ haben damit ja auch nicht angefangen …


 Solche genormten Bezugspunkte, für die man potentiell in der Zukunft
 Fahrplandaten, Echtzeitinformationen zum ÖPNV oder was auch immer
 bekommen kann, sind grundsätzlich willkommen, denke ich.

Natürlich. Jedoch ist die Einführung ist alles andere als unglücklich
gelaufen, und es scheint so, als wenn „die“ jetzt auch schon anfangen,
den Datenstand an „ihre“ Bedürfnisse anzupassen – Und dabei ist noch
nicht mal klar, ob der kryptische, nichtssagende Tagname, genommen
werden sollte, oder eine sinnvolle andere Bezeichnung, oder was genau
jetzt alles erfasst werden soll (Stichwort: Redundanz).


Grüße,
Dirk

-- 
Local time :: Ortszeit :: DE-HH
2013-07-19T01:28:39+0200


signature.asc
Description: PGP signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Einführung eines neuen Tags (globaleID)

2013-07-15 Diskussionsfäden Andreas Neumann

On 07/11/2013 09:54 PM, Henning Scholland wrote:
 Hallo
 Für mich klingt das nach jeder Menge Redundanz. Wenn DE:5334:1001 nur
 aussagt Ich bin die Haltestelle Busbahnhof Aachen, dann steckt diese
 Info doch bereits in unseren Daten. Dann braucht es doch keine
 zusätzliche Ref, die genau das gleiche nochmal sagt. Ebenso die
 weitere Unterscheidung. Dafür gibt es ja die pt-Relationen und ihre
 Member.

 Henning

Doch, diese Redundanz braucht es. Hin und wieder gibt es offizielle
Haltestellennamen sowohl für eine Bushaltestelle, als auch für einen
Bahnhof/Zughaltepunkt. Nehme ich nur den Namen ohne das Verkehrsmittel
zu kennen, habe ich zwei Ergebnisse.

Viele behelfen sich damit eindeutige Pre- oder Postfixe anzuhängen, was
aber leider auch den Namen verfälscht. Eine ID dagegen, ist eindeutig
und ich kann sie evtl. mit anderen Datenbanken verknüpfen. Somit wäre
der Erfurter Hauptbahnhof auch mit einer Datenbank verknüpfbar, inder er
nur als Erfurt Hbf hinterlegt ist.

MfG Andreas

-- 
Andreas Neumann
http://stadtplan-ilmenau.de




signature.asc
Description: OpenPGP digital signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Einführung eines neuen Tags (globaleID)

2013-07-15 Diskussionsfäden Wolfgang Hinsch

Am Montag, den 15.07.2013, 16:18 +0200 schrieb Andreas Neumann:
 On 07/11/2013 09:54 PM, Henning Scholland wrote:
  Hallo
  Für mich klingt das nach jeder Menge Redundanz. Wenn DE:5334:1001 nur
  aussagt Ich bin die Haltestelle Busbahnhof Aachen, dann steckt diese
  Info doch bereits in unseren Daten. Dann braucht es doch keine
  zusätzliche Ref, die genau das gleiche nochmal sagt. Ebenso die
  weitere Unterscheidung. Dafür gibt es ja die pt-Relationen und ihre
  Member.
 
  Henning
 
 Doch, diese Redundanz braucht es. Hin und wieder gibt es offizielle
 Haltestellennamen sowohl für eine Bushaltestelle, als auch für einen
 Bahnhof/Zughaltepunkt. Nehme ich nur den Namen ohne das Verkehrsmittel
 zu kennen, habe ich zwei Ergebnisse.
 
 Viele behelfen sich damit eindeutige Pre- oder Postfixe anzuhängen, was
 aber leider auch den Namen verfälscht. Eine ID dagegen, ist eindeutig
 und ich kann sie evtl. mit anderen Datenbanken verknüpfen. Somit wäre
 der Erfurter Hauptbahnhof auch mit einer Datenbank verknüpfbar, inder er
 nur als Erfurt Hbf hinterlegt ist.

Man könnte es vermeiden, indem eine Tabelle 

DE:5334:1001= Hauptbahnhof Erfurt
DE:5334:1001:01 = Hauptbahnhof Erfurt Gleis 1

auf einer Seite bereitgestellt wird. Wer eine Verknüpfung braucht, lädt
sich diese Tabelle in seine Datenbank und greift über diesen Umweg auf
die Daten zu. Dann kann er über die ID zugreifen, ohne dass sie in der
OSM-DB auftaucht.

Gruß, Wolfgang




___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Einführung eines neuen Tags (globaleID)

Ich finde einige Antworten auch ziemlich wenig einladend formuliert.

Hoffentlich hat das keine zu große abschreckende Wirkung.
Die Idee finde ich nämlich sehr gut.
Der Namensraum sollte angepasst und eine Nachvollziehbarkeit für andere Mapper 
sollte gegeben sein.
Es sollte aber klar sein, dass es bei OSM keine IDs mit Veränderungsschutz gibt.

Aber mit einer guten Dokumentation im Wiki und einer regelmäßigen Überprüfung 
(evtl. halb automatisch), ob die IDs noch vorhanden und richtig positioniert 
sind, sollte das kein großes Problem sein.



- Ursprüngliche Message -
Von: Toni Erdmann toni.erdm...@web.de
An: talk-de@openstreetmap.org
CC: 
Gesendet: 21:42 Mittwoch, 10.Juli 2013
Betreff: Re: [Talk-de]
 Einführung eines neuen Tags  (globaleID)

On 07/10/2013 05:26 PM, Stephan Knauss wrote:
 Dirk Sohler writes:

 Alles sehr „fishy“ … Vor allem, da sich das entsprechende Unternehmen
 nun so gar nicht mehr aktiv an der Diskussion beteiligt.

 Die Antworten waren auch in vielen Fällen alles andere als freundlich,
 einladend, konstruktiv.

Sorry, dass ich erst jetzt die Zeit finde mich zu melden.

Ich hatte am 17. Juni ein etwa 2-stündiges Gespräch in den Büros von
Mentz DV. Vorausgegangen war ein E-Mail-Verkehr aufgrund einer
Änderung am Münchener Ostbahnhof.

Das Gespräch mit Tracy und ihren Kollegen war sehr freundlich, entspannt
und konstruktiv. Meine Bitte war dabei, dass sie sich wegen weiterer
Absprachen / Vorschlägen an diese Liste wenden sollten.

Bei einigen Antworten habe ich mich dann allerdings über die Heftigkeit
gewundert.

Was neue Tags und die unabhängige Überprüfbarkeit durch Dritte angeht,
bin ich auch der Meinung, dass die Quellen offen sein müssen. Und zwar
so, dass ein beliebiger Mapper bei fehlerhafte oder verschwundene Tags
Reparaturen anhand einer Liste vornehmen kann. Optimal wäre ein
regelmäßiger Update der Liste(n).

Bei den Namen plädiere auch ich eher für generische Namen mit
Namensräumen, wie z.B. von Jochen Topf vorgeschlagen

public_transport:ifopt:stop_id

wobei ich das ifopt ganz ans Ende stellen würde:
- vom Allgemeinen public_transport
- über das spezifischere stop_id(oder so)
- zum spezifisch zu verwendenden Standard ifopt für die
   Analyse, Syntax und Semantik der Wertes.

Toni (ToniE)



___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

[Talk-de] Einführung eines neuen Tags (globaleID)

2013-07-11 Diskussionsfäden Tracy Kasperczyk

Hallo liebe OSM-Gemeinde,

mit dieser Mail wollen wir uns bei Ihnen allen melden. Wir müssen intern
erst ein paar Sachen klären, bevor wir eine Stellungnahme zu Ihren vielen
E-Mail nehmen können. Wir bedanken uns aber schon einmal sehr dafür, daß
Sie uns so zahlreich geantwortet haben.

Hiermit unsere vorläufige Stellungnahme zu diesem Thema:

** **Zunächst eine Ergänzung unserer Beschreibung:

 Wir nehmen die Anregung von Stephan Wolff auf und ändern den Namen in
ref_ifopt

Die IFOPT Nummer (globale ID)  gibt es für alle Haltestellenobjekte,
speziell auch für alle Haltepunkte der Busse und Straßenbahnen. Das ist
dann so was wie ein eindeutiges Nummernschild in den Ländern, die mitmachen.


 Wir bemühen uns um eine Veröffentlichung aller Nummern in den Portalen der
verantwortlichen Ländern. Allerdings sind noch nicht alle Nummern
endgültig. Vor allem in den Überschneidungsbereichen der Verbünde, z.B. VRR
und VRS fällt noch Arbeit an. Es gibt europaweit eine Open Data Initiative
die diese Daten öffentlich zugänglich machen will.


Einige  Verkehrsverbünde bieten kostenfreie öffentliche Schnittstellen zum
Abruf von Fahrplaninformationen an. Die IFOPT Nummer kann in diesem
Zusammenhang als eindeutiges Anfragekriterium genutzt werden, um
beispielsweise alle Abfahrten eines Haltepunktes, unabhängig vom
Verkehrsmittel abzurufen. Wie klären zur Zeit parallel mit den einzelnen
Verbünden die Möglichkeiten des Zugriffs auf diese Schnittstellen und
würden das Verfahren ebenfalls in diesem Rahmen bekannt geben.




Mit freundlichen Grüße

Tracy (taoxue)

i.A. Mentz Datenverabeitung GmbH
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Einführung eines neuen Tags (globaleID)

2013-07-11 Diskussionsfäden Martin Koppenhoefer

Am 11. Juli 2013 12:21 schrieb Tracy Kasperczyk kasperc...@mentzdv.de:

 Hallo liebe OSM-Gemeinde,

 mit dieser Mail wollen wir uns bei Ihnen allen melden. Wir müssen intern
 erst ein paar Sachen klären, bevor wir eine Stellungnahme zu Ihren vielen
 E-Mail nehmen können.



Ich hätte nochmal kurz eine Frage zum Detailgrad, gem. Wikipedia [1] sind
mit der ifopt-Nummer nicht nur Bahnhöfe normiert sondern auch deren
Eingänge, Bahnsteige, Räume, Ausstattung und Einrichtungen, etc.

Wie genau werden die Daten sein, die importiert werden sollen?

Gruß Martin



[1]
http://en.wikipedia.org/wiki/Identification_of_Fixed_Objects_in_Public_Transport
...provides a *Reference Data Model* for describing the main fixed objects
required for public access to Public
transporthttp://en.wikipedia.org/wiki/Public_transport,
that is to say Transportation
hubshttp://en.wikipedia.org/wiki/Transportation_hub such
as airports http://en.wikipedia.org/wiki/Airport,
stationshttp://en.wikipedia.org/wiki/Train_station
, bus stops http://en.wikipedia.org/wiki/Bus_stop,
portshttp://en.wikipedia.org/wiki/Port,
and other destination places and points of interest, as well as their
entrances, platforms, concourses, internal spaces, equipment, facilities,
accessibility etc.).
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Einführung eines neuen Tags (globaleID)

2013-07-11 Diskussionsfäden mail


Zitat von Martin Koppenhoefer dieterdre...@gmail.com:


Am 11. Juli 2013 12:21 schrieb Tracy Kasperczyk kasperc...@mentzdv.de:
Ich hätte nochmal kurz eine Frage zum Detailgrad, gem. Wikipedia [1] sind
mit der ifopt-Nummer nicht nur Bahnhöfe normiert sondern auch deren
Eingänge, Bahnsteige, Räume, Ausstattung und Einrichtungen, etc.

Wie genau werden die Daten sein, die importiert werden sollen?


Das hängt sehr stark von dem ab, der die Daten pflegt.

Ich pflege die Masten. Aachen Bushof, Bussteig H.1 hat beispielsweise  
die IFOPT-Nummer DE:5334:1001:1:1.


Dort wo erforderlich (bei uns nur Bahnhöfe), habe ich auch Zugänge  
erfasst, die werden auch eine IFOPT-Nummer erhalten.


Thomas



___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Einführung eines neuen Tags (globaleID)

2013-07-11 Diskussionsfäden Stefan Keller

Hallo Tracy

Mit grossem Interesse verfolge ich diese Diskussion, denn ich
beschäftige mich seit einiger Zeit mit dem Thema, wie man externe
Datenbanken mit OSM verknüpfen kann.

Am 11. Juli 2013 12:21 schrieb Tracy Kasperczyk kasperc...@mentzdv.de:
 ...
 Hiermit unsere vorläufige Stellungnahme zu diesem Thema:

 ** **Zunächst eine Ergänzung unserer Beschreibung:

  Wir nehmen die Anregung von Stephan Wolff auf und ändern den Namen in
 ref_ifopt

 Die IFOPT Nummer (globale ID)  gibt es für alle Haltestellenobjekte,
 speziell auch für alle Haltepunkte der Busse und Straßenbahnen. Das ist
 dann so was wie ein eindeutiges Nummernschild in den Ländern, die mitmachen.
 

Das was ihr mit dem IFOPT in OSM vorhabt, ist analog TCM und
entspricht der Variante 2, die ich hier zunächst für mich dokumentiert
habe: [1].

Ich meine, wenn schon eine solche Projekt-Spezial-ID, dann würde ich
einen sinnigen Tag-Namen verwenden, wie ihn Jochen
(public_transport:ifopt:stop_id) vorschlug.

Und in jedem Falle würde ich es bei diesem Projekt-Spezial-Tag
belassen und keine weiteren Tags vorsehen (die sind ja über die ID mit
der externen DB verknüpft).

Konsequenter wäre aber m.E. ganz ohne Projekt-Spezial-ID auszukommen,
in dem die OSM-ID oder eine noch zu findende
permanente/stabile/globale OSM IDs verwendet wird, auf die sich die
externe Datenbank bezieht (= vgl. Variante 4 [1]). Am 22.07.12 gab es
eine Diskussion über solche Permanente/stabile OSM IDs!. Ich schlug
dort eine einzige zusätzliche ID-Tag pro OSM-Objekt vor. Dort war
eines der (berechtigten) Einwände, dass die interne OSM-ID instabil
sei und sowohl bei dieser als auch bei Projekt-Spezial-IDs die
OSM-Daten aufgebläht würden.

Was mir an IFOPT jedenfalls nicht gefällt, ist die Codierung durch
sprechende Schlüssel (die ändern können!).

Ich frage mich daher, ob nicht der Vorschlag von Wolfgang Hinsch vom
10. Juli 2013 17:04 am besten wäre  (public_transport:stop_position)
- vgl. unten. So ein Tag könnte auch ausserhalb den an IFOPT
angeschlossenen Bahnhöfen (d.h. weltweit) verwendet werden.

LG, Stefan

[1] http://giswiki.hsr.ch/OpenStreetMap_und_externe_Datenbanken#Variante_2

LG, Stefan


Am 10. Juli 2013 17:04 schrieb Wolfgang Hinsch osm-lis...@ivkasogis.de:
 ...
 Also, wenn ich das richtig verstanden habe, werden damit Positionen auf
 dem Gleis und auf dem Bahnsteig am Gleis markiert. Wie das in
 irgendeiner Spezial-DB heißt, kann uns doch völlig schnuppe sein. Besser
 wäre ein Klartext wie:

 public_transport:stop_position=Gleis3_Nord';
 public_transport:stop_position=Gleis3_Mitte';
 public_transport:stop_position=Gleis3_Sued';

 oder ost/west, wenn der Bahnhof anders rum liegt.

 Falls eine Position reicht (an vielen Bahnsteigen werden mehrere Züge
 hintereinander bereitgestellt), einfach nur 'Gleis3'.

 Dann wird im Wiki erklärt, was das heißen soll, eine Vorlage dazu, damit
 die Rechtschreibung stimmt, ein Style für josm, damit es angezeigt wird
 und gut ist. Dann weiß jeder, was gemeint ist und kann das auch
 reparieren.

 Das Bundesland und der Bahnhofsname sollte sich eindeutig aus der Lage
 ergeben.

 Die Bahnsteigpositionen analog. Eingänge auch (Eingang_Nord,
 Eingang_Nord-Ost oder so). Aus einer separaten Tabelle geht dann hervor,
 welche ID damit gemeint ist, das muss nicht in OSM stehen.

 Zusätzlich hat man damit den Vorteil, dass sofort auffällt, wenn in den
 Daten etwas fehlt, weil dann für IDs die OSM-Position nicht gefunden
 wird.

 Vielleicht übersehe ich etwas, aber eigentlich könnte das so einfach
 sein.

 Gruß, Wolfgang


Am 11. Juli 2013 12:21 schrieb Tracy Kasperczyk kasperc...@mentzdv.de:
 Hallo liebe OSM-Gemeinde,

 mit dieser Mail wollen wir uns bei Ihnen allen melden. Wir müssen intern
 erst ein paar Sachen klären, bevor wir eine Stellungnahme zu Ihren vielen
 E-Mail nehmen können. Wir bedanken uns aber schon einmal sehr dafür, daß
 Sie uns so zahlreich geantwortet haben.

 Hiermit unsere vorläufige Stellungnahme zu diesem Thema:

 ** **Zunächst eine Ergänzung unserer Beschreibung:

  Wir nehmen die Anregung von Stephan Wolff auf und ändern den Namen in
 ref_ifopt

 Die IFOPT Nummer (globale ID)  gibt es für alle Haltestellenobjekte,
 speziell auch für alle Haltepunkte der Busse und Straßenbahnen. Das ist
 dann so was wie ein eindeutiges Nummernschild in den Ländern, die mitmachen.
 

  Wir bemühen uns um eine Veröffentlichung aller Nummern in den Portalen der
 verantwortlichen Ländern. Allerdings sind noch nicht alle Nummern
 endgültig. Vor allem in den Überschneidungsbereichen der Verbünde, z.B. VRR
 und VRS fällt noch Arbeit an. Es gibt europaweit eine Open Data Initiative
 die diese Daten öffentlich zugänglich machen will.


 Einige  Verkehrsverbünde bieten kostenfreie öffentliche Schnittstellen zum
 Abruf von Fahrplaninformationen an. Die IFOPT Nummer kann in diesem
 Zusammenhang als eindeutiges Anfragekriterium genutzt werden, um
 beispielsweise alle Abfahrten eines Haltepunktes, unabhängig

Re: [Talk-de] Einführung eines neuen Tags (globaleID)

2013-07-11 Diskussionsfäden fly

Am 11.07.2013 12:21, schrieb Tracy Kasperczyk:
 Hallo liebe OSM-Gemeinde,

Ich verfolge die Diskussion jetzt schon ne Weile und frage mich:
* ist das nur eine Deutschland Aktion oder soll sowas global funktionieren ?
* warum noch niemand auf die passende Mailingliste tran...@osm.org
verwiesen hat ?

fly


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Einführung eines neuen Tags (globaleID)

2013-07-11 Diskussionsfäden Martin Koppenhoefer

Am 11. Juli 2013 16:29 schrieb fly lowfligh...@googlemail.com:

 Am 11.07.2013 12:21, schrieb Tracy Kasperczyk:
  Hallo liebe OSM-Gemeinde,

 Ich verfolge die Diskussion jetzt schon ne Weile und frage mich:
 * ist das nur eine Deutschland Aktion oder soll sowas global funktionieren
 ?
 * warum noch niemand auf die passende Mailingliste tran...@osm.org
 verwiesen hat ?



ifopt is wohl eine europäische Norm, vermutlich werden ausserhalb der EU
bzw. Europas die Bahnhöfe nach einem anderen System nummeriert, global ist
der Anspruch AFAIK nicht.

Gruß Martin
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Einführung eines neuen Tags (globaleID)

2013-07-11 Diskussionsfäden Toni Erdmann


On 07/11/2013 02:08 PM, m...@thomas-reincke.de wrote:

Zitat von Martin Koppenhoefer dieterdre...@gmail.com:


Am 11. Juli 2013 12:21 schrieb Tracy Kasperczyk kasperc...@mentzdv.de:
Ich hätte nochmal kurz eine Frage zum Detailgrad, gem. Wikipedia [1] sind
mit der ifopt-Nummer nicht nur Bahnhöfe normiert sondern auch deren
Eingänge, Bahnsteige, Räume, Ausstattung und Einrichtungen, etc.

Wie genau werden die Daten sein, die importiert werden sollen?


Das hängt sehr stark von dem ab, der die Daten pflegt.

Ich pflege die Masten. Aachen Bushof, Bussteig H.1 hat beispielsweise
die IFOPT-Nummer DE:5334:1001:1:1.

Dort wo erforderlich (bei uns nur Bahnhöfe), habe ich auch Zugänge
erfasst, die werden auch eine IFOPT-Nummer erhalten.

hallo Thomas,

kann ich dann davon ausgehen, dass die IFOPT-Nummer eine Hierarchie
enthält, z.B. DE:5334:1001:*:* sind alle Objekte im Aachener Bushof?

Meine Frage zielt auf:

public_transport = stop_position
public_transport = platform

Haben die zusammen eine oder jeder seine eigene IFOPT-Nummern?

Wenn ich, wie Tracy andeutete, eine Suche nach allen Verkehrsmitteln
ab einer Position (konkrete IFOPT-Nummer) anstoßen möchte, hangele ich
mich dann von hinten her durch die Nummer und ersetze Zahlen durch '*'
um weitere Objekte im Umkreis mit einzubeziehen?

Gruß,
Toni


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Einführung eines neuen Tags (globaleID)

2013-07-11 Diskussionsfäden Thomas Reincke


On 11.07.2013 19:18, Toni Erdmann wrote:

Ich pflege die Masten. Aachen Bushof, Bussteig H.1 hat beispielsweise
die IFOPT-Nummer DE:5334:1001:1:1.

Dort wo erforderlich (bei uns nur Bahnhöfe), habe ich auch Zugänge
erfasst, die werden auch eine IFOPT-Nummer erhalten.

hallo Thomas,

kann ich dann davon ausgehen, dass die IFOPT-Nummer eine Hierarchie
enthält, z.B. DE:5334:1001:*:* sind alle Objekte im Aachener Bushof?

Meine Frage zielt auf:

public_transport = stop_position
public_transport = platform

Haben die zusammen eine oder jeder seine eigene IFOPT-Nummern?


DE:5334:1001 ist die Nummer der Gesamthaltestelle, auch STOP genannt. 
Das passt etwas zu public_transport = stop_area


DE:5334:1001:1 ist die Nummer des Umsteigebereichs, auch AREA genannt. 
Das ist meist eine Zusammenfassung von Objekten mit ähnlichen 
Umsteigeeigenschaften. Achtung, es gibt auch bereichlsoe Haltestellen, 
dann wäre die Nummer DE:5334:1001:0.


DE:5334:1001:1:1 ist die Nummer des in EFA Steig genannten Objekt. Bei 
mir ist das der physikalische Mast. Englisch POINT.

Das passt zu einem punktförmigen public_transport = platform

Zu public_transport = stop_position gibt es m. E. nichts äquivalentes. 
Ich setze die stop_position meist auf das Lot des Mastes auf die Fahrbahn.


Aber Achtung. Jeder Datenpfleger hat seine eigenen Vorlieben, das kann 
u.U. anders aussehen. Sowohl bei OSM, als auch bei den Hauptamtlichen.


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Einführung eines neuen Tags (globaleID)

2013-07-11 Diskussionsfäden Toni Erdmann


On 07/11/2013 05:34 PM, Martin Koppenhoefer wrote:

Am 11. Juli 2013 16:29 schrieb fly lowfligh...@googlemail.com:


Am 11.07.2013 12:21, schrieb Tracy Kasperczyk:

Hallo liebe OSM-Gemeinde,


Ich verfolge die Diskussion jetzt schon ne Weile und frage mich:
* ist das nur eine Deutschland Aktion oder soll sowas global funktionieren
?
* warum noch niemand auf die passende Mailingliste tran...@osm.org
verwiesen hat ?




ifopt is wohl eine europäische Norm, vermutlich werden ausserhalb der EU
bzw. Europas die Bahnhöfe nach einem anderen System nummeriert, global ist
der Anspruch AFAIK nicht.



Genau das ist für mich ein Grund für ein Tag:

xyz:ifopt   (ref:ifopt, public_transport:ifopt, ...)
zu plädieren, denn dann könnte man bei anderen Normen (USA, ...)
den string hinterm ':' austauschen und gut wärs. D.h. einen
Namensraum aufspannen, der erweiterbar ist.

Ich finde den Unterstrich bei ref_ifopt nicht optimal.

Toni







___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Einführung eines neuen Tags (globaleID)

2013-07-11 Diskussionsfäden Henning Scholland


Hallo
Für mich klingt das nach jeder Menge Redundanz. Wenn DE:5334:1001 nur 
aussagt Ich bin die Haltestelle Busbahnhof Aachen, dann steckt diese 
Info doch bereits in unseren Daten. Dann braucht es doch keine 
zusätzliche Ref, die genau das gleiche nochmal sagt. Ebenso die weitere 
Unterscheidung. Dafür gibt es ja die pt-Relationen und ihre Member.


Henning


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Einführung eines neuen Tags (globaleID)

2013-07-11 Diskussionsfäden Thomas Reincke


Am 11.07.2013 21:54, schrieb Henning Scholland:

Hallo
Für mich klingt das nach jeder Menge Redundanz. Wenn DE:5334:1001 nur
aussagt Ich bin die Haltestelle Busbahnhof Aachen, dann steckt diese
Info doch bereits in unseren Daten. Dann braucht es doch keine
zusätzliche Ref, die genau das gleiche nochmal sagt. Ebenso die weitere
Unterscheidung. Dafür gibt es ja die pt-Relationen und ihre Member.


Die Referenzierung zwischen beiden hilft die Daten abzugleichen.

Wenn die Haltestelle in -wovon ich nicht ausgehe- EBV Carree umbenannt 
würde, hätte sie immer noch die ID DE:5334:1001. Diese Änderung könnte 
man anhand zur Verfügung gestellten Listen recht schnell nachvollziehen 
und die Daten in OSM anpassen.



___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Einführung eines neuen Tags (globaleID)

2013-07-11 Diskussionsfäden Henning Scholland


Am 11.07.2013 22:17, schrieb Thomas Reincke:

Am 11.07.2013 21:54, schrieb Henning Scholland:

Hallo
Für mich klingt das nach jeder Menge Redundanz. Wenn DE:5334:1001 nur
aussagt Ich bin die Haltestelle Busbahnhof Aachen, dann steckt diese
Info doch bereits in unseren Daten. Dann braucht es doch keine
zusätzliche Ref, die genau das gleiche nochmal sagt. Ebenso die weitere
Unterscheidung. Dafür gibt es ja die pt-Relationen und ihre Member.


Die Referenzierung zwischen beiden hilft die Daten abzugleichen.

Wenn die Haltestelle in -wovon ich nicht ausgehe- EBV Carree 
umbenannt würde, hätte sie immer noch die ID DE:5334:1001. Diese 
Änderung könnte man anhand zur Verfügung gestellten Listen recht 
schnell nachvollziehen und die Daten in OSM anpassen.
Nehmen wir mal an, in einiger Zeit gibt es ein Objekt in OSM mit der Ref 
DE:5334:1001 und dem Namen Aachener Busbahnhof und die Liste sagt, die 
Ref DE:5334:1001 müsste EBV Carree heißen. Wer hätte nun recht? Sollte 
man dann nicht dann vor Ort nachschauen bzw. die Frage mit lokalem 
Wissen beantworten?


Henning


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Einführung eines neuen Tags (globaleID)

2013-07-10 Diskussionsfäden Martin Koppenhoefer

Am 10. Juli 2013 00:50 schrieb Stephan Wolff s.wo...@web.de:


  Für diese Erfassung benötigen wir einen neuen Tag. Dieser Tag
 soll globale_id_pt = * (IFOPT Nummer) heißen.


 Ich finde den Namen globale_id_pt ungünstig (Denglish und nicht intuitiv
 verständlich). Warum nicht ref_ifopt?
 Die von anderen geäußerten Bedenken gegen diese Information teile ich
 nicht.




sofern das öffentlich zugängliche Nummern sind, finde ich auch ref
angemessen, oder ggf. ref:ifopt=* falls ref schon vergeben ist (z.B. durch
Bahnhofsnummern der DB).

globale_id_pt halte ich auch in jedem Fall für weniger gut geeignet, in OSM
sind alphanumerische Identifier normalerweise ref oder ref:foo=*

Gruß Martin
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Einführung eines neuen Tags (globaleID)

2013-07-10 Diskussionsfäden Jochen Topf

On Wed, Jul 10, 2013 at 12:20:02PM +0200, Martin Koppenhoefer wrote:
 Am 10. Juli 2013 00:50 schrieb Stephan Wolff s.wo...@web.de:
 
 
   Für diese Erfassung benötigen wir einen neuen Tag. Dieser Tag
  soll globale_id_pt = * (IFOPT Nummer) heißen.
 
 
  Ich finde den Namen globale_id_pt ungünstig (Denglish und nicht intuitiv
  verständlich). Warum nicht ref_ifopt?
  Die von anderen geäußerten Bedenken gegen diese Information teile ich
  nicht.
 
 
 
 
 sofern das öffentlich zugängliche Nummern sind, finde ich auch ref
 angemessen, oder ggf. ref:ifopt=* falls ref schon vergeben ist (z.B. durch
 Bahnhofsnummern der DB).
 
 globale_id_pt halte ich auch in jedem Fall für weniger gut geeignet, in OSM
 sind alphanumerische Identifier normalerweise ref oder ref:foo=*

Ich hab mich immer gefragt, was der Informationsgehalt von diesem ref
sein soll. Warum muss überall ref mit rein?

Wie wäre es mit public_transport:ifopt oder so? public_transport ist
als Key schon eingeführt und es wird sofort klar, dass es um ÖPNV geht
irgendwie. Wer mehr wissen will, fragt seine Suchmaschine der Wahl nach
ifopt und findet dann mehr. Allerdings scheint mir ifopt der Name
eines Schemas zu sein und nicht der der ID. Also wahrscheinlich eher sowas
wie public_transport:ifopt:stop_id oder so.

globale_id_pt ist auf jeden Fall furchtbar. Es ist total unklar, was
das ist und sein könnte, man findet nix gescheites, wenn man danach sucht
und globale müßte global heissen, wenn es Englisch sein soll.

Jochen
-- 
Jochen Topf  joc...@remote.org  http://www.jochentopf.com/  +49-721-388298

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Einführung eines neuen Tags (globaleID)

2013-07-10 Diskussionsfäden Dirk Sohler

Jochen Topf schrieb:
 globale_id_pt ist auf jeden Fall furchtbar. Es ist total unklar, was
 das ist und sein könnte, man findet nix gescheites, wenn man danach
 sucht und globale müßte global heissen, wenn es Englisch sein
 soll.

So heißt das entsprechende Datenfeld vermutlich in der internen
Datenbank des Kunden, und man wollte sich nicht die Mühe machen, einen
brauchabren Tagnamen zu entwickeln, und hat einfach die interne
Bezeichnung der ID übernommen.

Alles sehr „fishy“ … Vor allem, da sich das entsprechende Unternehmen
nun so gar nicht mehr aktiv an der Diskussion beteiligt. Klingt eher
so, als wolle man lediglich sagen „wir machen das jetzt, und ihr lasst
das Tag bitte in Ruhe“.

Grüße,
Dirk

-- 
Local time :: Ortszeit :: DE-HH
2013-07-10T16:58:58+0200


signature.asc
Description: PGP signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Einführung eines neuen Tags (globaleID)

2013-07-10 Diskussionsfäden Wolfgang Hinsch

Am Mittwoch, den 10.07.2013, 13:14 +0200 schrieb Jochen Topf:
 On Wed, Jul 10, 2013 at 12:20:02PM +0200, Martin Koppenhoefer wrote:
  Am 10. Juli 2013 00:50 schrieb Stephan Wolff s.wo...@web.de:
  
  
Für diese Erfassung benötigen wir einen neuen Tag. Dieser Tag
   soll globale_id_pt = * (IFOPT Nummer) heißen.
  
   Ich finde den Namen globale_id_pt ungünstig (Denglish und nicht intuitiv
   verständlich). Warum nicht ref_ifopt?
  
  sofern das öffentlich zugängliche Nummern sind, finde ich auch ref
  angemessen, oder ggf. ref:ifopt=* falls ref schon vergeben ist (z.B. durch
  Bahnhofsnummern der DB).
  
  globale_id_pt halte ich auch in jedem Fall für weniger gut geeignet, in OSM
  sind alphanumerische Identifier normalerweise ref oder ref:foo=*
 
 Ich hab mich immer gefragt, was der Informationsgehalt von diesem ref
 sein soll. Warum muss überall ref mit rein?
 
 sowas
 wie public_transport:ifopt:stop_id oder so.
 
 globale_id_pt ist auf jeden Fall furchtbar. Es ist total unklar, was
 das ist und sein könnte, man findet nix gescheites, wenn man danach sucht
 und globale müßte global heissen, wenn es Englisch sein soll.
 

Also, wenn ich das richtig verstanden habe, werden damit Positionen auf
dem Gleis und auf dem Bahnsteig am Gleis markiert. Wie das in
irgendeiner Spezial-DB heißt, kann uns doch völlig schnuppe sein. Besser
wäre ein Klartext wie:

public_transport:stop_position=Gleis3_Nord';
public_transport:stop_position=Gleis3_Mitte';
public_transport:stop_position=Gleis3_Sued';

oder ost/west, wenn der Bahnhof anders rum liegt.

Falls eine Position reicht (an vielen Bahnsteigen werden mehrere Züge
hintereinander bereitgestellt), einfach nur 'Gleis3'.

Dann wird im Wiki erklärt, was das heißen soll, eine Vorlage dazu, damit
die Rechtschreibung stimmt, ein Style für josm, damit es angezeigt wird
und gut ist. Dann weiß jeder, was gemeint ist und kann das auch
reparieren.

Das Bundesland und der Bahnhofsname sollte sich eindeutig aus der Lage
ergeben.

Die Bahnsteigpositionen analog. Eingänge auch (Eingang_Nord,
Eingang_Nord-Ost oder so). Aus einer separaten Tabelle geht dann hervor,
welche ID damit gemeint ist, das muss nicht in OSM stehen.

Zusätzlich hat man damit den Vorteil, dass sofort auffällt, wenn in den
Daten etwas fehlt, weil dann für IDs die OSM-Position nicht gefunden
wird.

Vielleicht übersehe ich etwas, aber eigentlich könnte das so einfach
sein.

Gruß, Wolfgang


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Einführung eines neuen Tags (globaleID)

2013-07-10 Diskussionsfäden Stephan Knauss


Dirk Sohler writes:


Alles sehr „fishy“ … Vor allem, da sich das entsprechende Unternehmen
nun so gar nicht mehr aktiv an der Diskussion beteiligt.


Die Antworten waren auch in vielen Fällen alles andere als freundlich,  
einladend, konstruktiv.


Ich bin in den glücklichen Lage einen direkten Kontakt zum Unternehmen zu  
haben. Die waren nämlich im Vorfeld bereits persönlich bei der Community  
hier in München.


Ich werde mal andeuten dass eine kurze Reaktion, eventuell bereits mit  
einer Sammlung der Bedenken und Anregungen, im besten Fall schon mit  
Antworten ganz gut wäre.


Sehr gut möglich dass nächsten Dienstag wieder jemand vor Ort ist.

Viele Grüße,

Stephan

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Einführung eines neuen Tags (globaleID)

2013-07-10 Diskussionsfäden Eckhart Wörner

Hallo Wolfgang,

Am Mittwoch, 10. Juli 2013, 17:04:13 schrieb Wolfgang Hinsch:
 Also, wenn ich das richtig verstanden habe, […]

nein, offensichtlich nicht.

Eckhart

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Einführung eines neuen Tags (globaleID)

2013-07-10 Diskussionsfäden Toni Erdmann


On 07/10/2013 05:26 PM, Stephan Knauss wrote:

Dirk Sohler writes:


Alles sehr „fishy“ … Vor allem, da sich das entsprechende Unternehmen
nun so gar nicht mehr aktiv an der Diskussion beteiligt.


Die Antworten waren auch in vielen Fällen alles andere als freundlich,
einladend, konstruktiv.


Sorry, dass ich erst jetzt die Zeit finde mich zu melden.

Ich hatte am 17. Juni ein etwa 2-stündiges Gespräch in den Büros von
Mentz DV. Vorausgegangen war ein E-Mail-Verkehr aufgrund einer
Änderung am Münchener Ostbahnhof.

Das Gespräch mit Tracy und ihren Kollegen war sehr freundlich, entspannt
und konstruktiv. Meine Bitte war dabei, dass sie sich wegen weiterer
Absprachen / Vorschlägen an diese Liste wenden sollten.

Bei einigen Antworten habe ich mich dann allerdings über die Heftigkeit
gewundert.

Was neue Tags und die unabhängige Überprüfbarkeit durch Dritte angeht,
bin ich auch der Meinung, dass die Quellen offen sein müssen. Und zwar
so, dass ein beliebiger Mapper bei fehlerhafte oder verschwundene Tags
Reparaturen anhand einer Liste vornehmen kann. Optimal wäre ein
regelmäßiger Update der Liste(n).

Bei den Namen plädiere auch ich eher für generische Namen mit
Namensräumen, wie z.B. von Jochen Topf vorgeschlagen

public_transport:ifopt:stop_id

wobei ich das ifopt ganz ans Ende stellen würde:
- vom Allgemeinen public_transport
- über das spezifischere stop_id(oder so)
- zum spezifisch zu verwendenden Standard ifopt für die
  Analyse, Syntax und Semantik der Wertes.

Toni (ToniE)



___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Einführung eines neuen Tags (globaleID)

2013-07-09 Diskussionsfäden Stephan Wolff


Moin!

Am 07.07.2013 08:19, schrieb Tracy Kasperczyk:

Sehr geehrte OSM-Gemeinde,

wir die Firma Mentz Datebverarbeitung GmbH mit dem Sitz in München (
http://www.mentzdv.de/), arbeiten gerade daran die Bahnhöfe in Bayern, NRW
und Baden-Würtenberg zu überarbeiten mit dem Ziel einer vollständigen und
einheitlichen Darstellung.


Bitte beschreibt, was ihr ändern und vereinheitlichen wollt, bevor ihr in
großem Umfang Bahnhöfe überarbeitet.
Gibt es schon einen Musterbahnhof?


Für diese Erfassung benötigen wir einen neuen Tag. Dieser Tag
soll globale_id_pt = * (IFOPT Nummer) heißen.


Ich finde den Namen globale_id_pt ungünstig (Denglish und nicht 
intuitiv verständlich). Warum nicht ref_ifopt?

Die von anderen geäußerten Bedenken gegen diese Information teile ich nicht.

Gruß
Stephan



___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Einführung eines neuen Tags (globaleID)

2013-07-08 Diskussionsfäden Dirk Sohler

Wolfgang Hinsch schrieb:
 Es kann nicht sein, dass sich hier immer mehr tags einschleichen, die
 niemand mehr nachvollziehen kann und schon gar nicht solche, die man
 nicht nachschlagen darf.

Ja, am besten soll man die Tags auch noch selbst eintragen, ohne zu
wissen, was sie bedeuten, und hinterher unter keinen Umständen mehr
ändern, weil Kunden von Unternehmen, die die Eintragung initiiert
haben, damit hinterher kommerziell proprietär Geld verdienen wollen.


 Insofern sollte die Bedingung für jedes neue tag sein, dass eine
 verständliche Erklärung und nachvollziehbare Aufschlüsselung offen
 vorliegt, ggf. als Verweis über das Wiki.

+1


Grüße,
Dirk

-- 
Local time :: Ortszeit :: DE-HH
2013-07-08T17:11:08+0200


signature.asc
Description: PGP signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Einführung eines neuen Tags (globaleID)

2013-07-08 Diskussionsfäden richard.redw...@yahoo.de

...v...   vbn..

Gesendet mit meim. nem HT,t,hztC

- Reply message -
Von: Wolfgang Hinsch osm-lis...@ivkasogis.de
An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org
Betreff: [Talk-de]Einführung eines neuen Tags (globaleID)
Datum: So., Jul. 7, 2013 17:13


Am Sonntag, den 07.07.2013, 17:43 +0200 schrieb Eckhart Wörner:
 Hallo Tirkon,
 
 Am Sonntag, 7. Juli 2013, 17:36:18 schrieb Tirkon:
  Nein! Ich zitiere:
 
 Dann zitiere ich auch nochmal:
  Nummern, deren Bedeutung unter Verschluss ist, hätten
  in OSM nichts zu suchen
 

Ja und? Wo ist das Ideologie?

Nachvollziehbarkeit durch den Mapper ist bei uns eins der obersten
Gebote. Ich erinnere mich noch an die Diskussionen bezüglich OpenSeaMap,
und da kann man die Dokumentation international genormt für jede
Seekarte wirklich an fast jeder Hausecke bekommen.

Eine ähnliche Diskussion gab es neulich über Farben, die auch problemlos
nachschlagbar sind, aber einigen nicht verständlich genug waren.

Es kann doch nicht sein, dass die Mapper jetzt die Anweisung bekommen
Hier trägst du xx=y4mp35ql ein, und frage gefälligst nicht, was das
heißen soll.

Oder habe ich dich falsch verstanden?

Gruß, Wolfgang


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

[Talk-de] Einführung eines neuen Tags (globaleID)

2013-07-07 Diskussionsfäden Tracy Kasperczyk

Sehr geehrte OSM-Gemeinde,

wir die Firma Mentz Datebverarbeitung GmbH mit dem Sitz in München (
http://www.mentzdv.de/), arbeiten gerade daran die Bahnhöfe in Bayern, NRW
und Baden-Würtenberg zu überarbeiten mit dem Ziel einer vollständigen und
einheitlichen Darstellung. Die Modellierung soll Routing und Navigation
innerhalb des Bahnhofs bis zum Fahrzeug erlauben und dabei speziell auch wo
möglich die Berechnung barrierefreier Routen ermöglichen. Wir arbeiten im
Auftrag der jeweiligen Verbünde und Länder, Die Ergebnisse sollen in den
einzelnen Fahrplanauskunftssystem im Internet (Bayernfahrplan,
EFA-Baden-Württemberg, VRR) und in den jeweiligen Apps sichtbar werden. Wir
erwarten mit der Bearbeitung in OSM eine wesentliche Verbesserung der
geographischen Grundlage.



Für diese Erfassung benötigen wir einen neuen Tag. Dieser Tag
soll globale_id_pt = * (IFOPT Nummer) heißen.



Dieser neue Tag ist die eindeutige Nummerierung der Objekte einer
Haltestelle nötig. Diese Nummerierung der Haltestelle wird basierend auf
dem CEN Standard CEN TC278 SG6 IFOPT (Identification of Fixed Objects in
Public Transport) durchgeführt. Dieser Standard sieht für Deutschland
folgende Codierung vor:



Für die Plattformen in OSM: de:Landkreisnr:lokale
Haltstellennummer:PlattformNr

Für die Stop_Position in OSM: de:Landkreisnr:lokale
Haltstellennummer:PlattformNr:SteigCode

Für die Eingänge der Bahnhöfe: de:Landkreisnr:lokale
Haltstellennummer:EingangNr



Die Landkreisnummer kommt aus dem Amtlichen Gemeindeschlüssel. Die lokale
Nummer vergibt der örtlich verantwortliche Verkehrsverbund oder der
Landkreis bei Landkreisen ohne Verbund.



Wir benötigen diese Nummer für 3-Objekte aus OSM, für die Plattformen
(Bahnsteige), für die Stop_position auf den Gleisen und für die Zugänge/
Eingänge zu den Bahnhöfen.



Es existieren bereits solche Nummern aus den Haltestellenkatastern der
jeweiligen Länder, die wir und unsere Kunden in OSM durch einen neuen Tag
einpflegen würden. Diese Nummer sollte nicht bearbeitet werden, da unsere
Kunden diese benötigen um mit den OSM-Daten weiterarbeiten zu können.

Wir würden uns sehr über die Mithilfe der OSM-Gemeinde bei der Umsetzung
des Projektes freuen.

Viele Grüße
Taoxue (Tracy)
i.A. Mentz Darenverarbeitung GmbH
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Einführung eines neuen Tags (globaleID)

2013-07-07 Diskussionsfäden Dirk Sohler

Tracy Kasperczyk schrieb:
 Die Modellierung soll Routing und Navigation innerhalb des Bahnhofs
 bis zum Fahrzeug erlauben und dabei speziell auch wo möglich die
 Berechnung barrierefreier Routen ermöglichen.

Ist das ein Projekt, aus dem die Community ganz im Sinne von Open Data
einen Nutzen ziehen kann, oder ist das eine interne Geschichte, auf die
ein Normalbürger nicht ohne weiteres Zugriff bekommen kann?

… und wäre es für so eine Spezialanwendung nicht sinnvoller, das intern
zu machen, mit den OSM-Daten zusammenzuführen, und dann auszuliefern,
ohne unzählige Spezialtags in die OSM-Daten zu bringen, die jeder
jederzeit ändern kann (was laut der Projektbeschreibung nicht so gut
wäre)?

Grüße,
Dirk

-- 
Local time :: Ortszeit :: DE-HH
2013-07-07T09:59:26+0200


signature.asc
Description: PGP signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Einführung eines neuen Tags (globaleID)

2013-07-07 Diskussionsfäden Tirkon

Tracy Kasperczyk kasperc...@mentzdv.de wrote:

wir die Firma Mentz Datebverarbeitung GmbH mit dem Sitz in München (
http://www.mentzdv.de/), arbeiten gerade daran die Bahnhöfe in Bayern, NRW
und Baden-Würtenberg zu überarbeiten mit dem Ziel einer vollständigen und
einheitlichen Darstellung. Die Modellierung soll Routing und Navigation
innerhalb des Bahnhofs bis zum Fahrzeug erlauben und dabei speziell auch wo
möglich die Berechnung barrierefreier Routen ermöglichen. 

Nur vom Bahnsteiggleis zum Fahrzeug? 
Nicht zum örtlichen Nahverkehr und innerhalb dessen?

Wir arbeiten im
Auftrag der jeweiligen Verbünde und Länder, Die Ergebnisse sollen in den
einzelnen Fahrplanauskunftssystem im Internet (Bayernfahrplan,
EFA-Baden-Württemberg, VRR) und in den jeweiligen Apps sichtbar werden. 

Für den VRR Verkehrsverbund (Großraum Ruhrgebiet-Düsseldorf) finde ich
diese Annäherung an OSM doch nun erstaunlich. Der hat sich meines
Wissens in der Vergangenheit bei den Anfragen diverser OSMler
vollkommen taub bis einsilbig ablehnend gestellt. Es wäre natürlich
großartig, wenn sich das durch diese Maßnahme zumindest mittelbar und
möglicherweise zukünftig auch unmittelbar ändert.

Wir
erwarten mit der Bearbeitung in OSM eine wesentliche Verbesserung der
geographischen Grundlage.

Auf jeden Fall ist es zunächst einmal erfreulich, wenn OSM für die
Nutzer der Fahrplanauskunft hilfreich sein könnte. Von daher vielen
Dank für diese Initiative. :-) 

Für diese Erfassung benötigen wir einen neuen Tag. Dieser Tag
soll globale_id_pt = * (IFOPT Nummer) heißen.

Bitte nur einfügen, was mit unserer Lizenz kompatibel und frei
verfügbar ist. Nummern, deren Bedeutung unter Verschluss ist, hätten
in OSM nichts zu suchen, weil dann der Titel !!!Freie!!! Datenbank
keine Berechtigung mehr hätte. Sollte die Lizenzkompatibilität für die
hier von Dir im Thread erwähnten Nummern gegeben sein, dann bitte
deren Bedeutung im OSM Wiki erklären und eine zuverlässige Quelle
möglichst im Internet angeben, wo diese Nummern aufgelistet sind. Denn
die Daten in OSM sollten für jeden OSMler nachprüfbar sein. Alternativ
kann die Erklärung auch hier im Thread geschehen, wenn Du bestätigst,
dass der Text CC BY SA ist. Dann kann der Text ins OSM Wiki übernommen
werden.  

Dieser neue Tag ist die eindeutige Nummerierung der Objekte einer
Haltestelle nötig. Diese Nummerierung der Haltestelle wird basierend auf
dem CEN Standard CEN TC278 SG6 IFOPT (Identification of Fixed Objects in
Public Transport) durchgeführt. Dieser Standard sieht für Deutschland
folgende Codierung vor:

Für die Plattformen in OSM: de:Landkreisnr:lokale
Haltstellennummer:PlattformNr

Für die Stop_Position in OSM: de:Landkreisnr:lokale
Haltstellennummer:PlattformNr:SteigCode

Für die Eingänge der Bahnhöfe: de:Landkreisnr:lokale
Haltstellennummer:EingangNr

Sprichst Du bei Haltestellennummer, PlattformNr, Steigcode und
EingangNr etc. nur von Zügen (ab S-Bahn aufwärts?) und nicht vom
örtlichen Nahverkehr mit U-Bahn/Stadtbahn, Straßenbahnen und Bussen?
Existieren diese Nummern dort nicht? Denn wenn wir schon mit
irgendwelchen Nummern anfangen und diese nicht nur für Züge
existieren, dann sollten diese zumindest im benutzten Gebiet auch
komplett und nicht nur in Teilmenge verfügbar sein.

Weitere Frage: Existieren diese Nummern deutschlandweit, europaweit
oder gar weltweit oder nur in dem von Dir beschriebenen Gebiet?


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Einführung eines neuen Tags (globaleID)

Hallo Tirkon,

Am Sonntag, 7. Juli 2013, 12:06:06 schrieb Tirkon:
 Für diese Erfassung benötigen wir einen neuen Tag. Dieser Tag
 soll globale_id_pt = * (IFOPT Nummer) heißen.
 
 Nummern, deren Bedeutung unter Verschluss ist, hätten
 in OSM nichts zu suchen, weil dann der Titel !!!Freie!!! Datenbank
 keine Berechtigung mehr hätte.

Aua!

Eckhart

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Einführung eines neuen Tags (globaleID)

Hallo Dirk,

Am Sonntag, 7. Juli 2013, 10:10:26 schrieb Dirk Sohler:
  Die Modellierung soll Routing und Navigation innerhalb des Bahnhofs
  bis zum Fahrzeug erlauben und dabei speziell auch wo möglich die
  Berechnung barrierefreier Routen ermöglichen.
 
 Ist das ein Projekt, aus dem die Community ganz im Sinne von Open Data
 einen Nutzen ziehen kann, oder ist das eine interne Geschichte, auf die
 ein Normalbürger nicht ohne weiteres Zugriff bekommen kann?

Vielleicht beschäftigst du dich erst einmal mit der Materie? Die IBNR, die 
Bahnhöfe kennzeichnet, wird von den entsprechenden Leuten durchaus gewünscht, 
leider gibt es aber keine frei verfügbaren Listen.

Eckhart

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Einführung eines neuen Tags (globaleID)

2013-07-07 Diskussionsfäden Peter Wendorff

Hallo Tracy.

Das Ziel klingt nicht schlecht - aber die ID halte ich für unnötig -
Erklärung folgt unten:

Am 07.07.2013 08:19, schrieb Tracy Kasperczyk:
 Sehr geehrte OSM-Gemeinde,
 
 [...] 
 Für diese Erfassung benötigen wir einen neuen Tag. Dieser Tag
 soll globale_id_pt = * (IFOPT Nummer) heißen.
 
 Dieser neue Tag ist die eindeutige Nummerierung der Objekte einer
 Haltestelle nötig. Diese Nummerierung der Haltestelle wird basierend auf
 dem CEN Standard CEN TC278 SG6 IFOPT (Identification of Fixed Objects in
 Public Transport) durchgeführt. Dieser Standard sieht für Deutschland
 folgende Codierung vor:
 
 Für die Plattformen in OSM: de:Landkreisnr:lokale
 Haltstellennummer:PlattformNr
Der AGS ist in OSM prinzipiell schon vorhanden und eine räumliche
Zuordnung sollte möglich sein, insofern kann eine Vorverarbeitung für
jede Plattform den AGS und damit auch die Landkreisnummer herausfinden.

Die Lokale Haltestellennummer: Wo steht die? Wo lässt sich die für den
normalen Mapper nachschlagen? Denn jeder muss prinzipiell in der Lage
sein, einen Tag zu verifizieren oder zu korrigieren, sonst macht das
keinen Sinn.

Ich vermute mal ins Blaue (korrigiert mich, wenn ich falsch liege), dass
es Listen dafür gibt, die eine Zuordnung wie Ort/Haltestellenname =
Haltestellennummer enthalten.
Wenn das der Fall ist, kann man aber aus Ort und Haltestellennamen auch
wieder die Nummer rauskriegen.

Zur Plattformnummer sagst du nichts weiter, insofern weiß ich nicht, wie
die vergeben wird, aber wir haben mit ref=* die Gleisnummer, wenn
vorhanden, normalerweise auch drin.

 Für die Stop_Position in OSM: de:Landkreisnr:lokale
 Haltstellennummer:PlattformNr:SteigCode
 
 Für die Eingänge der Bahnhöfe: de:Landkreisnr:lokale
 Haltstellennummer:EingangNr
 
 
 
 Die Landkreisnummer kommt aus dem Amtlichen Gemeindeschlüssel. Die lokale
 Nummer vergibt der örtlich verantwortliche Verkehrsverbund oder der
 Landkreis bei Landkreisen ohne Verbund.
 
 
 
 Wir benötigen diese Nummer für 3-Objekte aus OSM, für die Plattformen
 (Bahnsteige), für die Stop_position auf den Gleisen und für die Zugänge/
 Eingänge zu den Bahnhöfen.
 
 
 
 Es existieren bereits solche Nummern aus den Haltestellenkatastern der
 jeweiligen Länder, die wir und unsere Kunden in OSM durch einen neuen Tag
 einpflegen würden. Diese Nummer sollte nicht bearbeitet werden, da unsere
 Kunden diese benötigen um mit den OSM-Daten weiterarbeiten zu können.
 
 Wir würden uns sehr über die Mithilfe der OSM-Gemeinde bei der Umsetzung
 des Projektes freuen.
Ich sehe hier zwei Probleme:
1) Diese Nummer sollte nicht bearbeitet werden
2) Mithilfe der OSM-Gemeinde: Wie soll die mithelfen, wenn die Mithilfe
darin besteht, nichts zu tun?

Zum ersten Problem:
Als sollte nicht bearbeitet werden ist das vielleicht noch halbwegs
akzeptabel - ein Verbot wird daraus aber nicht werden. Ihr könnt euch
als nicht darauf verlassen, dass die Nummer in OSM nicht bearbeitet
wird. Ihr könnt euch aber nichtmal darauf verlassen, dass die Nummer
korrekt bleibt. Nehmen wir als Beispiel eine Bushaltestelle mit zwei
Bussteigen, die bisher noch nicht vollständig erfasst ist, es existiert
also noch gar keine Plattform - auch wenn ihr Referenznummern dazu habt.
Ich vermute, ihr würdet hier zunächst nur die Nummer einfügen, also die
Haltestellennummmer und die Landkreisnummer, denn woher solltet ihr auf
einmal Kartenmaterial haben, das in OSM aufgenommen werden dürfte, und
genauer ist?
Jetzt fängt ein Mapper (ich zum Beispiel) an und trägt die einzelnen
Bussteige ein, angenommen, das sind drei. Darf ich eure ID jetzt
eintragen? Wenn ja: warum sollte ich das tun? das sind doch schließlich
redundante Informationen (siehe oben).
Anderer Fall: Die Haltestelle ist schon mit einzelnen Bussteigen
eingetragen, aber aus irgendeinem Grund zeichnet ein Mapper die
einzelnen Wege neu ein, z.B. weil er aus versehen vorher was
kaputtgemacht hat oder so. Darf er jetzt die IDs eintragen? Korrigieren?
Ändern? Woher kriegt er die?

Um sicherzugehen, dass eure Kunden nicht durch solche und ähnliche Fälle
ständig fehlerhafte Daten kriegen, müsstet ihr also unabsichtliche
Änderungen überwachen, kontrollieren und korrigieren. Dabei müsstet ihr
aber sicherstellen, dass gültige und korrekte Korrekturen weiter möglich
bleiben - also z.B. muss ich in der Lage sein, den neuen Aufzug
einzutragen (der sogar für euren direkten Anwendungsfall hilfreich ist),
oder die neue Pflasterung der Haltestelle, bei der die Querung auf 0
abgesenkt, aber mit taktilen Bodenindikatoren ausgestattet worden ist -
und so weiter.
Insbesondere beinhaltet das auch die Möglichkeit, Teile der Haltestelle
zu verschieben (um z.B. die Lage zu korrigieren).

Wenn ihr eine solche Überwachung aber nicht manuell umsetzen wollt,
bleibt euch nicht viel mehr übrig, als sowieso
- alle Haltestellenobjekte/Plattformen etc., die in OSM auftauchen, zu
bemerken
- jeweils die Daten zu überprüfen,
- und dann eure ID da dranzupappen.

...und das unter Vermeidung aller Konflikte

Re: [Talk-de] Einführung eines neuen Tags (globaleID)

2013-07-07 Diskussionsfäden Stephan Knauss


Hallo Tracy,

ihr wart ja schon vor ein paar Wochen bei uns auf dem Stammtisch und 
habe da bereits einiges an Infos und auch an möglichen Bedenken mitbekommen.


Es freut mich dass es euch nicht abgeschreckt hat OSM Daten zu verwenden.

Wenn ihr die PlatformNr, SteigCode und EingangNr zur Verfügung stellt 
ist das eine große Ergänzung zu OSM. Wir haben dadurch nicht nur 
sämtliche Haltestellen sondern auch noch die Eingänge dazu.
Könnt ihr zusätzlich den Namen der Haltestelle beitragen und eventuell 
welche Linie dort fährt?


Was auf jeden Fall passieren kann ist dass jemand den Tag versehentlich 
löscht, ändert oder bei neuen Haltestellen nicht einträgt.
Es könnte auch sein dass es Abweichungen zwischen eurer Liste und der 
Realität gibt. Habt ihr einen Plan wie ihr damit umgehen wollt?




On 07.07.2013 08:19, Tracy Kasperczyk wrote:

Für diese Erfassung benötigen wir einen neuen Tag. Dieser Tag
soll globale_id_pt = * (IFOPT Nummer) heißen.



Stephan



___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Einführung eines neuen Tags (globaleID)

2013-07-07 Diskussionsfäden Wilhelm Spickermann

Hi,

Am Sun, 7 Jul 2013 08:19:17 +0200
schrieb Tracy Kasperczyk kasperc...@mentzdv.de:

 ... soll globale_id_pt = * (IFOPT Nummer) heißen.

Ich würde es eher ifopt_ref nennen. Jede Suchmaschine liefert dann
passende Ergebnisse für den verwirrten Mapper.


Zum Konzept:

Falls ihr dabei Bahnsteige braucht, die nur zu einem Gleis gehören --
man die Bahnsteige also längs spalten müsste -- dann habt Ihr
ein Problem. OSM könnte sich gegen längsgesplittete Bahnsteige
entscheiden.

Falls Ihr mit Bahnsteigen in mehreren Teilen nicht klar kommt. OSM hat
sie wegen der Regelung mit Brücken. Der Mainzer Hauptbahnhof hat z.B.
sowas auf Gleis 5: Eine Brücke mitten im Bahnsteig sorgt für eine
Quer-Aufteilung des Bahnsteigs.

Auch in Mainz kann man doppelte Benennungen von Bahnsteigen sehen, die
so auch in den Fahrplänen auftauchen. Es gibt sowohl ein Gleis 3 als
auch Gleise 3a und 3b, obwohl das Ganze nur eine Bahnsteigsseite ist.

Dann gibt es noch Halte, bei denen gleichzeitig an zwei Bahnsteigen
gehalten wird. Das findet man z.B. bei der
wie-auch-immer-sie-gerade-heißt-Arena in Düsseldorf.

Was ist mit Ersatzhaltestellen bei Baustellen. Bei längerfristigen
Baustellen nehmen wir die eine gern aus den Linienrelationen raus und
die Ersatzhaltestelle kommt rein. Was sollte dann mit der Nummer
passieren?

Ihr braucht vermutlich die einzelnen Bahnsteige. Wo die nicht gemappt
sind, könnt Ihr sie natürlich eintragen, wenn das mit der Lizenz
hinkommt. Aber dabei müssen alle benutzenden Relationen angepasst
werden. Man muss also plötzlich Bahnsteig- oder Bussteignummern aller
Linien wissen und eintragen dürfen. Das gilt dann auch für die
Fahrzeuge von Nicht-Auftraggebern! (Zum Beispiel in den
Überlappungsgebieten von Verkehrsverbünden.) Ist das Problem wirklich
lösbar?

MfG
Wilhelm



___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Einführung eines neuen Tags (globaleID)

2013-07-07 Diskussionsfäden Henning Scholland



Am 07.07.2013 12:23, schrieb Peter Wendorff:

Der AGS ist in OSM prinzipiell schon vorhanden und eine räumliche
Zuordnung sollte möglich sein, insofern kann eine Vorverarbeitung für
jede Plattform den AGS und damit auch die Landkreisnummer herausfinden.

Die Lokale Haltestellennummer: Wo steht die? Wo lässt sich die für den
normalen Mapper nachschlagen? Denn jeder muss prinzipiell in der Lage
sein, einen Tag zu verifizieren oder zu korrigieren, sonst macht das
keinen Sinn.

Ich vermute mal ins Blaue (korrigiert mich, wenn ich falsch liege), dass
es Listen dafür gibt, die eine Zuordnung wie Ort/Haltestellenname =
Haltestellennummer enthalten.
Wenn das der Fall ist, kann man aber aus Ort und Haltestellennamen auch
wieder die Nummer rauskriegen.

Zur Plattformnummer sagst du nichts weiter, insofern weiß ich nicht, wie
die vergeben wird, aber wir haben mit ref=* die Gleisnummer, wenn
vorhanden, normalerweise auch drin.

+1

Ich sehe hier zwei Probleme:
1) Diese Nummer sollte nicht bearbeitet werden

Wird es in OSM nie geben.

2) Mithilfe der OSM-Gemeinde: Wie soll die mithelfen, wenn die Mithilfe
darin besteht, nichts zu tun?

+1

Henning


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Einführung eines neuen Tags (globaleID)

2013-07-07 Diskussionsfäden Wolfgang Hinsch

Am Sonntag, den 07.07.2013, 12:17 +0200 schrieb Eckhart Wörner:
 Hallo Tirkon,
 
 Am Sonntag, 7. Juli 2013, 12:06:06 schrieb Tirkon:
  Für diese Erfassung benötigen wir einen neuen Tag. Dieser Tag
  soll globale_id_pt = * (IFOPT Nummer) heißen.
  
  Nummern, deren Bedeutung unter Verschluss ist, hätten
  in OSM nichts zu suchen, weil dann der Titel !!!Freie!!! Datenbank
  keine Berechtigung mehr hätte.
 
 Aua!

Warum Aua?

Ich stimme Tirkon hier voll zu.

Gruß, Wolfgang


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Einführung eines neuen Tags (globaleID)

Hallo Wolfgang,

Am Sonntag, 7. Juli 2013, 15:33:07 schrieb Wolfgang Hinsch:
   Nummern, deren Bedeutung unter Verschluss ist, hätten
   in OSM nichts zu suchen, weil dann der Titel !!!Freie!!! Datenbank
   keine Berechtigung mehr hätte.
  
  Aua!
 
 Warum Aua?

Weil die Aussage auf so vielen Ebenen falsch ist, dass es einfach nur weh tut.

Erstens ist OSM keine freie Datenbank, sondern eine freie *Geo*datenbank, d.h. 
es gibt zwangsläufig Daten, die außerhalb von OSM liegen müssen (auch wenn es 
genug Leute gibt, die das nicht einsehen). Dazu braucht es aber Möglichkeiten, 
Daten innerhalb von OSM zu adressieren.

Zweitens ist es nicht das Ziel von OSM, die Verknüpfung mit Daten in 
geschlossenen Fremdsystemen zu verbieten, im Gegenteil: die ODbL ist extra so 
geschrieben, um solche Nutzungen zu ermöglichen.

Drittens gibt es jede Menge Nummern in OSM, die genau die gleichen Kriterien 
erfüllen, und an denen sich auch keiner stößt: TMC-Codes, IBNR-Nummern, 
ICAO-Codes, …

Und viertens ist die Bedeutung der Nummer (die eindeutige Identifikation von 
Haltestellen) gar nicht unter Verschluss, die Bedeutung soll ja gerade in OSM 
eingepflegt werden.

Eckhart

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Einführung eines neuen Tags (globaleID)