Moin,
mal den selbst erfahrenen Bereich betrachten und überlegen:
Da wo kein Holz erreichbar ist, sind die Holz-Bauern erst gar nicht erwähnt, suchen aber auch gar nicht erst - und da, wo Holz erreichbar ist, sind sie auch zugelassen.
Aber es ist natürlich gründlicher, dass getrennt zu erfassen - tut mir aber auch nicht unbedingt leid, dass ich die Daten fürs Holz-Navi bisher nicht erfasst habe … 
Gruß
Georg
Frag doch mal den Gesetzgeber, warum es zwei verschiedene Schilder gibt. Wenn Dich der Unterschied nicht interessiert, dann trage vielleicht besser kein access auf tracks ein, bevor Du behauptest dass man mit landwirtschaftlichen Fahrzeugen durch den Wald fahren dürfe oder der schwere Holzlaster die Abkürzung über den Feldweg zum Wald nehmen könne.
Das fällt jetzt unter Ironie - oder?
Moin,
nur zum geringen Teil.
Nicht umsonst bezog ich mich auf den selbst erfahrenen Bereich - wie es woanders aussieht, kann ich ja nicht pauschal beurteilen.
Hier ist es halt so, dass die Wege, über die Forstbereiche erschlossen sind, auch immer als Feld-Zufahrten dienen - von daher sind diese halt für beide freigegeben.
Wege, über die kein Forst erreichbar ist und die nur als Feld-Zufahrten dienen, halt nur für Landwirtschaft.
Reine Forstwege kenne ich hier nur innerhalb eines Forstes, die mit den grünen Schildern.
Ich sage ja auch, dass es für land- (und insbesondere) forstwirtschaftliche Nutzung der Daten sinnvoll ist, diese getrennt zu erfassen.
Aber ich betrachte es nun mal von der öffentlichen Verkehrsseite aus - und da genügt es mir halt, wenn der öffentliche Verkehr über eine der Einschränkungen ausgeschlossen ist.
Daher erfasse ich “land- und forstwirtschaftliche Nutzung” halt nur durch =agricultural (als hier überwiegende Nutzung).
Edit:
Ich sehe dabei den Schwerpunkt, dass lieber der öffentliche Verkehr bei der aktuellen Auswertung (ohne ;-Listen) eingeschränkt wird, als dass die Daten für forstwirtschaftliches Routing geeignet sind.
Gruß
Georg
Her macht man sich wohl mehr Gedanken über die genaue Bedeutung des Zusatzschildes als die jenigen die es aufstellen…
Also ich denke für die meisten ist “Landwirtschaftlicher Verkehr frei” praktisch das selbe wie “Land- und Forstwirtschaftlicher Verkehr frei”
Zumal hier im Südschwarzwald diese Schilder auch an Wegen zu abgelegen Bauernhöfen und Landschulheimen aufgestellt werden. Theoretisch bedeutet das, als Besucher kommt man da nur zu Fuß hin. Praktisch bedeutet es: Wenn Du diesen Weg befährst dann auf eigene Gefahr.
Ciao
Ryu
Da gehört dann auch Anlieger frei hin.
Alles nur Schlamperei bzw. z.T. Hochnäsigkeit der Behörden. Immer auf die Füße treten.
Wie gesagt: Wir machen sich wohl mehr Gedanken als die Behörden die diese Zusatzschilder schreiben…
Dumme Frage aus purer Unwissenheit: durch welche Software wird z.B. motor_vehicle=agricultural;forestry nicht unterstützt? JOSM hat nichts dagegen, dass ich so etwas eingebe; Potlach 2 warnt zwar, speichert es aber klaglos (*). Renderer? Wir mappen doch nicht für Renderer ;). Routing-Software? Es sollte doch kein Problem sein, ein split an ‘;’ durchzuführen …
() Von iD ganz zu schweigen, das für mehrfache Werte für einen Schlüssel seinen eigenen Unsinn vorschlägt: motor_vehicle=, motor_vehicle_1=* etc. Das muss Software dann natürlich wirklich nicht auswerten.
Deshalb, auf die Füße treten. War damit schon einige Male erfolgreich.
Editoren, Router, Renderer - Praktisch keine Software unterstützt beliebige “;”.
Die von Dir zitierten Editoren unterstützen es auch nicht. Daß man es (trotz Warnung!) irgendwie eingeben kann ist keine Unterstützung. Wenn Du zwei Werte die jeweils Presets im Editor haben mit “;” aneinanderklatscht, wird auch der Editor diese Presets auch nicht wiedererkennen sondern nur irgendwie “unbekannter Wert” anzeigen.
Auch wenn es auf den ersten Blick einfach aussieht, ist es ein Riesenproblem.
Darum rät das Wiki auch:
In general avoid ';' separated values whenever possible. Don't use them in your mapping, and don't propose them on the wiki if there are better ways of representing things.
bye, Nop
Hi Nop,
und was ist dann die Lösung? Machen wir dann jetzt z.B.
motor_vehicle=no
agricultural=yes
forestry=yes
?
Ich würde wie weiter oben schon vorgeschlagen ganz auf forestry verzichten.
Effektiv besteht in der Praxis kein Unterschied zwischen “Landwirtschaft frei”, “Forstwirtschaft frei” und “Land- und Forstwirtschaft frei”. Das sind nur unterschiedliche Worte für dieselbe Bedeutung. Deshalb macht es auch keinen Sinn, das detailliert zu mappen.
Schon gar nicht wenn es auch noch technische Probleme macht und in Kombination nur “ungültiger Wert”, also dasselbe wie “gar nichts getaggt” dabei rauskommt.
bye, Nop
Nein, denn agricultural=yes steht bereits für ein anderes Verkehrsschild.
[Ironie] Effektiv macht es keinen Unterschied, zwischen Fußweg und Radweg zu unterscheiden - die Radfahrer fahren so oder so.[\Ironie]
Wenn in meiner Heimat ein Holzlaster über einen nicht dafür vorgesehenen Feldweg fährt, muss der Fahrer mit einer Anzeige rechnen. Die Landwirte schätzen es nicht, wenn man ihre Wege kaputtfährt!
Wie gesagt: Wenn der Unterschied einem Mapper nicht interessiert, dann soll er einfach nur “track” eintragen - und damit die implizierten Zugangsbeschränkungen und nicht eine Beschilderung behaupten, die nicht da ist.
+1
Diese Konstellation mit mehreren Accesswerten haben ja nicht nur bei agricultural und forestry, sondern auch bei destination, delivery usw., z.B. motor_vehicle=forestry;destination oder motor_vehicle=agricultural;delivery
@nop: Schreiben wir hier dann auch nur motor_vehicle=agricultural dran oder [Ironie]werfen wir die Details nicht besser ganz weg und reduzieren das auf motor_vehicle=yes/no[/Ironie]?
Jemand, der einen Router für Lieferdienste oder Forstfahrzeuge schreibt muss die Tags vorm auswerten trennen, aber das ist technisch möglich. Trennt er nicht, erkennt er die Erlaubnis nicht und sollte nicht über diesen Weg routen. Besser einen Umweg, als ein verbotener Weg.
Grüße
Andreas
*Edit: Beispiel von motor_vehicle=agricultural;destination;delivery auf motor_vehicle=forestry;destination oder motor_vehicle=agricultural;delivery vereinfacht
*
Ah, OK, jetzt verstehe ich, was gemeint ist. Danke! Du unterscheidest also (völlig korrekt!) zwischen ‘tolerieren’ und ‘unterstützen’, und dann hast Du natürlich recht: JOSM und Co. tolerieren das ‘;’ im Prinzip nur, sie unterstützen es nicht aktiv.
Allerdings frage ich mich schon, warum das so ist bzw. bleibt. Es sollte bei den Editoren programmiertechnisch nicht wirklich schwierig sein, ‘;’ zu unterstützen. Am aufwändigsten ist natürlich das UI. Dann muss man eben mehr Checkboxes, die optional statt alternativ angewählt werden können, für Werte verwenden, oder mehrere Häckchen in Auswahlmenüs bzw. -listen erlauben … all das sollte jedoch im Jahre 2015, in dem wir schon Trojaner in der GPU unterbringen können und Armbanduhren Security Updates brauchen, keine Kunst mehr sein
Da hast du recht.
OK. Aber da wären wir ja wieder bei dem alten Punkt, dass das Wiki eher deskriptiv als normativ ist: nur weil das Wiki etwas rät, heißt das nicht, dass man sich daran halten müsste (das Wiki muss sich nach der Mapping-Praxis richten, nicht umgekehrt) :). Eine Formulierung wie “don’t propose them on the wiki if there are better ways of representing things” ist zudem sehr dehnbar: denn man kann in vielen konkreten Fällen streiten, ob denn da nun “better ways” sind oder nicht. Sogar schon bei unserem relativ simplen agricultural;forestry-Fall.
Dann können wir das Wiki ja gleich einstampfen.
Das Wiki muss eindeutig die Bibel fürs Mappen sein. Wenn sich die Mapping-Praxis grundlegend ändert, muss diese im Wiki dokumentiert werden. Alles andere führt zu chaotischem Mappen.
Wenn ich mir anschaue, wie unterschiedlich allein in DE gemappt wird. Eine gewisse Konsistenz sollte schon gegeben sein.
Klingt gut, ist aber ein etwas heikler Vergleich. Mindestens zwei grundegende Probleme gibt es mit diesem immer mal wiederkehrenden Bibel-Vergleich:
(1) Nur noch Ultraevangelikale und ein paar Ultra-Marienanbeter glauben, dass die Bibel wortwörtlich von Gott eingegeben wurde (sog. “Verbalinspiration”) und wie ein Kochbuch für Dummies 1:1 einzuhalten ist (nicht nur 10 Gebote etc., sondern bitte auch kein Mischgewebe in Kleidern, getrennte Kühlschränke für Milch- und Fleischprodukte, etc.). Alle ernstzunehmenden Theologen (OK, das ist meine liberale Sicht) sehen die Bibel als hochspannenden und zentralen, aber auslegungsbedürftigen Text, der nicht wörtlich zu nehmen ist, schon gar nicht an isolierten Stellen: man muss immer den Kontext berücksichtigen und jede Stelle “aus der Mitte der Schrift” interpretieren.
Ehm … möchtest du wirklich, dass das Wiki ähnlich komplex auszulegen ist? Das wäre nicht klarer als heute, glaub mir, sondern noch viel komplexer. Dann bräuchten wir Predigten über einzelne Absätze einzelner Wiki-Artikel …
(2) Die Ultraevangelikalen machen es sich leicht, indem sie die Bibel als wörtlich von Gott gegeben ansehen; damit ist sie über jede Kritik erhaben. Aber wer, bitte, soll unser Wiki “eingegeben” haben? Gott? Der heilige Ptolemäus oder der heilige Mercator? Mapper xyz? Das Wiki ist doch offensichtlich ebenso menschengemacht wie die Datenbank. Beide sind daher fehlbar. Und daher kann das Wiki nicht einfach als absolute Autorität hingestellt werden. Schon alleine deshalb, weil es sich immer wieder radikal selbst widerspricht. (Das ist übrigens eine der wenigen wirklichen Gemeinsamkeiten des Wikis mit der Bibel, wenn man sie stumpfsinning-wörtlich auslegt :)).
Sorry, ich weiß, dass du das wohl nicht so gemeint hast. Aber ich finde diesen Bibel-Vergleich, der immer mal wieder auftaucht, einfach ungeschickt. Man sollte sich einfach klarmachen, mit was man da etwas vergleicht, z.B. das Wiki.
Ah, das ist klar. Eine gewisse Konsistenz ist unumgänglich – da stimme ich dir 100% zu – und etwas anderes wollte ich eigentlich auch gar nicht behaupten (ich gebe zu, meine Formulierung, dass das Wike sich grundsätzlich nach der Praxis zu richten hat, war auch etwas zugespitzt ;)). Was mich jedoch störte, war der Punkt, dass da irgendjemand irgendwo etwas ins Wiki schreibt, z.B., wie bei diesem Thema:
und dass wir uns dann automatisch alle daran halten sollen, ohne den Kopf einzuschalten und ohne darüber zu diskutieren. Wenn wir feststellen, dass mehrfache Werte in bestimmten Fällen sinnvoll und nötig sind, dann muss jene Wiki-Passage geändert werden und nicht umgekehrt. Genausogut könnte ja auch jemand ins Wiki schreiben: “Do not map MacDonald’s at all, I do not like it” – würden wir uns dann automatisch dran halten? --, oder “Trage niemals schwarze Socken beim Mappen” – würden wir uns dann daran halten?
Kurz: Das Verhältnis von Wiki und Karte/Daten ist komplexer. Beide entwickeln sich ungefähr parallel in einem Prozess der sozialen Evolution (nicht der Verbalinspiration oder Schöpfung aus dem Nichts!), und das einzige, was bei Konflikten und offenen Fragen wirklich hilft, ist nicht Autorität – weder die Autorität des Wikis noch die Autorität der de facto gesetzten Tags noch die Autorität irgendeines Obermappers --, sondern (a) Verstand einschalten und (b) die Diskussion hier oder auf der Mailing-Liste oder Ähnliches.
Edit: Typo; klarer
Moin,
korrekt.
Aber
motor_vehicle=agricultural
forestry=yes
wäre zumindest eine Lösung / mögliche Umschreibung für diesen einen Spezialfall.
Diese werde ich zumindest zukünftig anwenden (und nachtragen), um die Information “Forstwirtschaft frei” zu erhalten.
Grüße
Georg