Zwecks Straßennavigation mit dem kleinen eTrex30 habe ich mir eine Karte gebaut, die nur das Nötigste enthält (siehe auch http://asphaltohneende.de/gps_osm.htm).
Mein Aufruf von osmfilter:
osmfilter -v germany.osm --drop-version --keep=“highway=primary =primary_link =secondary =secondary_link =tertiary =tertiary_link =living_street =residential =unclassified =rest_area =service =road or amenity=fuel =biergarten =cafe =fast_food =food_court =ice_cream =restaurant or place=city =town =village =hamlet” --drop=“motor_vehicle=no or motorcycle=no or vehicle=no or access=no” -o=filtered.osm
Vereinzelt bin ich in filtered.osm dabei auf Shops gestoßen, die nach meiner Vorstellung nicht in der Karte enthalten sein sollen (weder Tank- noch Futterstelle
Die Ursache ist, dass die Knoten jener Shops Teile von (erwünschten) Highways sind.
Beispiel (verkürzt):
Node 300088452 ist Teil von 26361179, und somit Bestandteil der Karte.
Nun vermute ich, dass ein Knoten mit “shop=car” gar kein Teil einer Straße sein sollte. Im o.g. Beispiel handelte es sich dann um einen Fehler in germany.osm (falsche Eingaben).
Ist diese Vermutung richtig?
Ich könnte auch osmfilter mit --ignore-dependencies aufrufen. Das geschilderte Problem wäre dann zunächst behoben.
Aber was handele ich mir damit noch ein?
Immerhin ist filtered.osm dann nur noch halb so groß. Die Vermutung liegt nahe, dass ich damit mehr herausfiltern würde, als mir lieb ist.
Welche Bedeutung haben die vielen anderen Knoten, die Teil anderer Knoten sind?
Über Infos zu diesem Thema würde ich mich sehr freuen.
Die Anwendung von --ignore-dependencies auf ways ist wohl ziemlich sinnfrei, weil ein Way mindestens zwei Knoten haben muss, nämlich dessen Endpunkte. Nur diese Knoten haben Koordinaten, der Way selbst hat keine.
Die mit --ignore-dependencies erzeute IMG-Datei (Garmin-Format) ist in meinem Fall nur 1/100 so groß, wie die ohne. Das eTrex zeigt alles an - bis auf Straßen.
Soweit sind mir die Zusammenhänge inzwischen klar.
Doch was ist mit Knoten, die z.B. shop=car beinhalten?
Ich sehe bisher keine Möglichkeit, solche von Ways referenzierte Knoten, ohne --ignore-dependencies, pauschal auszufiltern. Mit “pauschal” meine ich, ohne “shop” etc. explizit anzugeben. Es gibt ja eine enorme Menge solcher Tags. In den von Ways referenzierten Knoten möchte ich nur die Koordinaten behalten, damit die korrekt Ways erhalten bleiben.
Ist nicht verboten, POIs direkt an die Straße zu kleben. Oft wird es vermutlich unbeabsichtigt passiert sein.
Du könntest den shop doch in die drop-Liste reinnehmen?
Gerade habe ich meinen vorigen Post editiert, weil mir (zu spät) auffiel, dass von referenzierten shops etc. die Koordinaten gebraucht werden können.
Beispiel: Ein highway=service läuft zum shop, dann braucht dieser “highway” die Endkoordinate des shops. Alle highway=service sollen aber in der Karte vorhanden sein. D.h. der shop-Knoten muss bleiben, aber seine shop-Eigenschaft soll weg. Uff.
Den shop möchte ich nicht in die drop-Liste eintragen, weil es außer “shop” noch Myriaden anderer Knoten gibt, die ich alle einzeln aufführen müsste.
ich weiß nicht, ob es sinnvoll ist, einen Shop-Knoten rauzuwerfen, der Bestandteil einer Straße ist. Die Straße verliert dadurch einen Knoten und ändert ihre Form…
Wahrscheinlich wäre das eher ein Fall für den Tags-Filter. Du kannst für “shop” ganz bestimmte Werte zulassen oder verbieten. Müsste jetzt aber selber in der Anleitung blättern, ist zwar peinlich, aber ich hab die osmfilter-Optionen nicht im Kopf.
Davon gehe ich aus. Gestern habe ich mal in Potlatch2 einen Tankstellen-Knoten verschoben, der zwischen zwei highway=service saß (ohne zu speichern natürlich); damit habe ich die Straße verändert. Die Eigenschaft “Tankstelle” oder “Shop” bekommt der Knoten nur durch die entsprechenden Tags.
Dummerweise verschwinden damit z.B. auch die Namen der Tankstellen. Wenn ich “name=” ergänze, könnte es klappen - vorausgesetzt diese Positivliste ist dann vollständig. Doch weiß ich das? http://taginfo.openstreetmap.org/keys hilft da auch nicht weiter…
Bleibt vorerst der pragmatische Ansatz: Ich lasse meine Karte vorerst wie sie ist und probiere sie länger aus. Falls tatsächlich bestimmte Icons das kleine Display verstopfen, filtere ich sie mit osmfilter einfach heraus (–drop-tags oder --drop-node-tags). Nicht perfekt, aber effizient.
Für Perfektion müsste wohl eine Datenbank ran; mit SQL geht “alles”.
Warum hast du eigentlich auch “place” im Filter? Was passiert, wenn du das weglässt und nur die amenity-Werte bei “–keep-node-tags=” drin hast? Natürlich muss dann auch das “all” vorne verschwinden.
Im Tag-Filter (zweiter Durchgang) habe ich einfach alle Einträge des keep-Object-Filters wiederholt (erster Durchgang).
Erster Durchgang, zum Vergleich:
osmfilter -v germany.osm --drop-version --keep="highway=primary =primary_link =secondary =secondary_link =tertiary =tertiary_link =living_street =residential =unclassified =rest_area =service =road or amenity=fuel =biergarten =cafe =fast_food =food_court =ice_cream =restaurant or place=city =town =village =hamlet" --drop="motor_vehicle=no or motorcycle=no or vehicle=no or access=no" -o=filtered.osm
Im zweiten Durchgang möchte ich zwar nur in den Objekten filtern, die lediglich durch eine Referenz noch in der OSM-Datei sind, aber die referenzierenden Objekte werden vom Tag-Filter ja ebenso erfasst.
Die referenzierenden Objekte möchte ich nicht verändern; aus den referenzierten Objekten hingegen sollen alle Tags verschwinden. Ich habe also unterschiedliche Filterregeln für die primär gewollten (referenzierenden) und die sekundär nötigen (referenzierten) Objekte.
In osmfilter scheint das nicht formulierbar zu sein, oder ich habe osmfilter noch nicht ganz durchschaut - deshalb schreibe ich hier
Nein, denn “all” adressiert alle angegebenen Tags, unabhängig von deren Werten (das beabsichtige ich).
Ohne “all” werden nur die Tags gelöscht, deren Werte angegeben sind; es werden also Tags behalten, die spezielle Inhalte haben.
osmfilter --help
TAG_FILTER
The tag filter determines which tags will be kept and which
will be not. The example
--keep-tags=highway=motorway =primary
will not accept "highway" tags other than "motorway" or
"primary". Note that neither the object itself will be
deleted, nor the remaining tags. If you want to drop every
tag which is not mentioned in a list, use this example:
all highway= amenity= name=
Mmh, evetuell funktionokelt Dein Vorhaben, wenn es Dir gelingt, Deine osm zu splitten:
Einmal mit Tankenstellen incl. den “1-Punkt-auf-der-Straße-Tankstelle” und einmal das Komplementäre davon.
Beim ersten könntest Du dann keep-(node-)tags mit names und beim zweiten ‘drop all tags’ anwenden.
Anschließend beide Resultate wieder zusammenmanschen. Ob dann das “geographischen mergen” per osmconvert noch gelingt?
Versuch mach kluch
Aber dir gehts doch nur darum, dass die unerwünschten Shops nicht erscheinen, das heißt, es reicht, unerwünschte Shop-Tags zu löschen und die übrigen Tags unberührt zu lassen. Vielleicht hab ich es auch falsch verstanden.
Ich verstehe das Problem nicht mit den zusätzlich enthaltenen Tags?
Die dürfen doch ruhig in den OSM-Daten drin sein.
Wichtig ist wenn ich das richtig gelesen hab (map für eTrex30 = IMG ) das mkgmap dies richtig interpretiert.
mkgmap ist für solche Fälle wesentlich besser geeignet da man für jeden Fall entsprechende STYLES vorgegeben kann als mit osmfilter - das ja eigentlich fast nur eine ja/nein-Filterung zulässt.
Ich selbst gehe bei der IMG erstellung fast immer mit den ungefilterten OSM-Daten rein, was raus kommt leg ich mit den STYLES fest.
osmfilter verwend ich nur um die performace zu verbessern…
Die Shops sind nur ein Beispiel; was es sonst noch alles gibt, ist eine lange, für mich nicht zu überblickende Menge.
Aber natürlich ist dieser Ansatz nicht an der Praxis orientiert, sondern eher idealistisch.
Wie ich schon schrieb, dürfte für die Praxis direktes Ausfiltern der wenigen auffälligen Knoten vollkommen genügen
nicht gibt als tag, werden alles nodes “tag-frei” sein.
