Re: [Talk-de] ÖPNV: Unnötige Aufteilung in platform und stop_postion
Michael Reichert wrote: >Wenn aber z.B. eine Linie mit kurzen Zügen und eine mit langen Zügen vor >der selben Haltetafel halten, dann brauchen die beiden getrennte >stop_positions. Würdest Du mir zustimmen, dass die stop_position nur in sehr wenigen Fällen nicht aus den Positionen der Haltestellenschilder bzw. der Positionsschilder ABCDEF z.B. durch Fällen des Lotes auf den Verlauf der Routenrelation hervorgeht? Falls ja, bitte ich Folgendes zu bedenken: Das Mappen des ÖPNV geschieht derzeit sehr uneinheitlich. Eine große Mehrheit von Mappern versteht das derzeitige ÖPNV Schema mit der Aufteilung einer Haltestelle in platform und stop_position nicht. Wenn schon OSM-Füchse wie die Moderatoren des Podcastes sich nicht damit auskennen, sollte man doch schon ins Grübeln kommen. Es nützt nichts, wenn die "Diplomarbeit von Sebastian Schwarz"-Versteher ein Schema beschließen, an deren Abstimmung die große Mehrheit der Mapper nicht teilnehmen kann, weil sie deren Diskussion nicht versteht. Folglich wird das Modell nicht oder nur fehlerhaft umgesetzt. Selbst richtig gemappte Busrouten-Relationen werden dann inkonsistent, wenn der Mapper vor Ort bei Verlegung einer Bushaltestelle nur die platform aber nicht die stop_position verschiebt. Vielleicht bemerkt er auch (sofern er nicht ID nutzt) die Routen-Relation, lässt aber wegen der Komplexität dann die Finger von der Wartung. Ergo müssen die Datenjunkies beim Entwurf ihrer Schemata für die große schweigende Mehrheit der Mapper mitdenken und das Teil ergonomisch und intuitiv gestalten. Und was ist intuitiver als die Realität, in der für den Mapper nachvollziehbar der ÖPNV am Schild bzw. Wartefläche hält? Abseits vom Verständnis der Datenkonstruktion kommt noch Folgendes hinzu: Wer über 20 km mit dem Auto zu einem Bahnhof fahren muss, um von dort aus nach über zwei Stunden Zugfahrt den nächsten ICE Bahnhof zu erreichen, der fährt lieber gleich mit dem Auto zum Endziel und wird die seltene Notwendigkeit einer stop_position niemals live erleben. Dennoch ist man in der Lage, ein verschobenes Bushaltestellenschild in seinem Ort auch in OSM zu verschieben. Ich selbst kann als Landei die Teilung von Bahnsteigen durch Buchstaben nur deswegen nachvollziehen, weil ich alle zwei Jahre in München in einen in Hannover geflügelnden ICE einsteige. Was nutzt ein Modell, das zugunsten weniger Spezialfälle so komplex wird, dass es nicht funktioniert? Es geht hier also nicht um das Deprecaten eines Tags, sondern um ein Modell, das nicht nur von einer kleinen Minderheit umgesetzt werden kann. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] priority=* an railway=*
Hallo Fly, Am 2014-11-04 um 18:48 schrieb fly: > Dachte, die wären doch zu Google gegangen. > > Mentz war noch nie sehr diskussionsfreudig von Doku ganz zu schweigen. > Hier hat mal wieder eine Firma ihre Mitarbeiter*innen nicht unter Kontrolle. > > Am besten allen eine Mail schreiben und darauf hinweisen, dass so was im > Vorhinein zu diskutieren ist. http://lists.openrailwaymap.org/archives/openrailwaymap/2014-October/000157.html http://lists.openrailwaymap.org/archives/openrailwaymap/2014-October/000159.html http://lists.openrailwaymap.org/archives/openrailwaymap/2014-November/000164.html http://lists.openrailwaymap.org/archives/openrailwaymap/2014-November/000165.html http://lists.openrailwaymap.org/archives/openrailwaymap/2014-November/000166.html Viele Grüße Michael -- Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tag:highway=traffic_signals / wiki page inkonsistnet
Hey, On Di 04.11.2014 16:42 Florian Lohoff wrote: > Ich hatte mal überlegt ob man das durch eine relation lösen könnte. > > D.h. alle Signale die zu einer Kreuzung und einer Steuerung > unterliegen zu einer Relation > zusammenfassen. Damit wäre die zuordnung zu einer Kreuzung gegeben. > Dann gäbe es auch die > möglichkeit noch: > > - Ampelphasen (Wegen der statistischen 1/2 Ampelphase Wartezeit) > - Laufzeiten z.b. 8-16:00 > etc > > zu Dokumentieren. Nur so mal ins unreine gesprochen Das halte ich für einen gangbaren Weg. Meine Ideen dazu: Wenn dann die Relationen so eingesetzt werden, dass man zu einer Ampel kommt, alle anderen Ampeln der gleichen Relation auf dem Weg über die Kreuzung nicht mehr gezählt werden. Eine ähnliche Relation könnte man dann auch für Fußgänger/Radfahrer übergänge nutzen. (zweimal hintereinander "highway=traffic_signals + crossing=signals" oder "highway=crossing + crossing=signals") Im Zweifelsfall hat man dann aber mehrere Relationen pro Kreuzung. Außerdem könnte man so auch eine Grüne Welle darstellen/simulieren. Weiß jemand ob die Ideen mit dem Junction-Proposal im Widerspruch stehen? http://wiki.openstreetmap.org/wiki/Proposed_features/Junction Gruß Hubert ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] priority=* an railway=*
Dachte, die wären doch zu Google gegangen. Mentz war noch nie sehr diskussionsfreudig von Doku ganz zu schweigen. Hier hat mal wieder eine Firma ihre Mitarbeiter*innen nicht unter Kontrolle. Am besten allen eine Mail schreiben und darauf hinweisen, dass so was im Vorhinein zu diskutieren ist. cu fly Am 04.11.2014 um 18:32 schrieb Peter Czaja: > Moin, > > > mir fallen gerade Änderungen am Schienennetz auf, in denen die Firma > Mentz DV "priority=(yard | primary | switch)" an "railway=*"-Wege > anbringt. Im Wiki > > http://wiki.openstreetmap.org/wiki/DE:Key:priority > > finde ich auch die nichts zu dem value 'primary'. > > Auch unter den Modellierungsvorschlägen unter > > > http://wiki.openstreetmap.org/wiki/%C3%96V_Firma_Mentz_Datenverarbeitung_GmbH/Modellierungsvorschl%C3%A4ge > > nicht. > > Weiss jemand Näheres über das verwandte Tagging-Schema? ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Tag:highway=traffic_signals / wiki page inkonsistnet
Am 04.11.2014 um 18:31 schrieb Hubert: > Hey, > > On Di 04.11.2014 16:42 Florian Lohoff wrote: > >> Ich hatte mal überlegt ob man das durch eine relation lösen könnte. >> >> D.h. alle Signale die zu einer Kreuzung und einer Steuerung unterliegen zu > einer Relation >> zusammenfassen. Damit wäre die zuordnung zu einer Kreuzung gegeben. Dann > gäbe es auch die >> möglichkeit noch: >> >> - Ampelphasen (Wegen der statistischen 1/2 Ampelphase Wartezeit) >> - Laufzeiten z.b. 8-16:00 >> etc >> >> zu Dokumentieren. Nur so mal ins unreine gesprochen > > Das halte ich für einen gangbaren Weg. > Meine Ideen dazu: > Wenn dann die Relationen so eingesetzt werden, dass man zu einer Ampel > kommt, alle anderen Ampeln der gleichen Relation auf dem Weg über die > Kreuzung nicht mehr gezählt werden. Eine ähnliche Relation könnte man dann > auch für Fußgänger/Radfahrer übergänge nutzen. (zweimal hintereinander > "highway=traffic_signals + crossing=signals" oder "highway=crossing + > crossing=signals") > Im Zweifelsfall hat man dann aber mehrere Relationen pro Kreuzung. > Außerdem könnte man so auch eine Grüne Welle darstellen/simulieren. Dafür braucht es doch keine Relation, eine geschlossene Linie genügt vollkommen. Siehe [1],[2] und [3]. > Weiß jemand ob die Ideen mit dem Junction-Proposal im Widerspruch stehen? > http://wiki.openstreetmap.org/wiki/Proposed_features/Junction cu fly [1] https://wiki.openstreetmap.org/wiki/Proposed_features/highway%3Djunction [2] https://wiki.openstreetmap.org/wiki/Proposed_features/Tagging_for_complex_junctions_or_traffic_signals_that_are_named [3] https://wiki.openstreetmap.org/wiki/Proposed_features/highway%3Djunction ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] priority=* an railway=*
Moin, mir fallen gerade Änderungen am Schienennetz auf, in denen die Firma Mentz DV "priority=(yard | primary | switch)" an "railway=*"-Wege anbringt. Im Wiki http://wiki.openstreetmap.org/wiki/DE:Key:priority finde ich auch die nichts zu dem value 'primary'. Auch unter den Modellierungsvorschlägen unter http://wiki.openstreetmap.org/wiki/%C3%96V_Firma_Mentz_Datenverarbeitung_GmbH/Modellierungsvorschl%C3%A4ge nicht. Weiss jemand Näheres über das verwandte Tagging-Schema? Peter ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tag:highway=traffic_signals / wiki page inkonsistnet
Am 04.11.2014 um 14:20 schrieb Hubert: > Am Di 04.11.2014 13:32 schrieb Martin Koppenhoefer : > >> Richtungsangaben auf nodes, die sich auf die Richtung des ways beziehen > (und nicht z.B. auf >> Himmelsrichtungen) sind broken, nicht nur, weil nodes keine Richtung > haben, sondern z.B. auch, >> weil es ways mit verschiedenen Richtungen geben kann, die durch denselben > node laufen. Jain, forward/backward funktioniert nicht direction=* in Himmelrichtungen bzw Winkel geht sehr gut Laut wiki [1] ist die Richtung definiert als Richtung in die das Objekt zeigt. > zumindest zumindest die Begründung weil nodes keine Richtung haben ist > nachvollziehbar. Im Anderen Falle kann man ja die Ampel auf die Haltelinie > setzten. Dann hat man keine sich kreuzende Nodes. Ich setzt die Ampel meistens an den Übergang bzw an die Haltelinie bei fehlendem Übergang und gebe direction=* an. > Man müsste sich einmal mal überlegen, ob man einen Datenauswerter dabei > unterstüzen kann, zu erkennen, wieviele Ampeln zusammengehören. Zum Thema Kreuzungen gab es gerade einige Diskussion auf tagging@ und es existieren mehrere Proposal diese als Fläche zu taggen. Weiß allerdings nicht welche Software sowas schon einsetzt und in Asien geht es primär darum Kreuzungen bzw Ampeln Namen zu geben. Grüße fly [1] https://wiki.openstreetmap.org/wiki/DE:Key:direction ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Unscharfe Objekte (Bucht, Berg, Gebiet, Kanal, Meeresteil, etc)
Liebe DB-Designer, mein Englisch ist nicht so gut - vielleicht kann das ja jemand auf "talk" weitergeben, als Gedanken zu https://lists.openstreetmap.org/pipermail/tagging/2014-October/019775.html Dort wird diskutiert, ob man eine Bucht als Punkt oder als Fläche kartografieren soll ;-) für Punkt: - ist viel einfacher einzutragen - ungefähr in der "Mitte" für Fläche: - eine Bucht ist eine Fläche - nur so kann man die Ausdehnung bestimmen gegen Fläche: - unscharfe Objekte können nicht sinnvoll begrenzt werden - mapping für den Renderer: wo der Schriftzug hin soll - hierarchische Zusammenhänge erforden viele Flächen in Flächen Relationen sind noch komplizierter Gedanken dazu: _Unscharfe Objekte_ Berge, Gebirge, Buchten, Meeresteile, Meeresstrassen zw. Inseln, geogr. Gebiete, Täler, Wüsten, Sumpfgebiete, Wattgebiete, etc. sind immer unscharf, da ihre Beschreibung künstlich ist. Scharfe und unscharfe Objekte sind verschiedene Klassen. Sie sollten nie vermischt werden. Wenn wir nun beginnen, die Sicht jedes Mappers über jedes unscharfe Objekt als Linie in die DB zu schreiben, wird das höchst unübersichtlich (und mit heutigen OSM-Mitteln m.E. nicht händelbar). Abgesehen davon, dass jede Sicht immer auch gleich irgendwie "falsch" ist, denn jede Karte und jeder Bewohner/Besucher verwendet andere Namen und "Begrenzungen". Die "Küstenlinie" umzudefinieren als "Grenze einer Bucht" ist m.E. eine Klassen-Verletzung und auch sachlich nicht richtig. Um Namen auf unterschiedlichen Zoomleveln und Ausschnitten sinnvoll rendern zu können, sind bei geografischen Objekten immer hierarchische Bedeutungsunterschiede auszuwerten: Mächtigkeit, Grösse, Dominanz, Reliefenergie, Schartenhöhe/-Tiefe, ist-Teil-von, Entfernung-von (und bei Buchten: Tiefe, Besiedlung, Tourismus, Schifffahrt, Fischfang, etc). Bei Buchten ist es bei Punkten in vielen Fällen vermutlich möglich, die Ausdehnung durch Preprozessing ungefähr abzuschätzen. Vielleicht könnte man für unscharfe Objekte alternativ in der DB einen eigenen Layer machen, in dem Dinge wie "Kieler Bucht", "Ural", "Allgäu", "Golf von Aden", etc. ungefähr als Fläche eingezeichnet werden? Das könnte ganz grob gezeichnet werden und würde Grösse und Form trotzdem gut abbilden. Und dann kann der Renderer aus der Ausdehnung und der Form der unscharfen Objekte die Platzierung des Schriftzuges festlegen, jeweils für jeden Zoomlevel? Und in Vektorkarten könnte man ds sogar passend drehen? _Beipiele für Bucht_ Bucht als Punkt: http://www.openstreetmap.org/node/2681179665#map=11/53.7700/14.7670 http://osm.org/go/YdiXEQA?node=2501579651 Bucht als Fläche: http://overpass-turbo.eu/s/5CQ Meeresstrassen (gut): http://maps.imagico.de/#map=3/80.707/55.862&lang=en&l=dark&r=fj&ui=0 Meeresstrasse (willkürlich): http://www.openstreetmap.org/way/163242449 Form: http://i.imgur.com/AMigrSf.png Golf: http://1.bp.blogspot.com/_-9_Y031ZiZQ/THowBMn81dI/Ci8/inSvDDa1DC4/s1600/Golf+van+Biskaje.jpg Liste vorgängiger Diskussionen: http://wiki.openstreetmap.org/wiki/List_of_proposals_regarding_landuse,_geology,_geography_and_vegetation _Küstenzonenmanagement_ Die Hydrographischen Organisationen verschieben ihren Schwerpunkt Richtung Meeresumweltschutz, Küstenzonenmanagement und maritime Raumordnung: https://www.facebook.com/OpenSeaMap Zonen werden bezeichnet für: - Küstenschutz - Umweltschutz - Baumassnahmen - Windpark - Geschwindigkeitsbegrenzung - Zoll- und Polizei-Zuständigkeit - Fischfangbestimmungen - Artenschutz - Tourismus - Naturschutz - politische Zuständigkeiten - Wasserqualität - Abfallbeseitigung - Strömungen - Ankerplätze - Tauchgebiete - Schiessplätze - Ausgrabungsstätten etc. etc. Jede Zone hat eine Bezeichnung und weitere Attribute. _Lösungsvorschlag_ Spezieller *DB-Layer für unscharfe Objekte* Spezieller Editor (oder Tool in JOSM) Christoph kann Vergleichbares (für Buchten und Meeresstrassen) aber auch mit Preprocessing aus einem Punkt und umgebenden Küstenlinien: http://maps.imagico.de/#map=3/80.707/55.862&lang=en&l=dark&r=fj&ui=0 Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tag:highway=traffic_signals / wiki page inkonsistnet
Hola, On Mon, Nov 03, 2014 at 09:36:09PM +0100, Peter Wendorff wrote: > Ich weiß nicht genau, wie Router das momentan zählen, aber Probleme sehe > ich eigentlich höchstens bei geteilten Richtungsfahrbahnen an einer oder > beiden Straßen. Ansonsten tagge ich: > > 1) highway=traffic_signals am Kreuzenden Knoten der beiden Straßen, mit > der Interpretation: Diese Kreuzung ist (für den Hauptfahrweg) durch eine > Ampel geregelt) > 2) highway=crossing, crossing=traffic_signals an der Querung (für > Fußgänger und/oder Radfahrer), also meist leicht abseits des kreuzenden > Nodes der beiden Hauptfahrwege. So mache ich das auch - Ist ja auch am logischten jeweils auf den Nodes die beide Wege haben zu beschreiben wie die regelung der Kreuzung ist. So handhaben wir das ja auch bei anderen konstrukten. Nur in den Beispielen die von komplexeren Konstruktionen ausgehen d.h. mehrspurige Straßen wird davon abgewichen. Das führt eben zu inkonsistenzen in der interpretation der Daten. Das finde ich reichlich unschön. Ich hatte mal überlegt ob man das durch eine relation lösen könnte. D.h. alle Signale die zu einer Kreuzung und einer Steuerung unterliegen zu einer Relation zusammenfassen. Damit wäre die zuordnung zu einer Kreuzung gegeben. Dann gäbe es auch die möglichkeit noch: - Ampelphasen (Wegen der statistischen 1/2 Ampelphase Wartezeit) - Laufzeiten z.b. 8-16:00 etc zu Dokumentieren. Nur so mal ins unreine gesprochen Flo -- Florian Lohoff f...@zz.de signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tag:highway=traffic_signals / wiki page inkonsistnet
Am 4. November 2014 14:20 schrieb Hubert : > Im Anderen Falle kann man ja die Ampel auf die Haltelinie > setzten. Dann hat man keine sich kreuzende Nodes. > und man müsste verbieten, diesen way zu splitten bzw. danach die Richtung eines der ways zu ändern ;-) Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tag:highway=traffic_signals / wiki page inkonsistnet
Am Di 04.11.2014 13:32 schrieb Martin Koppenhoefer : > Richtungsangaben auf nodes, die sich auf die Richtung des ways beziehen (und nicht z.B. auf > Himmelsrichtungen) sind broken, nicht nur, weil nodes keine Richtung haben, sondern z.B. auch, > weil es ways mit verschiedenen Richtungen geben kann, die durch denselben node laufen. Hallo, zumindest zumindest die Begründung weil nodes keine Richtung haben ist nachvollziehbar. Im Anderen Falle kann man ja die Ampel auf die Haltelinie setzten. Dann hat man keine sich kreuzende Nodes. Man müsste sich einmal mal überlegen, ob man einen Datenauswerter dabei unterstüzen kann, zu erkennen, wieviele Ampeln zusammengehören. Gruß Hubert ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tag:highway=traffic_signals / wiki page inkonsistnet
Am 4. November 2014 12:49 schrieb Tom Pfeifer : > Wenn die Ampeln für verschiedene Richtungen auf dem gleichen highway > zuständig sind, könnte man :forward und :backward -Zusätze einführen. > Richtungsangaben auf nodes, die sich auf die Richtung des ways beziehen (und nicht z.B. auf Himmelsrichtungen) sind broken, nicht nur, weil nodes keine Richtung haben, sondern z.B. auch, weil es ways mit verschiedenen Richtungen geben kann, die durch denselben node laufen. Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tag:highway=traffic_signals / wiki page inkonsistnet
chris66 wrote on 2014-11-03 21:19: Am 03.11.2014 15:12, schrieb Martin Koppenhoefer: Zu der Wikiseite möchte ich anmerken, dass das hier im Falle von Abbiegern von primary auf secondary die Ampel zweimal zählt: http://wiki.openstreetmap.org/w/images/d/dc/Traffic_signals_example_3.png Mir fällt hier auch keine Ampelpositionierung ein, so dass bei jeder Abbiegung jeweils nur einem Ampel im Weg liegt. Wenn die Ampeln für verschiedene Richtungen auf dem gleichen highway zuständig sind, könnte man :forward und :backward -Zusätze einführen. Davon abgesehen sollten Navis hier etwas mehr Fuzzy Logik anwenden also z.B. eine zweite Ampel innerhalb von 10 Meter Wegstrecke nicht noch einmal für die Penalty zählen. Kreuzungsarten gibt es verschiedene. Mir fallen in Berlin einige Kreuzungen ein, die zum Queren der zweiten Richtungsfahrbahn nochmal eine Ampel haben. Die ist zwar meist synchron zur ersten, man kann aber Pech haben und hier eine weitere Phase festhängen. Biegt man an einer solchen Kreuzung mit 2x2 Richtungsfahrbahnen ab, hängt man beim Abbiegen garantiert bis zum Phasenwechsel. Tom ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tag:highway=traffic_signals / wiki page inkonsistnet
Am 3. November 2014 21:19 schrieb chris66 : > > Zu der Wikiseite möchte ich anmerken, dass das hier im Falle von > Abbiegern > > von primary auf secondary die Ampel zweimal zählt: > > > http://wiki.openstreetmap.org/w/images/d/dc/Traffic_signals_example_3.png > > Mir fällt hier auch keine Ampelpositionierung ein, so dass bei jeder > Abbiegung jeweils nur einem Ampel im Weg liegt. > mir auch nicht ;-), aber wenn man die Ampeln auf die Schnittpunkte setzte, würden sich die Fälle der doppelten Zählungen schonmal reduzieren. Als Lösung für dieses Problem bietet sich so was wie die Kreuzungsarea an, wo man dann sagen kann, das hier ist ein Stück Kreuzung, und alle sich darin befindlichen einzelnen Ampeln gelten als eine Ampelpenalty. Hier ist leider auch eine Unsitte verbreitet, Ampeln sowohl vor als auch nach der Kreuzung aufzustellen (ursprünglich vermutlich als Hilfe gedacht, wenn die Kreuzung im Stau versackt, führt es in der Praxis oft dazu, dass die Autofahrer die Haltelinie überfahren, bsp. hier: https://www.google.it/maps/@41.8546343,12.4907606,3a,75y,233.81h,92.89t/data=!3m4!1e1!3m2!1smRXbofOobr4s1B5otR5hfQ!2e0!6m1!1e1 und hier: https://www.google.it/maps/@41.856415,12.4806906,3a,75y,140.27h,81.55t/data=!3m4!1e1!3m2!1sWwpUmYUhi5JMhD3hPv436A!2e0!6m1!1e1 Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
