You are not logged in.

#1 2018-03-28 22:12:32

Nakaner
Moderator
From: Karlsruhe
Registered: 2011-09-03
Posts: 2,865
Website

Proposed features/Drop stop positions and platforms

Hallo,

Ilya Zverv hat nach seinem gescheiterten ersten ÖPNV-Taggingproposal jetzt ein neues geschrieben, das in meinen Augen das Prädikat "übersichtlich" verdient.

Das Proposal möchte public_transport=stop_position und public_transport=platform abschaffen.

https://wiki.openstreetmap.org/wiki/Pro … _platforms

Ich werde dazu morgen oder übermorgen noch etwas auf der Mailingliste Tagging schreiben.

Viele Grüße

Michael, für den das vor noch nicht allzu langer Zeit auch ketzerische Gedanken waren


Werdet Mitglied in der OSM Foundation und bestimmt über die Zukunft der Foundation und des Projekts mit. Ab 42 Mappingtagen in den letzten 365 Tagen ist es kostenlos. Jetzt beitreten ("Active Contributor Membership")!
Moderator im Bereich users: Austria

Offline

#2 2018-03-29 06:37:59

Weide
Member
Registered: 2009-04-05
Posts: 1,430

Re: Proposed features/Drop stop positions and platforms

Ich finde den Vorschlag abstrus.

Er schlägt vor, die public_transport tags optional zu machen. Nur ... das sind sie in PTv2 schon.

Er kritisiert, dass hunderte oder tausende Haltetellen schon da waren und man die nicht alle ummappen kann. Gemäß PTv2 muss man keine einzige alte Haltestelle ummappen.

Er behauptet, dass man statt eines Node jetzt mindestens zwei Objekte mappen müsste. Das ist in PTv2 nicht so.

Die Gründe für die Einführung von public_transport=stop_position und public_transport=platform kommen da überhaupt nicht vor und scheinen völlig unbekannt zu sein.

PTv2 ist da nicht wiederzuerkennen.

Offline

#3 2018-03-29 08:31:26

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

Re: Proposed features/Drop stop positions and platforms

Ich schließe mich @Weide an.

Ilya scheint ausschließlich etwas wieder entfernen zu wollen, was nicht mandatory ist.

Das, für mich alte Problem, bleibt bestehen: wie ist die Position von highway=bus_stop definiert? Neben oder auf der Fahrbahn?

Über dieses Problem geht er ganz nebenbei hinweg indem er bei public_transport=stop_position sagt:

Ilya wrote:

Bus and trolleybus     not mapped     In some regions highway=bus_stop is put on highways.

Eine Lösung biete er aber auch nicht.

Last edited by ToniE (2018-03-29 08:32:07)


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

Online

#4 2018-03-29 09:06:30

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

Re: Proposed features/Drop stop positions and platforms

Weide wrote:

Ich finde den Vorschlag abstrus.

Ich finde es steckt schon ein bisschen Wahrheit darin.

public_transport=stop_position finde ich haben sehr oft eine sehr schlechte Qualität. Meines Erachten wurden die meisten Stop-Positionen geraten oder angenommen Anhand der Plattform, aber nicht vor Ort aufgenommen. Eine Stop-Position in der Lage zu korrigieren, wenn es größere Entpfernungen sind oder um Kurven, ist meist sehr aufwendig da der Punkt auf einer Straße plaziert ist und nicht immer einfach verschoben werden kann. Sollte der Weg auch noch aufgetrennt sein kann man schon mal Stunden damit verbringen die Relationen zu begutachten und zu korrigieren oder man lässt es so. Das Tagging ist auch sehr wechselhaft.

public_transport=platform gibt es auch sehr viele Konstruktionen wo ich sage: Das hat auch nichts mehr mit der Wirklichkeit zu tun. Da werden irgendwelche Flächen und Wege gezeichnet die vor Ort noch nie gesehen habe. Im Tagging oft Doppelungen.

Am liebsten sind mir einzelne Nodes für jede Fahrrichtung die man ausführlich Taggen kann. public_transport=stop_position werd ich nicht mehr unterstützen.. das ist mir ehrlich gesagt zu blöd auf Dauer, das kann gerne wer anders machen sad

Offline

#5 2018-03-29 09:09:55

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

Re: Proposed features/Drop stop positions and platforms

ToniE wrote:

Das, für mich alte Problem, bleibt bestehen: wie ist die Position von highway=bus_stop definiert? Neben oder auf der Fahrbahn?.

Warum immer wieder diese Frage.. Antwort: neben der Fahrbahn.. ich such es nicht wieder aus dem Wiki raus: siehe highway=bus_stop

Last edited by miche101 (2018-03-29 09:13:27)

Offline

#6 2018-03-29 10:10:27

axelr
Member
Registered: 2014-03-18
Posts: 243

Re: Proposed features/Drop stop positions and platforms

Es besteht keinerlei Notwendigkeit die detaillierten Haltestellen wegzuschmeißen , wie Weide oben beschrieben hat.

Das Verständnisproblem bei Neu-Mappern besteht darin, das wir im wiki den Unterschied zwischen PTv1-Routen und PTv2-Routen nicht deutlich machen, sondern nur irgendwo Irgendetwas davon beschreiben.

iD - Editor hatte in den letzten Tagen einige Probleme mit der Reihenfolge der Haltestellen. Diese Probleme wurde aber jeweils binnen zwei Tagen gelöst. Dieser Editor ist nach meiner Meinung nicht ideal zur Bearbeitung von Routen, aber wir haben doch einige Mapper, die Routen damit korrekt erstellen und bearbeiten können.

Offline

#7 2018-03-29 10:38:51

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

Re: Proposed features/Drop stop positions and platforms

miche101 wrote:

Warum immer wieder diese Frage.. Antwort: neben der Fahrbahn.. ich such es nicht wieder aus dem Wiki raus: siehe highway=bus_stop

OK, mag sein, dass das vor längerem genauer definiert wurde.

Die Realität sieht leider anders aus, highway=bus_stop sehe ich häufig noch auf der Straße, oder machnmal sogar als way oder area neben der Straße.

highway=bus_stop ist "vom Namen" her nicht eindeutig auf oder neben der Straße (und welcher Anfänger liest schon für jeden tag das Wiki?). Hier hat public_transport=stop_position einen gewissen Vorteil: keine Historie und eindeutiger.
Verzichten könnte ich auf die stop_position aber auch.


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

Online

#8 2018-03-29 13:04:31

Weide
Member
Registered: 2009-04-05
Posts: 1,430

Re: Proposed features/Drop stop positions and platforms

miche101 wrote:

public_transport=stop_position finde ich haben sehr oft eine sehr schlechte Qualität. Meines Erachten wurden die meisten Stop-Positionen geraten oder angenommen Anhand der Plattform, aber nicht vor Ort aufgenommen. Eine Stop-Position in der Lage zu korrigieren, wenn es größere Entpfernungen sind oder um Kurven, ist meist sehr aufwendig da der Punkt auf einer Straße plaziert ist und nicht immer einfach verschoben werden kann. Sollte der Weg auch noch aufgetrennt sein kann man schon mal Stunden damit verbringen die Relationen zu begutachten und zu korrigieren oder man lässt es so. Das Tagging ist auch sehr wechselhaft.

public_transport=platform gibt es auch sehr viele Konstruktionen wo ich sage: Das hat auch nichts mehr mit der Wirklichkeit zu tun. Da werden irgendwelche Flächen und Wege gezeichnet die vor Ort noch nie gesehen habe. Im Tagging oft Doppelungen.

Am liebsten sind mir einzelne Nodes für jede Fahrrichtung die man ausführlich Taggen kann. public_transport=stop_position werd ich nicht mehr unterstützen.. das ist mir ehrlich gesagt zu blöd auf Dauer, das kann gerne wer anders machen

Was Du da sagst spricht überhaupt nicht gegen PTv2 ... nur gegen die verbreiteten PTv2-Irrtümer.

Wenn man eine Bushaltestelle mit einem Node gut beschreiben kann, dann sollte man das einfach tun. Das ist die beste Lösung. Das ist gültiges PTv2 und funktioniert ganz ohne public_transport=xxx. Das highway=bus_stop ist voll gültig in PTv2.

Nur wenn Du mehr mappen willst brauchst Du die public_transport=xxx - Tags. Z.B. ist highway=bus_stop nicht zulässig für Linien und Flächen (denn das würde PTv1-Routen kaputt machen oder anderen Mappern verbieten, dort PTv1-Routen anzulegen).

Oder: Sollte jemand unbedingt beide Möglichkeiten mappen wollen (stop_position und platform), dann darf wegen der Regeln zu highway=bus_stop nicht an beiden das highway=bus_stop stehen. Daher braucht man in dem Fall einen Ersatz und den macht PTv2 möglich.

Offline

#9 2018-03-29 13:24:25

Weide
Member
Registered: 2009-04-05
Posts: 1,430

Re: Proposed features/Drop stop positions and platforms

ToniE wrote:

Das, für mich alte Problem, bleibt bestehen: wie ist die Position von highway=bus_stop definiert? Neben oder auf der Fahrbahn?

Das ist über lange Zeit historisch gewachsen. Ganz früher (als die Straßen noch Dinosaurierspuren hatten) waren auch große Kreuzungen einfach zwei Striche mit einem gemeinsamen Punkt und an den Punkt hat man highway=bus_stop und name=soundso geschrieben, wenn es an der Kreuzung Bushaltestellen gab.

Dann waren alle highway=bus_stop auf der Straße und es brach ein Streit aus, ob man an die Nodes für eine Richtung sowas wie "dir=NW" schreiben soll oder ob man sie besser neben die Straße legen soll. Auch ein shelter=yes auf der einen Straßenseite und "no" auf der anderen war schwer auf der Straße zu mappen.

Wir sind dann eigentlich einvernehmlich dazu gekommen, dass man sie gewöhnlich neben die Straße legt.

PTv2 hat dann Linien und Flächen als Platforms neben der Straße möglich gemacht ohne PTv1 kaputt zu machen. PTv1 kann aber nur Nodes für Haltestellen. Jetzt gab es nur die Möglichkeit, bei Linien oder Flächen als platform das highway=bus_stop im Node unterzubringen. PTv1 verlangt ja genau einen highway=bus_stop-Node pro Halt ... nicht mehr und nicht weniger. PTv2 verbietet aber einen zusätzlichen Node. Also geht bei Linien oder Flächen als Platform nur das Taggen der stop_position mit highway=bus_stop und das liegt auf der Straße.

Offline

#10 2018-03-29 14:17:24

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

Re: Proposed features/Drop stop positions and platforms

Weide wrote:

PTv2 hat dann Linien und Flächen als Platforms neben der Straße möglich gemacht ohne PTv1 kaputt zu machen. PTv1 kann aber nur Nodes für Haltestellen. Jetzt gab es nur die Möglichkeit, bei Linien oder Flächen als platform das highway=bus_stop im Node unterzubringen. PTv1 verlangt ja genau einen highway=bus_stop-Node pro Halt ... nicht mehr und nicht weniger. PTv2 verbietet aber einen zusätzlichen Node. Also geht bei Linien oder Flächen als Platform nur das Taggen der stop_position mit highway=bus_stop und das liegt auf der Straße.

Man kann es sich auch so hindrehen wie man es gerne hätte. highway=bus_stop => public_transport=platform! Obwohl public_transport=platform erstmal garnichts heißt, weil da kann theoretisch alles halten..public_transport=platform + bus=yes wäre dann korrekt das Klarheit bestände. Und wenn du sagt darf man nur als node erfassen werden dann muss es getrennt gemappt werden..

public_transport=stop_position sieht kein highway=bus_stop vor, siehe Wiki.

Offline

#11 2018-03-29 14:27:35

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

Re: Proposed features/Drop stop positions and platforms

Frequent errors

    highway=platform

If you know places with this tag, verify if it could be tagged with another tag.
Automated edits are strongly discouraged unless you really know what you are doing!

https://wiki.openstreetmap.org/wiki/Tag … 3Dplatform

Jetzt wurde highway=platform als Fehler erhoben... zumindest im Englischen Teil des Wikis

Offline

#12 2018-03-29 17:03:07

Weide
Member
Registered: 2009-04-05
Posts: 1,430

Re: Proposed features/Drop stop positions and platforms

miche101 wrote:

Man kann es sich auch so hindrehen wie man es gerne hätte. highway=bus_stop => public_transport=platform!

PTv2 unterscheidet klar zwischen dem Fall in dem highway=bus_stop public_transport=stop_position entspricht und dem Fall, in dem es public_transport=platform entspricht. In beiden Fällen ist damit klar, dass man es nicht als zusätzlichen Node zu zwei bereits vorhandenen Objekten des Haltes verwenden darf. PTv2 verlangt ganz explizit, dass sämtliche stop_positions und sämtliche platforms in die Routen gehören und man kann in eine PTv2-Route keine drei Halt-Objekte reinschreiben und dabei weniger als zwei Halte des Fahrzeugs bekommen.

miche101 wrote:

Obwohl public_transport=platform erstmal garnichts heißt, weil da kann theoretisch alles halten..public_transport=platform + bus=yes wäre dann korrekt das Klarheit bestände.

Die Idee, an eine Platform bus=yes oder ähnliches zu schreiben, ist PTv2 unbekannt. Platforms gehört zu allen Linien in denen sie erwähnt werden.

Offline

#13 2018-03-30 10:29:46

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

Re: Proposed features/Drop stop positions and platforms

Ja aber wie soll z.B. eine Software damit umgehen? Wenn einmal highway=bus_stop mal hier mal dort ist? Was ist wenn die Software public_transport=platform unterstützen möchte? highway=bus_stop einfach fallen lassen? Nein geht noch nicht... weil ca. > 1 Million Objekt haben noch kein public_transport=platform getaggt. Wie gehe ich mit beiden um, in den unterschiedlichen Situationen? Verblase ich unendlich viel Rechenleistung um Umkreise abzusuchen.. tagging auszuwerten um abzuwägen was ich im Einzelfall dann zu machen ist? Wo platziere ich Symbole bei Platform-Ways, welche lat/lon verwende ich für mein Routing.. usw. usw.?

Am besten wäre highway=bus_stop + public_transport=platform als eine Node zu belassen, mit allen Informationen, und die ganzen anderen Dinge extra zu Erfassen und meinetwegen in einer Relation public_transport=stop_area zusammenzufassen.

Man sollte hier die Dinge nicht ins Unendliche kompliziert machen.. da verbaut man sich nur selbst die Dinge. Wie z.B. das es public_transport=platform nicht dargestellt werden kann im Standard-Tiles oder falsch wie bei http://www.öpnvkarte.de

mfg Miche

Offline

#14 2018-03-30 13:29:57

Weide
Member
Registered: 2009-04-05
Posts: 1,430

Re: Proposed features/Drop stop positions and platforms

miche101 wrote:

Ja aber wie soll z.B. eine Software damit umgehen? Wenn einmal highway=bus_stop mal hier mal dort ist?

Abgesehen von der Einhaltung der alten Regeln:
1.: highway=bus_stop darf nur an Nodes
2.: Zu jedem Haltevorgang des Busses gehört nur ein highway=bus_stop
ist es nicht so wild:

highway=bus_stop in einem bus-geeigneten Weg wird als public_transport=stop_position mit bus=yes behandelt und highway=bus_stop woanders wird als public_transport=platform behandelt. Das wars. Sobald man es übersetzt hat, muss man sich nicht mehr darum kümmern. Jetzt sind keine Probleme mehr da, die man ohne highway=bus_stop nicht auch hätte.

Es wird also nie highway=bus_stop fallen gelassen und es sind auch nie besondere Regeln für highway=bus_stop in verschiedenen Situationen nötig oder irgendwelche Suchen.

miche101 wrote:

Am besten wäre highway=bus_stop + public_transport=platform als eine Node zu belassen, mit allen Informationen, und die ganzen anderen Dinge extra zu Erfassen und meinetwegen in einer Relation public_transport=stop_area zusammenzufassen.

Ja, da sind wir uns fast immer einig. Fast alle über-komplizierten Konstruktionen beruhen auf Missverständnissen von PTv2. Wenn ein Node als Platform reicht, dann sollte man diesen Node mappen und das wars. PTv2 verlangt nicht, dass man eine stop_position hinzufügt oder Multipolygone als Platforms nimmt oder alles mit stop_areas zupflastert. Man kann sogar einen Node auf der Straße für beide Richtungen nehmen, wenn die Halte einander gegenüberliegen und gleich ausgestattet sind. PTv2 hat nichts dagegen.

miche101 wrote:

Man sollte hier die Dinge nicht ins Unendliche kompliziert machen.. da verbaut man sich nur selbst die Dinge. Wie z.B. das es public_transport=platform nicht dargestellt werden kann im Standard-Tiles oder falsch wie bei http://www.öpnvkarte.de

Ja. Da kommen wir zu einem echten Schwachpunkt von PTv2. Es gibt soviel Optionales beim Mappen der Haltestellen, dass man ohne Analyse aller beteiligten Routen bei einer Ansammlung von Halt-Objekten Probleme bekommt, auf Karten Symbole zu plazieren. Nur stops ist falsch, nur platforms geht auch nicht und immer beides anzuzeigen ist noch schlimmer. Deshalb ist es verbreitet, das highway=bus_stop für die Symbole zu benutzen und Namensgleichheit statt stop_areas für Haltestellen zu nehmen. (Deshalb hab ich damals das Analyseprogramm geschrieben, dass aus den Daten einer ganzen Gegend etwas von mkgmap auswertbares macht.) Da müssen wir beim nächsten Schema gut überlegen, wie man sowas vermeidet.

Die ÖPNV-Karte war unter PTv1 ideal ... einfach klasse. Mit PTv2 wurde z.B. die Ermittlung der genutzten Wegrichtungen echt schwierig. Dass man dann noch die üblichen Fehler der Mapper bei der Kartenerzeugung berücksichtigen muss, hat die Sache fast unlösbar gemacht.

Offline

#15 2018-03-31 11:08:51

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

Re: Proposed features/Drop stop positions and platforms

highway=bus_stop in einem bus-geeigneten Weg wird als public_transport=stop_position mit bus=yes behandelt und highway=bus_stop woanders wird als public_transport=platform behandelt. Das wars. Sobald man es übersetzt hat, muss man sich nicht mehr darum kümmern. Jetzt sind keine Probleme mehr da, die man ohne highway=bus_stop nicht auch hätte.

Es wird also nie highway=bus_stop fallen gelassen und es sind auch nie besondere Regeln für highway=bus_stop in verschiedenen Situationen nötig oder irgendwelche Suchen.

Man sieht es ja was so Software technisch so los ist. Viele ungelöste Probleme über Jahre hinweg.. Es bleibt immer noch bei den Versprechungen was man damit alles machen könnte.. nichts ist davon ist Realität. Der Mehrwert ist gegen null..

Wenn ich das umtagging an den Haltestellen betrachte würde ich ein minus davor setzen.


über-komplizierten Konstruktionen beruhen auf Missverständnissen von PTv2

Dann sollte das auch mal in der Dokumentation => Wiki klar dargestellt werden. Und nicht wie jetzt unterschiedlich, über viele Seiten verteilt.. mit groben Abweichungen zwischen den Übersetzungen usw.

Detail-mapping hat jeder das recht das zu machen.. aber wie setzt man das am besten um... wie schaut es mit dem tagging aus Vor-/Nachteile usw.


Die ÖPNV-Karte war unter PTv1 ideal ... einfach klasse. Mit PTv2 wurde z.B. die Ermittlung der genutzten Wegrichtungen echt schwierig. Dass man dann noch die üblichen Fehler der Mapper bei der Kartenerzeugung berücksichtigen muss, hat die Sache fast unlösbar gemacht.

Bei PTV1 hat man auch aufpassen müssen.. aber man hat nur eine Relation gebraucht und keine Vielzahl neutral

Offline

#16 2018-04-09 20:42:10

chris66
Member
From: Germany
Registered: 2009-05-24
Posts: 9,829

Re: Proposed features/Drop stop positions and platforms

Nakaner wrote:

Das Proposal möchte public_transport=stop_position und public_transport=platform abschaffen.

Hört sich für mich (als KISS Fan) erstmal gut an.
Haben die Profis (VRR, Mentz) da eigentlich schon was zu gesagt? Kann zB auf die stop-Position wirklich verzichtet werden?


Mapper aus dem Münsterland.

Offline

#17 2018-04-10 07:17:18

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

Re: Proposed features/Drop stop positions and platforms

chris66 wrote:

Haben die Profis (VRR, Mentz) da eigentlich schon was zu gesagt? Kann zB auf die stop-Position wirklich verzichtet werden?

Wenn die auf GTFS (General Transit Feed Specification) setzen als Technologie für das Routing würde ich sagen: Ja, da bräuchte man nur eine node die "Platform" wo man aus- bzw. einsteigt.

Auf der FOSSGis gab es einen schönen Vortrag dazu die sich mit dem Thema ÖPNV und OSM usw. beschäftigten und kombinierten:

Open Source Erreichbarkeitsanalysen im ÖPNV
https://media.ccc.de/v/2018-5379-ersatz … en_im_opnv

Offline

#18 2018-04-10 11:48:17

Weide
Member
Registered: 2009-04-05
Posts: 1,430

Re: Proposed features/Drop stop positions and platforms

chris66 wrote:

Haben die Profis (VRR, Mentz) da eigentlich schon was zu gesagt? Kann zB auf die stop-Position wirklich verzichtet werden?

Die haben professionell überraschenderweise nichts mit dem ÖPNV in OSM zu tun. Es werden Nodes aus den Datenbanken der Verkehrsunternehmen als Start und Ziel des Fußgängerroutings beim Umsteigen benutzt und OSM-Daten nur für die Fußwege dazwischen. Es ist für diese Anwendungen ganz egal, ob da railway=platform oder highway=footway steht und welche weiteren Tags und Relationen da dran hängen.

Ich denke, dass wir in einem PTv3 komplett auf Haltepositionen des Fahrzeugs verzichten sollten. In PTv2 hätte die Abschaffung einige üble Nebenwirkungen und die Begründung der Abschaffung bezieht sich auf Regeln, die PTv2 garnicht hat. Es gibt nur viele Mapper, die auf die im Vorschlag kritisierte Art mappen. Der Vorschlag legt den Finger auf real existierende Wunden und er sollte gelesen werden ... aber die Lösung ist nicht die Änderung von PTv2 sondern die Anpassung der Praxis an PTv2 und längerfristig ein neues Konzept.

Offline

#19 2018-04-10 13:47:45

geri-oc
Member
From: Sachsen
Registered: 2011-03-21
Posts: 5,013
Website

Re: Proposed features/Drop stop positions and platforms

Weide wrote:

Die haben professionell überraschenderweise nichts mit dem ÖPNV in OSM zu tun.

Und wieso werden dann Daten von MENTZ und VRR in OSM eingetragen oder geändert?
Auf Fehler (Gebäude im Gebäude, level Angaben, Fußwege in Gebäuden, ...) wird auch nicht reagiert.

Offline

#20 2018-04-10 14:11:11

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

Re: Proposed features/Drop stop positions and platforms

geri-oc wrote:

Und wieso werden dann Daten von MENTZ und VRR in OSM eingetragen oder geändert?
Auf Fehler (Gebäude im Gebäude, level Angaben, Fußwege in Gebäuden, ...) wird auch nicht reagiert.

Ich würde sagen für das Routing nach dem ÖPNV-Routing.. also den Fuß-/Autoweg zum und weg von der Haltestelle

Offline

#21 2018-04-10 14:11:50

d3d9
Member
From: Hagen
Registered: 2015-05-18
Posts: 77

Re: Proposed features/Drop stop positions and platforms

geri-oc wrote:

Und wieso werden dann Daten von MENTZ und VRR in OSM eingetragen oder geändert?

Siehe https://wiki.openstreetmap.org/wiki/VRR/Zusammenarbeit
Es werden vor allem Routing (Linienverläufe, Fußwege), Umgebungspläne, Linienpläne gemacht; Pläne zum Ausdrucken generiert; außerdem werden POI aus OSM in der Suche und allgemein eine Hintergrundkarte in den Apps verwendet.
Dann ist es doch auch normal, dass von denen OSM bearbeitet wird, vor allem damit die Daten besser werden.

Andersherum verwende ich deren Daten um sie mit OSM zu vergleichen und dann Fehler zu melden, das geht dann leider aber nur mit Umwegen und langen Wartezeiten, weil Daten wie Haltestellen und Steigzuordnungen ja komplett intern gepflegt werden und aus OSM nur sehr indirekt (z.B. als Hintergrundkarte) Daten dort einfließen und Fehler manuell korrigiert werden (oder auch nicht).

Last edited by d3d9 (2018-04-10 14:12:36)

Offline

Board footer

Powered by FluxBB