Re: [Talk-at] maxspeed=signals vs. maxspeed:variable=yes + maxspeed=x
Am 21.12.2014 um 18:49 schrieb Norbert Wenzel: 1) maxspeed ist eben als maximale (rechtliche) Höchstgeschwindigkeit definiert worden. Die Tatsache, dass der Wert von maxspeed in der Praxis nicht gefahren werden kann und für das Routing nicht immer passt, ist ein Problem von maxspeed selber -- und unabhängig von Signalanlagen. Versuche mit maxspeed:practical gibt es, so recht durchgesetzt hat es sich nicht (siehe letzter Absatz im Posting). Es geht mir nicht um praktische Geschwindigkeiten sondern um die rechtliche Begrenzung, die die meiste Zeit aktiv ist. [...] Keine Frage. Aber an Stellen wie dem IGL auf der A1 in OÖ bei Linz ist imo die meiste Zeit ein 100er (ab Landesgrenze NÖ/OÖ bis zum Autobahnkreuz, wo sowieso immer 100 gilt) und die Maximalgeschwindigkeit dort wäre 130. Meiste Zeit ist zwar formal gesehen ein objektiver Ansatz, er ist aber in der Praxis deutlich schwerer zu erfassen [es ist ja schon die maximale Höchstgeschwindigkeit nicht ganz unproblematisch und benötigt einige Fahrten/Beobachtungen] und mit mehr Konflikten behaftet, weil die eigenen Autofahrten leider nicht gleichmäßig über die Zeit verteilt sind. Ebenso stellt sich die Frage des Beobachtungszeitraums, gerade beim IG-L. Im Winter wird's vermutlich schlimmer sein, ebenso am Tag vs. Nacht, ebenso gibt es jahreszeitlichen Schwankungen, Monate können daher unterschiedlich sein. Leider konnte ich keine IG-L Fakten über den Abschnitt A1 bei Linz finden, aber IG-L-Anlagen sind typischerweise nur 30%-50% der Zeit aktiv [gilt das nun als meiste Zeit?]. Für den durchschnittlichen Pendler kann sich das trotzdem wie 100% anfühlen, weil der fährt ja nicht in der Nacht, Samstag oder Sonntag, sondern in der Emissionsspitze am Morgen und Abend. Für den Fall A1 bei Linz kann es aber durchaus anders sein, ich hab' leider keine Daten dazu gefunden. Es stellt sich die Frage, ob man für Spezialfälle* eine problematischere 'maxspeed' Definition in Kauf nehmen will. Meiner Meinung nach müsste man das Problem mit einer Lösung für ein Default-Routing-Geschwindigkeits-Profil anpacken [ideal mit conditionals für Zeitabhängigkeiten, etc.], wenn diese Information überhaupt in die OSM-Datenbank gehört. Am Ende wäre es viel Aufwand mit (im Verhältnis zum Aufwand) wenig Genauigkeits-Verbesserung, weil die Verwendung von Echtzeit-Verkehrsdaten solche statischen Angaben wohl immer schlagen werden, wenn es um Fahrten im Berufsverkehr geht, bei denen eben die Fahrtzeit ein wichtiger Aspekt ist. OSM ohne weitere Datenquellen wird wohl auf absehbare Zeit mit machbarem Aufwand nur für Schönwetter-Sonntagsfahrten realistische Werte liefern können. * in Österreich, international muss das nicht so sein, aber alle Diskussionen und RFCs haben in der Richtung noch nichts ergeben. Gruß martinq Off-Topic: Ich bin beim Recherchieren auf folgenden Fun-Fact gestoßen: Ohne IG-L ist die tatsächlich gefahrene Durchschnittsgeschwindigkeit von PKWs 123 km/h, mit IG-L dem 100er 113 km/h... ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] maxspeed=signals vs. maxspeed:variable=yes + maxspeed=x
Meiner Meinung nach ist maxspeed:variable dem Tag maxspeed=signals deutlich überlegen, da es nicht nur die Information liefert, dass das Geschwindigkeitslimit variabel ist, sondern zusätzlich: * das höchste mögliche(!) Geschwindigkeitslimit * den Grund(!) für das variable Limit Ok, der Grund steht zumindest in AT manchmal dabei, zumindest beim IGL. Aber in den anderen Fällen und vor allem bei der Maximalgeschwindigkeit die angezeigt werden kann, kann ich mir als normaler Mapper, der selten Autobahnen mapped, eigentlich nicht erklären, wo die Daten herkommen sollen. [...] als wären das Daten, die ein Mapper vor Ort nicht mehr einfach nachvollziehen kann. Natürlich sind die Daten (der Hauptgrund für Änderung der Geschwindigkeit) Vor-Ort durch Beobachtung überprüfbar, nur nicht bei einem einzelnen Kurzbesuch. Aber praktisch jeder Ortskundige oder Berufsfahrer kann die Daten bestätigen, immerhin stehen die Dinger ja auf Hauptverkehrsrouten und nicht auf Feldwegen, wo wir schon froh sind, wenn da überhaupt 'mal ein Mapper vorbeikommt. Im übrigen bleibt der Wert yes als Option, wenn man eine neue Anlage einträgt und nicht ortskundig ist. Die fehlende Überprüfbarkeit bei einem einzelnen Besuch gilt im übrigen auch für highway=primary, secondary, tertiary, das kann man ohne Ortskenntnisse Vor-Ort (zB bei einem Sonntagsbesuch in einem ländlichen Ort als Gelegenheitsmapper) auch nicht wirklich überprüfen. Ortskundigkeit wird bei manchen Tags in OSM benötigt. Aus meiner Sicht gibt es genügend Mapper - viel mehr als bei manch anderen Tags - die gemachte Angaben verifizieren können, daher ist doch eher eine akademische Diskussion über Regeln, die solche Projekte oft ersticken. In einem Community-Projekt benötigt es auch manchmal Pragmatismus, am Ende zählt doch ob falsche Daten durch genügend Mapper erkannt werden können -- und das ist hier aus meiner Sicht gegeben. martinq ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] maxspeed=signals vs. maxspeed:variable=yes + maxspeed=x
maxspeed=signals wird über 5000x verwendet, ist also in use und muss daher im Wiki dokumentiert bleiben. +1 Es liegt ungefähr gleich auf mit maxspeed:variable=*, und vermutlich stammt ein guter Teil dessen von dir... Schon die geografische Verbreitung spricht dagegen: https://taginfo.openstreetmap.org/keys/maxspeed%3Avariable#map Das steht schon auf etwas breitere Basis, maxspeed=signals war bei vielen nicht sonderlich beliebt, daher wird der Vorschlag auch gerne übernommen. Wenn du das Proposal gut findest, solltest du den Autor dazu bewegen, es einer Abstimmung zuzuführen. Schleißlich gibt es seit etwa 1 Jahr keine Veränderung oder Diskussion mehr an diesem Proposal. Ja, der korrekte Weg - nach geltenden Richtlinien - wäre eine Abstimmung und anschließend die Änderung der maxspeed-Seite mit dem Hinweis, dass maxspeed=signals als veraltet gilt. Die RFC-Phase gab's ja schon. Das Alter eines Proposals oder dessen letzte Änderung sagt hingegen nix über Akzeptanz und Verbreitung aus. Ich finde, dass weder die eine noch die andere Möglichkeit optimal ist. maxspeed=signals allein fehlt die Information über die Maximal- bzw. Normalgeschwindigkeit, und maxspeed:variable=* fehlt die Information, wie die Geschwindigkeit angezeigt wird. Die Werte von maxspeed:variable=* taugen mir ebenfalls nicht. Also ich sehe schon einen bedeutenden Unterschied, ob die Information über die Maximalgeschwindigkeit in einem Tag für die Maximalgeschwindigkeit fehlt oder ob eine nebensächliche Information, wie etwas angezeigt wird (LED, Prismawender?) fehlt. Wenn es Interessenten für die Art der Anzeige gibt, dann würde ich maxspeed:variable:type=led,prism,etc vorschlagen. Ursprünglich war nur =yes vorgesehen, und solche Tags weisen immer darauf hin, dass der Key besser ein Value sein sollte. -1 In manchen Fällen gibt yes diesen Hinweis vielleicht, immer aber sicher nicht. Ich erinnere zB an oneway=yes. Anstelle von yes tritt bei vielen Tags öfters eine zusätzliche Hauptinformation, statt highway=yes (das ist eine Straße) hat man sich dazu entschieden, die Bedeutung zu integrieren (mit den OSM-üblichen Zusatz-Hacks). Bei maxspeed:variable ist eben der Vorschlag, statt yes direkt einen Hinweis über den Grund und damit implizit über die Häufigkeit zu geben. maxspeed:variable unterscheidet sich daher vom Konzept nicht von vielen anderen etablierten OSM-Tags. Den Grund (peak_traffic usw.) anzugeben ist Kaffeesudleserei. Nirgends ist ersichtlich, in welchen Fällen die Geschwindigkeit herabgesetzt wird. Bitte dem Grundsatz we map what we see treu bleiben. Auf der A2 und der Südosttangente wird die Geschwindigeit mittels Anzeigen oft bei viel Verkehr herabgesetzt, aber auch bei Baustellen, Unfällen, Geisterfahrern... Nicht alle Gründe sondern primär der Hauptgrund. Der ist bei der Tangente offensichtlich peak_traffic und diese Information kann jeder Ortskundige (in diesem Fall - und generell bei Hauptverkehrswegen mit Verkehrsbeeinflussung - sehr viele) bestätigen. Mir würde besser gefallen: maxspeed=80 + maxspeed:type=signals Der Wert signals impliziert schon, dass sich die Anzeige ändern kann. Ich kann jetzt - außer den unterschiedlichen Bezeichnern - keinen inhaltlichen Unterschied zwischen maxspeed=80 + maxspeed:type=signals und dem vorgeschlagenen maxspeed=80 + maxspeed:variable=yes erkennen. Nur lässt maxspeed:variable eben Raum gleich direkt für detaillierte Angaben - wenn man so will. Das entspricht einem lange gebräuchlichen Ansatz in OSM. Natürlich hätte man auch maxspeed:variable=prism, maxspeed:variable=led, etc nehmen können, aber ein Hinweis auf die Häufigkeit (nur fallweise, meistens der gleiche Wert oder tägliche Änderung bei peak_traffic) wurde als die wichtigere Information erachtet. Auch maxspeed=signals ließe sich reparieren, indem man mit einem Zusatztag eine konkrete Zahl angibt, z.B. maxspeed=signals + max_maxspeed=80. Möglich, aber sinnvoller wäre es, den Murks zu beseitigen, dass im Tag für die maximale Höchstgeschwindigkeit genau diese Information nicht zu finden ist. Wir reden hier von einer Schlüssel/Wert-Kombination, die noch nicht millionenfache Verbreitung gefunden hat, daher ist aus meiner Sicht die geplante Umstellung vertretbar. Im übrigen hatte maxspeed=signal schon schlechte Akzeptanz, viele Tunnelstrecken mit variabler Anzeige waren einfach mit der zu 99% geltenden Geschwindigkeit und nicht mit signals gekennzeichnet. Die neue Möglichkeit legalisiert diesen Ansatz und erlaubt es, die signals-Information nun trotzdem zu taggen. Gruß martinq ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] maxspeed=signals vs. maxspeed:variable=yes + maxspeed=x
Wenn wir hier von Pragmatismus reden, warum wird dann die Höchstgeschwindigkeit erfasst, die die Signalanlage erlaubt? Zugegeben, ich fahr nicht viel Auto, aber mir fallen da durchaus Abschnitte ein, da kommt die tatsächlich einstellbare Höchstgeschwindigkeit praktisch nie zum Zug. 1) maxspeed ist eben als maximale (rechtliche) Höchstgeschwindigkeit definiert worden. Die Tatsache, dass der Wert von maxspeed in der Praxis nicht gefahren werden kann und für das Routing nicht immer passt, ist ein Problem von maxspeed selber -- und unabhängig von Signalanlagen. Versuche mit maxspeed:practical gibt es, so recht durchgesetzt hat es sich nicht (siehe letzter Absatz im Posting). In den überwiegenden Zahl von Fällen wird die maximale Höchstgeschwindigkeit für das Routing aber nicht so schlecht funktionieren, besonders auf Autobahnen in urbanen Gegenden, wo häufig 130 niemals erlaubt ist, sondern eher 100 oder sogar nur 80. Gerade dort sind auch Signalanlagen häufig. Einzelne Ausnahmen machen es trotzdem noch zu einer Verbesserung. 2) Die maximale erlaubte Höchstgeschwindigkeit ist kein Schätzwert und wird auch nicht von der Verkehrsleitzentrale frei vergeben, sondern (so wie alle Verkehrszeichen) gesetzlich verordnet. - Daher gehört auch nicht der Wert hinein, der mit der Anlage technisch maximal möglich ist. Jeder, der solche Abschnitte halbwegs regelmäßig fährt, kann mit fast absoluter Sicherheit den richtigen (verordneten) maximalen Wert nennen. Als Gelegenheitsmapper und Wenigfahrer sieht man das vielleicht etwas anders oder skeptisch, es ist aber kein praktisches Problem: Auf der SÖ-Tangente gilt maximal 80, da gibt es keine Zweifel von Ortskundigen - und es muss auch keiner eine Verordnung rauskramen. Beim Tradenbergtunnel gilt maximal 100, da gibt es auch keine Zweifel von Leuten, die dort öfters fahren. Weiteres Beispiel: Es gilt nun auf Teilabschnitten der Inntalautobahn immer IGL 100, weil neuerdings so verordnet, obwohl mit der Anlage die Beschränkung auch aufgehoben werden könnte -- maxspeed=100. Ortskundige Tiroler werden das sehr wohl wissen, ging ja auch durch die Medien. Die dazugehörige Verordnung https://www.tirol.gv.at/fileadmin/themen/umwelt/umweltrecht/LGBLA_TI_20141118_145.pdf musste dazu kaum jemand studieren... Wäre es da nicht sinnvoller, wenn es die Community dafür gibt, die das korrekt und richtig mapped, die erwartbare Geschwindigkeit zu mappen? Was interessiert mich denn die mögliche Höchstgeschwindigkeit, wenn die an vermutlich nichtmal an einem Drittel der Tage im Jahr erreicht wird? Siehe oben, meiner Meinung nach ein anderes Problem - zugegeben noch ohne Lösung, außer dem maxspeed:practical-Versuch. Wenn man hier eine Chance sieht etwas anderes (praktisches) mit zu erfassen, weil man die Signalanlagen sowieso angreifen muss, dann kann man ja maxspeed:variable:typical andenken [diese Idee hat aber viel Konfliktpotential, denn was ist schon typisch?]. Ich sehe das aber als getrenntes Proposal. Schöner wäre es, das maxspeed-Problem (Geschwindigkeit in der Praxis nicht erreichbar) allgemeiner in den Griff zu bekommen. Bedarf und willige Mapper gäbe es genug, nur will sich mittlerweile keiner mehr die Proposal-Voting-Hölle antun [viel Arbeit, noch mehr Nörgler, wenig Ehr']. Die fuzzy-Komponente lässt ja schon vorab auf heftige Diskussionen schließen (die Schläglöcher stören doch mein SUV nicht..., aber mit meiner Rickshaw..., ich fahr' nur bei Nacht und für mich..., mit meinem Bus..., da ist aber häufig Nebel...). Gruß martinq ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] maxspeed=signals vs. maxspeed:variable=yes + maxspeed=x
Das Alter eines Proposals oder dessen letzte Änderung sagt hingegen nix über Akzeptanz und Verbreitung aus. Aber es sagt was darüber aus, ob es reif für die Abstimmung ist. Ich mag es nicht, wenn ein Proposal nur 2 Wochen lang RFC ist und dann schon abgestimmt wird. Das ist Überrumpelungstaktik. In Fall von maxspeed:variable=* besteht das Proposal schon lang genug, es hatte jeder genug Zeit sich an der Diskussion zu beteiligen (auch wenn ich es nicht getan habe, Asche auf mein Haupt). Darum gibt es keinen Grund, noch länger zuzuwarten. +1 Ich finde, dass weder die eine noch die andere Möglichkeit optimal ist. maxspeed=signals allein fehlt die Information über die Maximal- bzw. Normalgeschwindigkeit, und maxspeed:variable=* fehlt die Information, wie die Geschwindigkeit angezeigt wird. Die Werte von maxspeed:variable=* taugen mir ebenfalls nicht. Also ich sehe schon einen bedeutenden Unterschied, ob die Information über die Maximalgeschwindigkeit in einem Tag für die Maximalgeschwindigkeit fehlt oder ob eine nebensächliche Information, wie etwas angezeigt wird (LED, Prismawender?) fehlt. Wenn es Interessenten für die Art der Anzeige gibt, dann würde ich maxspeed:variable:type=led,prism,etc vorschlagen. maxspeed=* steht eigentlich nicht für die Maximalgeschwindigkeit, sondern für die Geschwindigkeitsbeschränkung. Wenn du in dem Tag genau das drin haben willst, musst du eigentlich maxspeed=signals bevorzugen. maxspeed=80 ist falsch, wenn die Geschwindigkeitsbeschränkung nicht immer 80 ist. So klar ist die Sache bezüglich Geschwindigkeitsbegrenzung nicht. Die einzige Referenz, die wir haben, ist (leider) das Wiki. Da wird viel rumgefummelt und manchmal lässt sich auch nicht mehr rekonstruieren, wie etwas ursprünglich gemeint war. Trotzdem habe ich mir die Arbeit angetan: Die aktuelle Beschreibung lautet: The maxspeed=* tag is used to define the *maximum* legal speed limit... Diese Formulierung sagt tatsächlich maximale Geschwindigkeitsbeschränkung und nicht Geschwindigkeitsbegrenzung. Jetzt habe ich ein bisschen weiter recherchiert: Diese Formulierung wurde erst am 1.1.2012 eingeführt (lange vor dem Proposal, das war also nicht der Anlass), davor war es maximum speed that is allowed. Das lässt durchaus auch Raum für Interpretation. Wenn mich jemand fragen würde: Welche Geschwindigkeit ist auf der Tangente maximal erlaubt?, dann sage ich 80, auch wenn manchmal 60 gilt. Die deutsche Übersetzung ist da recht nah an dieser ursprünglichen Formulierung rechtlich angeordnete maximal zulässige Geschwindigkeit. Auch hier würde ich sagen, auf der Tangente ist 80 die 'rechtlich angeordnete maximal zulässige Geschwindigkeit'. Aus meiner Sicht ist das aber irrelevant, die Frage ist doch, gibt es ein Problem mit der aktuellen (englischen) Definition? Wenn nein, dann gibt es mit maxspeed:variable auch keinen Konflikt. Die Information, wie eine Geschwindigkeitsbeschränkung vermittelt wird, ist vielleicht für Router nicht wichtig, für andere Anwendungen und vor allem für die Wart- und Überprüfbarkeit der Daten sehr wohl. Darum gibt es dafür schon länger source:maxspeed=* bzw. synonym maxspeed:type=*. Und genau da passt nun auch der Wert signals hinein. Ob die Anzeige auf LED oder Prisma basiert, darum geht es mir nicht, denn das ist so bedeutsam wie ob ein Verkehrszeichen auf einer Alu- oder einer Eisenstange steht. ;-) Dachte ich mir doch, dass ich etwas falsch verstanden habe. Ich wollte auch schon etwas wie Was interessiert es mich, ob ein Schild aus Alu oder Eisen ist schreiben... Impliziert die Verwendung von maxspeed:variable nicht bereits, dass eine Signalanlage vorhanden ist? Wenn es hier nicht-exotische Ausnahmen gibt (zB einer geht regelmäßig durch und dreht Metallschilder manuell), dann sollte man wirklich noch ein maxspeed:type=signals andenken. Gruß martinq ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Karte zur Gebäudeabdeckung in Österreich
Hallo! http://osm-austria-building-coverage.thomaskonrad.at/ Die Seite ist wirklich sehr gut gemacht, da steckt sicher schon einiges an Freizeit drinnen. Eine Kleinigkeit bei der Karte: Mir sind seltsame Geistergebäude aufgefallen: http://osm-austria-building-coverage.thomaskonrad.at/map/#16/48.3852/16.5243 Dort befindet sich ein Friedhof, in basemap sind dort (bis auf das südliche Ende) keine Gebäude eingezeichnet. In der Vergleichskarte sind aber rote Spuren entstanden. Der Erkennungsalgorithmus muss hier eventuell etwas besser eingestellt werden. [...] Falls jemand Ideen hat, wie man das am besten „vermarktet“, damit es auch möglichst viele Mapper motiviert, an der Situation etwas zu ändern, dann habe ich dafür ein offenes Ohr! :) Für Gebiete ohne Gebäude ist das sicherlich motivierend und hilfreich. Wir man aber Neumapper (in neuen Gebieten ohne Gebäude) erreicht, ist aber eine grundlegende Frage bei OSM. Bei fast vollständigen Gebieten kann durch eine Prozentjagd ein negativer Effekt eintreten, weil ein noch höherer Prozentwert (ab ca. 80% je nach Gebiet) nicht notwendigerweise höhere Qualität sondern nur eine genauere Basemap-Kopie (mit allen Fehlern!) bedeutet. Gerade in Niederösterreich ist basemap teilweise recht veraltet und/oder ungenau. Obwohl ich Wolkersdorf und Katastralgemeinden fast vollständig erfasst habe (eventuell einige kleinere Nebengebäude in Gärten*, drei größere Neubauten fehlen noch), liegt der Wert bei nur 81,6% -- Tendenz sogar fallend (weil basemap immer mehr veraltet und es recht rege Bautätigkeit gibt). Das ist kein Fehler deiner Auswertung und auch keine Beschwerde, es zeigt aber, dass man vor einer reinen Prozent-Optimierung durch basemap-Abmalen auch klar warnen muss. Schöne Grüße martinq * Diese Nebengebäude sehe ich etwas kritisch, weil man hier auf Privatgrund oft nicht on the ground prüfen kann und stattdessen von nicht ganz aktuellen Luftbildern abzeichnet. Es stellt sich auch die Frage, ob diese Nebengebäude längerfristig aktuell gehalten werden können. ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Karte zur Gebäudeabdeckung in Österreich
Hallo, Hm ja, ich seh’s gerade. Das Problem hier ist, dass die Fläche einen leicht rötlichen Ton hat und damit teilweise noch innerhalb der Toleranzwerte für die Gebäudefarbe ist. Ich denke ich werde die Toleranzwerte nur dann ausbessern und alles neu berechnen, wenn das zu größeren Problemen in ganz Österreich führt. In der Umgebung tritt das Problem auch bei anderen Friedhöfen auf (die offensichtlich diesen ungünstigen Farbton für die Landnutzung verwenden). Das Problemchen wirkt sich aber höchstens im Zehntel-Prozentbereich aus. In Anbetracht anderer Ungenauigkeiten kann man diese Miniabweichung bei den wenigen Friedhofs-Flächen (bezogen auf die typische Gemeindefläche) auch einfach ignorieren. Ich brauch' deshalb keine Neubewertung. Aus genau diesem Grund steht in der gelben Box auf der Startseite: [...] Oha. Da kann man ja weiterscrollen :-)) So ist es in Ordnung. Gruß martinq ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Mapillary
Die Fotos könnte ich für einiges gebrauchen, aber leider sind praktisch alle Schilder verpixelt, z.B. [1]. Kann man die Ersteller der Fotos irgendwie kontaktieren um an die Originalfotos ohne Verpixelung ranzukommen? Die Pixelung kann man bei Mapillary (mittlerweile) bearbeiten, bespielsweise falsche Pixelung entfernen oder nicht erkannte Personen/Gesichter verpixeln. Man muss allerdings angemeldet sein. Bei Bild [1] war schon jemand schneller (blur request in progress). [1] http://www.mapillary.com/map/im/bInKjKWn4DMQwZxqqsWq1Q Gruß martinq ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Tagging: Straßen auf der Donauinsel
Gegen highway=cycleway spricht, dass die Wege nicht mit blauem Lolly beschildert sind (oder sind sie das?). Dafür spricht, dass sie praktisch als Radwege genutzt werden. Mit dem (ehrlichen) Ansatz dreht man sich im Kreis. Zur Illustration: Gegen footway spricht, dass die Wege nicht mit blauem Lolly beschildert sind. Dafür spricht, dass sie praktisch als Fußwege genutzt werden -- Also highway=footway + bicycle=yes? Die Wege auf der Donauinsel haben keine klare Nutzung (mein Wissenstand). Sowohl footway als auch cycleway unterstellen aber eine bevorzugte Benutzung. Darum benutze ich auch highway=path in solchen Fällen. Die Renderer sollten ohnehin das surface-Tag besser einbeziehen (gilt auch für cycleway und footway - zB asphaltiert und nicht asphaltiert andere Strichtyp auf der Karte). Wenn es auf bestimmten Abschnitten Wege gibt, bei denen Radfahrer klar überwiegen, spricht auch nix gegen cycleway. Ein in 2 Richtungen befahrbarer Radweg muss aber ebenfalls eine gewisse Mindestbreite aufweisen. Das grundsätzliche Problem, dass in den Tags verschiedene Eigenschaften vermengt werden, hat Stefan schon angesprochen. Zu 90% fährt man ja trotzdem ganz gut mit dem Eigenschafts-Mischmasch. Für die restlichen Fälle ist - ich wiederhole mich - highway=path mit expliziten Attributen vorgesehen. Aber: nachdem ich das Gefühl habe, dass die 2 Lager (track vs. cycleway) ungefähr gleich groß sind könnten wir ja einfach die klaren Attribute ergänzen. -1 track ist das einzige, das definitiv nicht passt. Es ist kein Weg, der primär landwirtschaftlich (englisches Wiki) bzw. land- und forstwirtschaftlich (deutsches Wiki) genutzt wird. akzeptiert zu werden, aber wieso eigentlich? In der Wiki steht sogar in fett, dass tracks Roads for agricultural use sind. Danke für den Hinweis. Da hat jemand im Wiki herumgepfuscht. Gehört korrigiert. Da hat niemand rumgepfuscht, zumindest laut History. Sowohl auf der englischen als auch auf der deutschen Wiki-Seite ist hauptsächlich landwirtschaftlich schon seit Beginn Teil der Definition. Man kann sich auf den Standpunkt stellen, dass die unasphaltierten Wege nicht als Radweg zu gebrauchen sind und daher nur track übrig bleibt. 1. gibt es ausgeschilderte, aber unasphaltierte Radwege, für die cycleway genutzt wird. Dh. das surface-tag muss/müsste man bei Routenplanung/Radfahrkarte ohnehin schon berücksichtigen. Außerdem fährt nicht jeder mit dem Rennrad. 2. gibt es auch highway=path, das besser passt als track. Für die Forst- und Landwirtschaft sind die Wege ja definitiv nicht vorgesehen. Das Illustrations-Foto auf der path-Wiki-Seite ist leider grauenhaft, weil es die (unglückliche) Assoziation highway=path = Pfad = Trampelpfad noch verstärkt. Ein Parkweg wäre vielleicht passender. Auch wenn gerade noch eine Fahrzeug von der Breite passt, solange man umgangsprachlich von einem Weg spricht, und 2-spurige Fahrzeuge nur die Ausnahme darstellen, kann man highway=path durchaus mit gutem Gewissen verwenden. martinq ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Tagging: Straßen auf der Donauinsel
Am 10.04.2013 23:38, schrieb Friedrich Volkmann: On 10.04.2013 21:40, martinq wrote: Gegen footway spricht, dass die Wege nicht mit blauem Lolly beschildert sind. Dafür spricht, dass sie praktisch als Fußwege genutzt werden -- Also highway=footway + bicycle=yes? Im Zweifelsfall immer das Höherrangige, also cycleway statt footway. Aha, den Ansatz kannte ich noch nicht. So einfach kann es aber nicht sein, dann dann wäre nämlich jeder Weg, auf dem Radfahren erlaubt ist, ein cycleway. Wieso soll cycleway überhaupt höherrangig sein? Das ist doch keine Abstufung wie bei primary, secondary... Die Wege auf der Donauinsel haben keine klare Nutzung (mein Wissenstand). Sowohl footway als auch cycleway unterstellen aber eine bevorzugte Benutzung. Darum benutze ich auch highway=path in solchen Fällen. Es ist schon klar, dass path ursprünglich für alles gedacht war und verwendet wurde. Das hat sich aber geändert. Ob das gut ist, sei dahingestellt. Aber du kannst die Zeit nicht zurückdrehen! Wir sollten halbwegs einheitlich taggen, also path nur noch für Pfade. Ich bin mir nicht sicher, ob dieser alte Konflikt wirklich gelöst ist. Das es im deutschsprachigen Raum von vielen als Pfad verwendet wird (false friend), ist klar. Am Ende geht es ohnehin nur um sehr wenige Wege, die sich eben schlecht in footway oder cycleway pressen lassen. Darum wird das Problem auch nie wirklich gelöst. == Wenn es nun aber angeblich Konsens gibt, dann sollte das über die tagging-Liste im Wiki geändert werden. Ich leg' mich da sicher nicht quer, und passe die paar Wege, die es betrifft, an die neue Interpretation an. Wenn es auf bestimmten Abschnitten Wege gibt, bei denen Radfahrer klar überwiegen, spricht auch nix gegen cycleway. Auf den Anteil kommt es nicht an, sonst wären die meisten Bundesstraßen motorway und manche Landstraßen cycleway. Und manche Wege, wo Radfahren verboten ist, wären ebenfalls cycleway. Da hinkt irgendwas. Meine Aussage galt nur für die Entscheidung zwischen footway cycleway. Und klar spielt der Anteil eine Rolle, denn die Regel höherrangig eignet sich nicht als (alleiniges) Unterscheidungskriterium: Da müsste es viel mehr cycleways geben, nämlich sobald Fahrräder auch nur erlaubt sind. Nein, in der ersten Version lautete die Definition: unpaved/unsealed roads for agricultural use; gravel roads in the forest etc. Unscheinbar, aber bedeutend, ist das etc. !! Ich hatte schon die korrigierte Version gelesen - und habe gegen einige ältere Versionen verglichen, aber *nicht* die Vorletzte... Klar könnten Renderer auch surface, smoothness usw. auswerten. Ich kenne aber keinen, der das tut. Einer der Gründe dürfte sein, dass diese Tags selten gesetzt sind. highway=* ist hingegen immer gesetzt. Das übliche Problem: Wenn etwas nicht gerendert wird, wird es auch nicht getaggt. Und weil es keiner taggt... Die fehlende Auswertung von 'surface' entwertet die Karten auf jeden Fall. Dabei würde sich durchgezogene (für paved und ähnliche) vs. strichlierte Linie gerade zu aufdrängen. Es ist definitiv eine Information, die für viele Kartenanwender interessant ist! Ich sehe das nicht als Thema für Spezialkarten. Und das taggen von Fahrradwegen als track, bloss weil sie nicht asphaltiert sind, grenzt schon an Taggen für den Renderer. Auch der schleichende Bedeutungswandel von 'path' (zusätzlich zur schlechten Übersetzung als Pfad) lässt sich damit erklären: Damit konnte man endlich auf der Karten der Standard-Renderer schön sehen, welche Wege gatschig sind (path nur als Trampelpfade) bzw. welche ordentlich asphaltiert (footway) sind. Darum fühlt sich vielleicht auch die Trampelpfad-Fraktion auch viel mehr von 'path' für andere Wege gestört, weil so das Rendering nicht mehr passt. Umgekehrt gibt es den Effekt nicht so (mehr die Daten-Fokusierten, die den Renderern mehr Zeit geben). Für cycleway und track scheint nun der gleiche Prozess einzusetzen (weil man die wichtige Info sonst nicht sieht). Es wird Zeit für die Renderer, endlich surface einzubeziehen, sonst gilt bald: Fahrradwege, die gatschig sind: track - sonst cycleway... martinq ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Tagging: Straßen auf der Donauinsel
Am 10.04.2013 22:02, schrieb Stefan Kopetzky: Auch wenn gerade noch eine Fahrzeug von der Breite passt, solange man umgangsprachlich von einem Weg spricht, und 2-spurige Fahrzeuge nur die Ausnahme darstellen, kann man highway=path durchaus mit gutem Gewissen verwenden. Kann man eh, nur leben halt Tags generell davon, wie sie in der Praxis eingesetzt werden und da ist deine Ansicht klar die Minderheitsmeinung (vs. Trampelpfadansatz). Naja, in Wien vielleicht, aber versuche die Meinung auf der internationalen tagging-Liste durchzusetzen - beziehungsweise die Wiki-Seite entsprechend zu ändern... Also klar die Minderheitsmeinung steht zumindest genauso im Wiki. Von schmal als Grundvoraussetzung steht bei 'path' nämlich nix. Aber ich stelle meine Meinung deshalb nicht über die lokale Interpretation oder spreche von einer Minderheitsmeinung der Wiener - auch weil das Wiki-System bekanntermaßen so seine Mängel Problemchen hat. Objektiv betrachtet: Generell gibt es vermutlich sehr wenige Grenzfälle von breiten Wegen wie diesem, wo man sich überhaupt diese path-Frage stellen muss: Denn üblicherweise passt footway oder cycleway ganz gut, bzw. es sind tatsächlich schmale Wege, die sich mit der path=Trampelpfad-Interpretation und auch mit der path=Weg-Interpretation deckt. ABER: Es besteht zumindest Konsens, den Grundtag mit Zusatzattributen zu ergänzen. Langfristig glaube ich ohnehin, dass sich Straßen und Wege mit mehr, aber dafür eindeutigeren, Attributen durchsetzen wird. Die großen Tags wie cycleway, track, etc. sind einfach zu oft uminterpretiert und lokal eingefärbt worden, und haben damit nur mehr begrenzte Aussagekraft. Somit spielt die Grobklassifizierung, um die es hier im Grunde geht, hoffentlich eine immer geringere Rolle. Manchmal muss man eben Wissen, ob etwas asphaltiert ist - und nicht wer es hauptsächlich benutzt... Dann sollte man eben das surface-Attribut auslesen können, und nicht kompliziert aus Grobklassifikation, Annahmen und geschätzter, praktischer Verwendung darauf schließen müssen. Für mich impliziert highway:path schon etwas, wo man mit 2-spurigen üblicherweise nicht fahren kann. Fahren kann ist nicht Fahren darf ist nicht, wie im Wiki, nicht dafür gedacht (so steht's im Wiki, englisch not intended). Ist eher eine Interpretation, die aus der (irreführenden) Übersetzung als Pfad stammt. Weil es aber naheliegend ist, gibt es diese Interpretation im deutschsprachigen Raum sehr häufig. Die Wege sind aus meiner Sicht nicht dafür gedacht, auch wenn es möglich ist, darauf mit dem Auto zu fahren. Darum nennt man sie auch Wege und nicht Straßen. Aber ich wiederhole mich - schon wieder. Ich sehe die Sache im Grunde ohnehin als gelöst an: 'track' ist OK. Wird ohnehin schon oft eingesetzt, wo es gar nicht um land- oder forstwirtschaftlichen Verkehr geht. + ein paar Zusatzattribute dran, fertig. Oder wir lassen cycleway - mit ein paar Zusatzattributen dran. Auch OK. Oder wir machen footway draus - mit ein paar Zusatzattributen dran. Wär' auch nicht total falsch. Nur möchte ich nicht, dass man 'path' - mit ein paar Zusatzattributen! - hier als minderwertige Lösung darstellt, die angeblich schlechter passt und keiner verwendet. Nur unclassified find' ich unpassend, die Wege nennt keiner Verbindungsstraße. martinq ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Tagging: Straßen auf der Donauinsel
Und das taggen von Fahrradwegen als track, bloss weil sie nicht asphaltiert sind, grenzt schon an Taggen für den Renderer. Unglücklich formuliert: Das war keine Antwort auf eine direkte Aussage im Post von Friedrich Volkmann, sondern war mehr eine bestimmte Tendenz in der Diskussion bisher. Die Wege auf der Donauinsel sind nicht unterschiedlich beschildert, trotzdem sind manche cycleways und manche tracks. Außer der Oberfläche gibt es keinen Unterschied. Auch hier geht die Tendenz in die Richtung, dass die Oberfläche (und somit die Darstellung) als bevorzugtes Entscheidungskriterium herangezogen wird. Klar, dann sieht man es auch schön auf der Karten und bleibt nicht mit dem Fahrrad im Schlamm stecken... martinq ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Tagging: Straßen auf der Donauinsel
Dem kann ich mich nur anschließen. Fuß-/Radwege sind schon die am ehest
korrekten Beschreibungen (vielleicht auch noch path). Für den urbanen
Bereich fehlt genau diese Wegkategorie (in die Richtung urban_track).
'path' war als allgemeiner Weg (also ohne primäre Nutzung als Rad-
*oder* Fußweg) vorgesehen.
Wenn man im Alltag von Wegen spricht - und nicht von Straßen - wäre
es ein guter Kandidat. Auf der Donauinsel spricht man ja wohl eher von
Wegen und nicht von Straßen.
ABER: Durch die naheliegende, aber nicht gleichbedeutende Übersetzung
als Pfad, hat man im deutschsprachigen Raum path zum (Trampel-)Pfad
umgedeutet, also einem implizit schmalen und eher unbefestigten Weg.
Darum haben wir jetzt den Salat -- und die wiederkehrende
footway/cycleway/path Diskussion.
Persönlich tagge ich solche Wege (typisch in Parks) immer noch als
'path', immer mit Zusatzattributen wie width, surface, access -
inbesondere bei gemischter Nutzung Rad/zu Fuß ohne besondere Ausschilderung.
track: eigentlich nur für Überland und primär landwirtschaftliche Nutzung
+1 (+Forstwirtschaft), die Nutzung spielt bei dieser Klassifizierung
eine zentrale Rolle. Auf die Donauinsel trifft diese Nutzung nicht zu.
Also in meinen Augen bleibt somit:
foot-/cycleway, path und unclassified zur Auswahl.
-1 zu unclassified: Keine öffentliche Straße mit Verbindungscharakter
Sofern eine Nutzungsart überwiegt oder ausgeschildert ist, tendiere ich
zu footway bzw. cycleway - sehe aber path trotzdem als zulässig an.
Bei wirklich gemischter Nutzung (so wie auf der Donauinsel), und wenn in
der Alltagssprache von einem Weg die Rede ist, dann bevorzuge ich
(noch immer) 'path' mit Zusatztags (nie ohne Zusatztags).
Ich verstehe aber, wenn es jemanden stört, weil es einen
Bedeutungswandel zu Wanderweg gegeben hat [überall?], und path nun
eine Bedeutung in der Art Trampelpfad/Wanderweg impliziert, die es im
Park so nicht hat. Bei footway und cycleway kann man aber das gleiche
Argument anführen (gaukelt indirekt überwiegende Nutzung vor, die es so
nicht gibt).
Statt eines neuen Tags (urban_path o.ä.), wäre ein Rückbesinnung auf die
allgemeine Bedeutung von 'path' mMn sinnvoller.
Die Information Wanderweg kommt mittlerweile über Relationen.
Und bei den Renderern wäre die bessere Berücksichtigung von surface oder
width ohnehin mehr als sinnvoll: Radweg als Schlagloch-Schotterpiste
statt Asphalt und mit dem Rennrad unterwegs [aber in der Karte nix zu
sehen] - dafür dünne, strichlierte Linien [Mapnik] in der Karte für
befestigte asphaltierte Weg ('path') im Park...
martinq
___
Talk-at mailing list
Talk-at@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-at
