Kommt auf die gewählte Kartendarstellung an, denn nicht jeder Kartenstil unterstützt alle Optionen.
Folgende Kartenstile sollten die Option “Naturschutzgebiet” anbieten:
OsmAnd, Desert, OSM-carto, Snowmobile, Tourenansicht, UniRS, Winter und Ski
Topo, Desert und Offroad zeigen Naturschutzgebiete auch ohne Option als Fläche an.
Verstehe, klappt auch bei mir.
Kann ich mir auch Schutzgebiete mit Betretungsverbot wie z.B. dieses hier anzeigen lassen?
Ich mache mal die Ingrid
Ja werden sie!
Eines meiner Beispiele in meiner Gegend: NSG Spreebögen bei Briescht hatte nie leisure=nature_reserve und wird neben dem Standard-Rendering: OpenStreetMap auch hier bei Osmand gerendert. Ich sehe keine Notwendigkeit mehr für leisure=nature_reserve… und betrachte dies nun als obsolet und veraltet.
Was mich noch umtreibt, ist eine bessere Darstellung von Flächen, die z.B. protect_class=1 haben… Auch Gebiete mit protect_class=16 betrachte ich damit absolut vergleichbar…
Sven
Es kann sein, dass nur protect_class 1-5 unterstütz wird, bin mir da aber nicht sicher.
Bei access=no wäre das Gebiet dann rot umrandet (evtl. muss hierfür eine Option aktiviert sein).
Ich habe dazu ein Issue erstellt:
Danke. Vielleicht kannst du noch das Beispiel von @streckenkundler hinzufügen:
Denn im Issue behauptet jemand leisure=nature_reserve wäre für das Rendering in OsmAnd notwendig:
In order for it to show as a Nature reserve, it must be tagged as leisure = nature_reserve (this tag is missing from OSM in your case).
Das lässt sich aber einfach durch das Beispiel von @streckenkundler widerlegen.
Hallo,
ich versuche eine Möglichkeit zu finden, die besagten Schongebiete doch noch darzustellen. Neben anderer Schwierigkeiten bin ich auf die folgende gestoßen.
Objekte mit tag="boundary" value="protected_area" sollen eingefärbt werden, Objekte mit zusätzlich tag="leisure" value="nature_reserve" aber nicht. Ausprobieren kann man das gut anhand 9893495.
Das sollte sich doch eigentlich trivial mit
<polygon>
<switch noProtectedAreas="false" noPolygons="false" natureReserves="true">
<case minzoom="12" tag="leisure" value="nature_reserve"/>
<case minzoom="12" tag="boundary" value="protected_area" color="#440000ff"/>
</switch>
</polygon>
implementieren lassen. Denn nach meinem Verständnis ist die erste case-Anweisung erfüllt und würde nichts machen und deswegen wird die zweite case-Anweisung gar nicht ausgeführt. Und dies ist auch die einzige Möglichkeit, eine Bedingung zu negieren wie in
if ( (boundary==protected_area) && not(leisure==nature_reserve) )
Leider werden in allen meinen Versuchen beide case-Anweisungen ausgeführt (habe ich überprüft, indem ich der ersten auch eine color
hinzugefügt habe). Das Gebiet wird immer mit beiden Farben eingefärbt.
Habe ich die Funktionsweise der case- innerhalb der switch-Anweisung falsch verstanden?
Viele Grüße
geht es da um die Wald-Wild-Schongebiete die der DAV ausgewiesen hat?
Ja, die kann man nämlich herunterladen und als zusätzliche Karte über den anderen anzeigen.
OK, die sind aber keine “protected area” oder “nature reserve” in OSM, da der DAV nur ein privater Verein ist, der da soviel bestimmen kann wie der ADAC oder der DFB, oder? (mal abgesehen davon, dass der ADAC wahrscheinlich 10x soviele Mitglieder hat und deshalb vermutlich beanspruchen würde, mehr Menschen zu vertreten). Der DAV müsste auf den Gesetzgeber einwirken dass seine Empfehlungen umgesetzt werden, und wenn sie das dann sind, dann taggen wir es als Schutzgebiet.
Diese Gebiete werden als protected_area mit protect_class 14 automatisiert in OSM eingepflegt. Ob diese Gebiete irgendeinen rechtlichen Hintergrund haben, ist doch erst mal nicht entscheidend.
Optimal wäre natürlich, das access-Tag würde in die Osmand-Binärdatei mit übertragen werden, dass z.B. access=discouraged anders darstellen könnte.
Eine brauchbare Vorlage gibt es hier.
OsmAnd scheint keine break-Anweisung zu haben.
Vermutlich geht das in der Vorverarbeitung (obf-Erstellung), siehe if_not_tag und if_not_value.
Ob es eine direkte Lösung für diese Logik in der render.xml gibt, weiß ich nicht.
Das kann ich bestätigen.
Bei switch werden üblicherweise alle passenden case (ohne break) ausgeführt, nicht nur der erste Treffer.
In den obf-Dateien sind aktuell nur protected_area mit protect_class 1 bis 4 enthalten oder wenn diese kein protect_class haben. Für 14 wäre also auch eine Anpassung der obf-Erstellung notwendig:
https://github.com/osmandapp/OsmAnd-resources/blob/master/obf_creation/rendering_types.xml
Aktuell sind nur die folgenden access-Werte drin:
<type tag="access" value="no" minzoom="13" additional="true"/>
<type tag="access" value="private" minzoom="13" additional="true"/>
<type tag="access" value="permit" minzoom="13" additional="true"/>
<type tag="access" value="yes" minzoom="13" additional="true" poi="false"/>
<type tag="access" value="destination" minzoom="13" additional="true" poi="false"/>
<type tag="access" value="permissive" minzoom="13" additional="true"/>
<type tag="access" value="agricultural" minzoom="13" additional="true"/>
<type tag="access" value="forestry" minzoom="13" additional="true"/>
<type tag="access" value="customers" minzoom="13" additional="true"/>
<type tag="access" value="delivery" minzoom="13" additional="true"/>
<type tag="access" value="emergency" minzoom="13" additional="true"/>
discouraged also nicht.
Der OsmAnd MapCreator ist übrigens gut für solche Vorhaben geeignet, unterstützt sowohl das Erstellen von obf-Dateien als auch das Rendern mit eigenen render.xml-Dateien. Falls default.render.xml direkt angepasst werden soll, muss der Dateiname übrigens auf einen unbekannten Namen geändert werden (z.B. new.render.xml) und name="default" in der zweiten Zeile der Datei auch entsprechend angepasst werden, denn sonst wird die eingebaute Datei verwendet. Den absoluten Pfad in den Einstellungen passend angeben.
Der mitgelieferte Inspektor ist manchmal auch hilfreich um nachzusehen, welche Daten in den obf-Dateien tatsächlich enthalten sind, z.B.:
inspector.sh -vmap -vmapobjects -osm my.obf
Achtung, die Ausgabe kann sehr umfangreich werden.
Vielen Dank für die ausführliche Erklärung.
Am Anfang von default.render.xml befindet sich eine Dokumentation der Syntax:
<switch> element :
1. A <switch> (or <group>, logically the same) on the top level propagates all its attributes like e.g. strokeWidth to the <case> level (unless overwritten there)
2. If <switch> has <case> or <switch> children, it tests these in their order with (if...else), and returns "true" when/if the first test succeeds (all others are not executed any more). If one succeeds, also all <applies> are executed in their specified order.
3. If <switch> does not have <case> or <switch>, but only <apply> children, all of these are executed, and "true" is returned.
4. All highest (top level) occurrences of <case> elements must contain tag/value attributes! A nested sequence from the top level like <switch><switch><case tag="" value=""></switch></switch> is possible, though.
In der Klammer von 2. ist ausdrücklich erwähnt, dass die case-Anweisungen innerhalb von switch wie if … else … bzw. analog einer folgenden break-Anweisung zu verstehen sind. Das ist auch sinnvoll, da nur so die o.g. Verneinung zu realisieren ist.
Das auch von dir bestätigte Verhalten, dass sämtliche case-Anweisungen ausgeführt werden, ist mir völlig unklar.
Auch bzgl. dieses Themas hätte ich das von dir beschriebene Verhalten erwartet, habe aber Seltsames festgestellt und hier dokumentiert.
Es wird aber nur das note-Tag aufgenommen (und der Umriss), das Schutzgebiet (boundary=protected_area) selbst, wegen dem protect_class=14, nicht.
note-Tags können von OsmAnd bei Bedarf auf der Karte angezeigt werden, deshalb wird dieses aufgenommen.