etc., aber wirklich zufriedenstellend ist das alles nicht. Trotzdem würde ich auch solche Werte nicht entfernen.
der Grund zwischen source sign und kontextbezogenem Default zu unterscheiden war genau der, dass man bei einer Änderung der Rechtslage diese Fälle unterscheiden können will. In Deutschland gab es dann viele, die lieber noch einen zweiten, dritten und vierten Standard für dasselbe haben wollten, dadurch wird die Auswertung ein bisschen komplizierter aber nicht viel.
zu mindestens an der Stelle bitte nach “Autobahn” ein üblicherweise setzen…
Die Berliner Stadtautobahn ist zu mindestens stellenweise beleuchtet: z.B. Bereich Dreieck Neukölln
+1, Autobahnen sind oft beleuchtet in städtischem Umfeld, in manchen Ländern auch überall (z.B. Belgien)
Ja, aber die Anzahl der Objekte, an denen das (also source: und traffic_sign) erfasst wird, ist im Verhältnis verschwindend gering. Da sehe ich schon sehr viel häufiger Waldwege mit highway=path/track + bicycle=yes, obwohl das nirgendwo ein Schild explizit erlaubt 
Gibt es solch eine Relation für jedes Land oder nur für Deutschland?
Wenn ich das richtig sehe leider nicht.
Deutschland, Belgien, Frankreich, Italien und Dänemark sind vertreten:
(nicht in der Karte, sondern in den JSON Daten nachgucken)
Ich glaube, das ist bisher auch nur ein Proposal gewesen. Ob das irgendjemand zum aktuellen Zeitpunkt auswertet, weiß ich nicht. Aber angesichts der Abdeckung ist es vermutlich fraglich.
Na ja, wir brauchen ja auch vermutlich pro Land nur so eine Relation. Ich habe mir die noch nicht näher angesehen, ob die Werte dort korrekt sind, aber falls ja, wäre das natürlich sehr nett.
Eine kleine Anmerkung zu maxheight=default
Bei dieser default-Angabe macht es einen gewissen Unterschied, ob sie gesetzt ist oder nicht. Wenn vorhanden, kann der reguläre Verkehr sicher davon ausgehen, dass keine Höheneinschränkungen auf dem Abschnitt vorhanden sind. Mit Ausnahme von Sondertransporten. Fehlt diese Angabe, ist nicht klar, ob keine Höheneinschränkung vorhanden ist oder nur noch keiner die Höheneinschränkung erfasst und eingetragen hat. Die Angabe reicht natürlich auf den Abschnitten, auf denen Brücken oder andere Infrastrukturen die Fahrbahn queren.
Zu den anderen Attributen:
oneway=yes müsste jetzt nicht unbedingt sein, erleichtert es aber vermutlich den Softwareentwicklern.
lit=no oder Fahrrad-, Fußgänger-, Reiter- und sonstiger Attributismus schießt für mich über’s Ziel hinaus.
Trefflich formuliert, aber das trifft eben auf alle Default-Werte zu, z.B. auch auf das von Dir als „müsste nicht unbedingt sein“ titulierte oneway=yes am Radweg, oder eben auch lit=no. Es wird sich für so ziemlich jedes Tag ein Fall skizzieren lassen, wo das explizite Erfassen des Standardwertes relevant ist.
Es wird immer Mapper, oder Software geben, die die Standard-Werte explizit eintragen, um Sicherheit zu haben. Wen das stört, der kann ja seine Zeit mit Edit-Wars verbringen, oder darauf hoffen, dass die Editoren einem irgendwann erlauben, diese Attribute auszublenden, damit sie einen nicht mehr stören. Letzteres fände ich produktiver und für alle Seiten praktischer.
| chris2map
March 20 |
- | - |
Eine kleine Anmerkung zu maxheight=default
Bei dieser default-Angabe macht es einen gewissen Unterschied, ob sie gesetzt ist oder nicht. Wenn vorhanden, kann der reguläre Verkehr sicher davon ausgehen, dass keine Höheneinschränkungen auf dem Abschnitt vorhanden sind.
oder dass der Mapper sie übersehen hat. Aber gut, es heißt dass jemand bestätigt, dass er keine gefunden hat, was besser ist als die Ungewissheit, ob sich überhaupt jemand das je daraufhin angesehen hat.
Mit Ausnahme von Sondertransporten. Fehlt diese Angabe, ist nicht klar, ob keine Höheneinschränkung vorhanden ist oder nur noch keiner die Höheneinschränkung erfasst und eingetragen hat. Die Angabe reicht natürlich auf den Abschnitten, auf denen Brücken oder andere Infrastrukturen die Fahrbahn queren.
die Komplettmapper würden dazu sagen, dass du nie weißt, ob noch querende Infrastrukturen fehlen. Es könnten z.B. auch Bäume in die Fahrbahn ragen oder ähnliches. Wenn man schon komplett mappt, dann am besten immer, sonst wäre es halt nicht komplett.
Zu den anderen Attributen:
oneway=yes müsste jetzt nicht unbedingt sein, erleichtert es aber vermutlich den Softwareentwicklern.
lit=no oder Fahrrad-, Fußgänger-, Reiter- und sonstiger Attributismus schießt für mich über’s Ziel hinaus.
wenn man maxheight=default ok findet, ist die logische Konsequenz, alle Attribute zu mappen, weil die Argumente genau dieselben sind. Ein “default” der nicht getaggt ist, ist unklar.
Grundsätzlich gehört die “nichts ist verboten”-Haltung natürlich als eine der essenziellsten Regelungen in OSM.
Aber selbst iD-User machen das nicht so “industriell” und “für die Massen interessant” wie SC. Warum taggt man etwas, das nicht (also GAR nicht, nicht mal - ja, mal - nein) existiert? Es gibt in D keinen Radweg neben einer Autobahnfahrspur, und wenn, dann ist das eine extrem seltene Ausnahme. Gab es nicht bei Quests auch mal die sog. “no spam”-Regel in SC? Wozu ist die denn da?
Ich meine, Treppen zum Beispiel sind allgemein auch nicht für Rollstuhlfahrer geeignet, was einfach in der Natur der baulichen Sache liegt. Rollstuhlrampen sind in aller Regel separat. Deswegen könnte man an alle highway=steps wheelchair=no taggen. Weil es ist ja nicht verboten. Toll.
Mit “cycleway” und “motorway” werden zwei Dinge zueinander gebracht, die halt einfach nichts miteinander zu tun haben. DAS ist das Ding. cycleway an anderen highways - ja. Aber es bringt niemandem etwas, wenn ich mit tausenden von Usern wohlgemerkt (!) etwas in die Datenbank kippe, was keinen Mehrwert hat.
Vielleicht gibt es in Deutschland irgendwo einen Zigaretten- oder Fahrkartenautomaten, der Bitcoin akzeptiert, keine Ahnung. Aber dann könnte man auch hingehen und einen Overlay machen “akzeptiert dieser Fahrkartenautomat Kryptowährungen?” und dann currency:bitcoin=no an alle Fahrkartenautomaten taggen. Oder abfragen ob alle Bäckereien chinesische Yen akzeptieren. Weil man darf das ja taggen. Ja, natürlich darf man das. Das ist halt dieselbe Argumentation.
Nun gut, mit maxheight taggen wir ja immer eine Einschränkung, eine Be-schränkung
Der name “maxheight=default” ist da ein bisschen irreführend. maxheight=default gibt ja an, dass eine maxheigt existiert, und dass diese aber auf jeden Fall nicht unter 4,5 Metern liegt. maxheight=default zeigt also immer an, dass “irgendwas über der Straße ist, das die maxheight auf jeden Fall einschränkt” (wenn auch nicht allzu stark).
Außer natürlich, man geht hin und ““missbraucht”” das Tag, indem man es überall taggt. Das ist dann das, was man eig. glaube ich genau nicht haben wollte, denn ich meine, das Tag wäre ursprünglich erst einmal nur für Straßen unter Brücken und für Tunnel vorgesehen gewesen.
Wobei es eig. auch maxheight:physical=default hätte heißen müssen, da “maxheight” nur ausgeschilderte maxheights bezeichnen sollt(e). Damals war man einfach nich nicht so weit 
das ist bei cycleway=track allerdings die Regel, dass es sich um unterschiedliche Wege handelt. Allerdings ist laut taginfo weder cycleway=track noch cycleway:right=track eine übliche Kombination mit highway=motorway or trunk oder motorroad. 
in Deutschland ist die maximal zulässige Höhe von Fahrzeugen übrigens 4m. Das ist aber keine Streckenbegrenzung sondern eine Begrenzung der zulässigen Fahrzeugmaße, das taggen wir also nicht weil es ein gesetzlicher default ohne Sichtbarkeit on the ground ist.
Verstehe, dann wird eine maxheight>4 m wsl. eher von so Kränen oder so was benötigt, die unterhalb von Brücken ihren Kranarm ausfahren müssen (oder was weiß ich 
)
Hier hätte man das Attribut maxheight damals gebrauchen können, lol:
Ja, die gibt es, deswegen gibt es ja auch keinen Quest, der bei Autobahn nach Radwegen fragt. Es ist eben nur über das Overlay möglich mit denen StreetComplete erstmals das Editieren von Objekten jenseits der Quests ermöglicht.
Ich habe dem User bimbo666 übrigens einen Kommentar an einem Changeset hinterlassen (und ihn auch nochmal privat darauf hingewiesen):
Changeset: 133722353 | OpenStreetMap
@westnordost Wie sieht es mit der Abfrage nach Radwegen bei highway=track aus? Dort fügt er es nämlich auch hinzu, obwohl es meiner Meinung nach total unnötig ist: Changeset: 133958963 | OpenStreetMap
Das hat er manuell über den CyclewayOverlay (siehe CS) eingetragen. Es gibt keine Radweg-Quest für Feldwege. Das könnte man SC-seitig verhindern, aber iD oder JOSM hindert mich ja auch nicht daran.
Ach stimmt, steht ja sogar dort. Danke.
Naja dann mal abwarten ob er sich noch meldet.
Übrigens, zum Thema Fahrradwege auf Autobahnen:
In einigen Ländern, insbesondere der USA, ist es wohl möglich, dass der Standstreifen einer Autobahn explizit für Fahrradfahrer freigegeben ist (cycleway=shoulder), siehe
Siehe auch: https://bicycleuniverse.com/legal-interstate/ - Fahrradfahren auf der Autobahn ist untersagt, es sei denn es ist explizit erlaubt.
Hier z.B. eine Autobahnbrücke mit Fahrradweg, bei Harrisburg, Pennsylvania: Google Maps (nicht ganz klar ob die Fahrradfahrer auf dem Standstreifen oder auf dem “Bürgersteig” fahren sollen…)
Hier eine Autobahnauffahrt mit winzigem Radfahrstreifen in San Antonio, Texas: Google Maps (bei ~100 km/h Höchstgeschwindigkeit 
)
Ja… schon ein bischen wahnwitzig. Allerdings sehen highway=motorway in vielen anderen Ländern eher so aus wie etwas, was in Deutschland eher als highway=trunk gemappt wird. Insofern, nicht ganz so krass.