Hallo!
Ich denk zurzeit über ein einfaches und schnelles Filterprogramm nach, das .osm-Dateien nach bestimmten Kriterien filtern können soll.
Das Programm osmfilter (version 0) geht mir nicht weit genug, es soll nach zusätzlichen Kriterien bzw. Kombinationen gefiltert werden können. Neben .osm sollen auch .pbf und .o5m als Formate unterstützt werden.
Welche Anwendungsfälle gibt es? Für welche Zwecke setzt ihr Filter ein, bzw. welche Funktionen würdet ihr benötigen?
Danke!
Gruß FK270673
Hallo,
wenn ich nach einer Relation filtere, dann wäre es schön, wenn man optional auch alle betreffenden ways und deren nodes erhalten könnte.
Mal ein Bsp zu Grenzen:
Ich will alle Objekte haben, die ein Grenzway sind oder einer Grenzrelation angehören.
Bsp:
--accept="way{boundary=administrative} | relation{boundary=administrative}" --all-used-objects
| steht für ODER, denkbar wäre evtl. auch eine UND-Verknüpfung (&). In den geschweifte Klammern könnte man dann wieder mit & oder | verknüpfen und runde Klammern setzen um das ganze logisch zu gliedern.
wie wäre es mit einem Filter, die Objekte mit einer Bearbeiter ID filter, die nicht in users_agreed.txt steht so dass ich einen Datensatz bekomme, der sicher in ODbL sein wird oder genau andersrum
Hallo und danke euch für die Ideen!
So wie es aussieht, wird es in einem ersten Wurf sicher auf den bisherigen Funktionsumfang des Programms osmfilter rauslaufen. Boolesche Algebra wäre zwar schick, aber in einer ersten Version zu viel Aufwand.
Was mich am bisherigen osmfilter stört, ist, dass man beim Berücksichtigen von abhängigen Objekten die Input-Datei zuerst vorverarbeiten muss. Gepackte Dateien muss man zu diesem Zweck einmal auspacken und dann wieder einpacken. Zudem ist das Ganze nicht sonderlich benutzerfreundlich, weil umständlich.
Das neue Programm wird stattdessen Direktzugriff auf die Eingabedatei benötigen. Anderenfalls müsste es mehrere temporäre Dateien erzeugen oder sehr viel Hauptspeicher reservieren. Deswegen darf die Eingabedatei nicht komprimiert sein. PBF bildet zwar eine Ausnahme, weil es portionsweise gepackt ist, also einen direkten Zugriff zumindest beschränkt ermöglichen würde, aber auch hier müsste bei jedem Zugriff der betreffende Block dekomprimiert werden. Bleiben noch die Formate .osm und .o5m.
So weit meine bisherigen Gedanken. Kritik willkommen! 
Links:
http://wiki.openstreetmap.org/wiki/DE:Osmfilter
http://wiki.openstreetmap.org/wiki/Pbf
http://wiki.openstreetmap.org/wiki/.osm
http://wiki.openstreetmap.org/wiki/.o5m
Höchste Anerkennung, danke!
Noch setze ich keine Filter ein - einen Anwendungsfall sehe ich in der Vorverarbeitung der .osm-Daten, bevor sie in Navi-Karten umgewandelt konvertiert werden, das könnte ich gut gebrauchen.
Das Tool sollte vor allem die Quelldatenmenge reduzieren und den “Nutzwert pro MB .osm-file” erhöhen, sowie ggf. die Struktur vereinfachen:
Wäre das nicht einfache die osm-Datei in eine Datenbank zu spielen und dann bequem mit SQL zu filtern? Dafür ist PostGIS schließlich erfunden worden.
Schon, nur spezielle Filterprogramme sind einiges schneller als ein Komplettimport von Daten, wovon man hinterher nur einen Bruchteil braucht. Und beim Planeten geht es da um Tage, nicht Sekunden.
Gruß,
ajoessen
Selbst wenn es einfach wäre…schnell ist es ganz gewiss nicht 
Zwischenbericht:
Erste Versuche waren erfolgreich. Läuft überraschend schnell. Auf meiner Kiste (32-Bit-Linux, Intel-Atom) lief das Programm mit < 1GB RAM-Bedarf. Folgende Parameterzeile:
germany.o5m --keep="route=bus" >buslinien.osm
Als Ergebnis hatte ich dann alle Buslinien in Deutschland (alle Relationen mit allen Unterrelationen, deren Wegen und deren Knoten) innerhalb von 2,5 Minuten.
germany.o5m --keep="all route=bus ref=64" >buslinien_64.osm
Hier dasselbe, aber nur Buslinien mit der Nummer 64. Dauerte auch wieder 2,5 Minuten.
Hi,
wenn jener aus der (N)400 oder 500-Serie stammt geht auch 64 bit.
Läuft auf meinen Netbook mit Debian 6 prima.
Ciao,
Frank
Richtig, gibts auch! Allerdings schwör ich immer noch auf 32 Bit, gibt weniger Probleme. Und Programme sind nicht immer schneller, wenn man sie für 64 Bit übersetzt. Manchmal laufen sie dann auch langsamer als auf 32 Bit.
Aber egal, eigentlich wollte ich damit nur sagen, dass das Filtern überraschend schnell klappt. Bei Gelegenheit probier ich es aber sicher auch noch auf 64 Bit. 
@ Marks
So einen Filter fänd ich prima. Danke!
Da er die Daten drastisch zu reduzieren vermag, bekomme ich dann für bestimmte Themen vielleicht sogar einen ganzen Deutschlandsatz oder mehr durch den Composer durch geschleust. (Brauch ich zwar nicht, eine Region tut’s auch, sieht aber schön aus auf dem Bildschirm )
Auch ich würde den Filter vorrangig als ideales Werkzeug für die Vorbereitung von Layerkarten aller Art sehen. Es gibt so vieles, was man als Layerkarte gebrauchen könnte: Wanderwegenetz mit Jugendherbergen, Naturfreundehäusern, Hütten, …, Radwegenetz mit Fahrradgeschäften, DB-Mitnahmepunkten, … , Reitwegenetz mit Wanderreitstationen, pferdefreundlichen Gaststätten, Tierärzten, Hufschmieden, … , Skirouten mit Skiliften, Skihütten, … , Museumstouren, Kneiptouren, Shoppingouren, touristische Attraktionen etc. etc. etc. Der Fantasie sind da keine Grenzen gesetzt.
Ich würde mir ein Tool wünschen, das mir zeigt, welche Tags in den Daten stecken. Das setzt voraus, daß die Daten erst einmal alle gelesen und die Tagliste irgendwo zwischengespeichert wird. Dann würde ich gerne Verzeichnisse sehen, in denen die Tags nach POI, Wegen und Flächen, sowie thematisch geordnet aufrufbar, sowie an- und abwählbar sind.
Interessant wäre ein Filter, mit dem man Objekte ihren Öffnungszeiten entsprechend filtern kann.
So könnte man sich z.B. dann eine Karte basteln, die alle am Montag, Dienstag etc. geöffneten Wochenmärkte zeigt, oder welche Tankstellen am Sonntag geschlossen sind, einen Nachtschalter haben …
Oder man könnte anzeigen lassen, wo Saisonbuden (Weihnachts-, Oster-, Pfingstmarkt, Erntekioske etc.) stehen.
Viele Grüße
tippeltappel
Hallo noch einmal und danke für die vielen Ideen.
Herausgekommen ist - natürlich - ein Kompromiss. Manches konnte/wollte ich nicht umsetzen. Dazu gehören ein paar Dinge, die in der Programmierung recht aufwändige gewesen wären (evtl. wär das was für eine zukünftige Version) und manches, das das Programm zu sehr verlangsamt hätte. Mir ist ja wichtig, dass es schnell bleibt, denn ein universelles Filterprogramm gibt es bereits mit Osmosis, und ein sehr einfaches, aber brauchbar schnelles mit osmfilter.
Konkret ansprechen will ich ein paar Punkte…
Boolesche Algebra:
Gute Idee, aber zu komplex in der Umsetzung. Deswegen sind erstmal nur sehr einfache Verknüpfungen möglich. Wenn man es wirklich benötigt, kann man das Programm natürlich mehrfach aufrufen, also in Reihe schalten.
Zahlenvergleiche:
Vergleiche wie “Alle Stromleitungen ab 50kV” oder alphabetische Vergleiche wurden noch nicht realisiert. Ist aber grundsätzlich vorgesehen.
Abhängigkeiten:
Relationen von Relationen, Wege von Relationen, Knoten von Wegen werden immer berücksichtigt, ist also Standard.
User-IDs, User-Namen
Bis jetzt kann nur nach Tags gefiltert werden.
Quelldatenmenge reduzieren:
Ja, dazu ist der Filter gedacht.
Filtern nach Öffnungszeiten:
Geht mir für einen ersten Wurf zu weit. Das ist eher Sache von Nutzeroberflächen oder interaktiven Karten. Dann steckt meist eh eine Datenbank dahinter, man braucht also ein Filtertool für Dateien.
Die Idee gefällt mir recht gut. Wird eingebaut. Allerdings - wie üblich - nicht als graphische Benutzeroberfläche, sondern im Kommandozeilenstil: Es wird möglich sein, eine Liste aller verwendeten Tag-Keys auszugeben, damit man sich vor dem Filtern in Ruhe überlegen kann, welche man wirklich braucht.
Ich melde mich wieder, wenns was Neues gibt.
Guten Abend. Gute Nachricht:
Das Programm ist so weit, dass man es benutzen kann. Mag sein, dass noch der ein oder andre Bug drin ist, aber meine ersten Tests waren erfolgreich.
Eine Beschreibung (bisher leider nur in Englisch) hab ich hier reingestellt:
http://wiki.openstreetmap.org/wiki/o5mfilter
Fragen, Ideen, Beschwerden bitte einfach hier ins Forum schreiben.
Hi Markus,
danke schön
Hab mal einen Kartenausschnitt von osm.org runtergeladen:
$ ./a.out map.osm --out-keys >tag_list.txt
o5mfilter Warning: wrong sequence at way 26476988.
o5mfilter Warning: wrong sequence at way 33293028.
o5mfilter Warning: wrong sequence at way 26579821.
Jetzt die Datei map.osm in JOSM geladen und sofort als mapi.osm gespeichert:
$ ./a.out mapi.osm --out-keys >tag_listi.txt
o5mfilter Warning: wrong sequence at node 0.
o5mfilter Warning: wrong sequence at node 0.
o5mfilter Warning: wrong sequence at node 0.
tag_list.txt hat 1284 Byte, tag_listi.txt 0 Byte 
Ciao,
Frank
PS
a.out weil ich auf mein 64Bit debian selbst kompiliert habe
Danke für den Test! Sind die OSM-Objekte in map.osm unsortiert? Woher hast du die Datei?
http://www.openstreetmap.org/?lat=50.1004&lon=14.38803&zoom=17&layers=M
=> Export
EDIT
map.osm von osm.org ist mit Gaensefüßchen, JOSM speichert als single quote, wenn ich diese wieder in " umändere, geht es wohl.
Stimmt, die Datei ist tatsächlich nicht nach id sortiert:
...
<way id="44334377" user="Petr Dlouhý" uid="17615" visible="true" version="1" changeset="3109757" timestamp="2009-11-13T23:28:58Z">
<nd ref="290860248"/>
...
<nd ref="290707209"/>
<tag k="barrier" v="fence"/>
<tag k="source" v="cuzk:km"/>
</way>
<way id="26485894" user="Petr Dlouhý" uid="17615" visible="true" version="1" changeset="373206" timestamp="2008-08-22T22:33:55Z">
<nd ref="290278439"/>
<nd ref="290278441"/>
<nd ref="290278442"/>
<nd ref="290278440"/>
<nd ref="290278439"/>
...
Zum Glück sind die sonst üblichen .osm-Downloads sortiert.
Trotzdem hätte die Tag-Liste geschrieben werden müssen. Bei mir klappts jedenfalls:
6 access
131 addr:conscriptionnumber
131 addr:housenumber
131 addr:postcode
131 addr:street
131 addr:streetnumber
4 admin_level
1 alt_name
57 amenity
1 area
20 barrier
6 bicycle
4 boundary
2 bridge
147 building
43 building:levels
1 building:min_level
4 building:part
2 color
14 complete
306 created_by
31 crossing
3 crossing_ref
1 cuisine
4 cycleway
2 description
1 ele
1 fee
1 foot
7 height
214 highway
7 historic
2 id:čvut
1 int_name
15 landuse
5 lanes
9 layer
9 leisure
2 man_made
1 maxheight
2 maxspeed
3 memorial
3 min_height
1 motorcar
120 name
1 natural
14 network
18 note
34 oneway
1 opening_hours
15 operator
1 parking
3 phone
1 place
1 power
18 railway
5 recycling:glass
5 recycling:paper
5 recycling:plastic
4 recycling:tetrapack
18 ref
1 religion
15 route
13 shop
232 source
131 source:addr
3 sport
2 state
1 station
1 surface
1 tariff
2 text_color
1 tourism
1 traffic_calming
8 tunnel
22 type
131 uir_adr:ADRESA_KOD
1 url
1 website
3 wheelchair
EDIT: OK, beruhigend.
So, Version 0.0K ist online. Damit kann man die Tag-Liste auch nach Häufigkeit sortiert ausgeben. Klar, das ginge auch mit nachgeschaltetem “sort -nr”, aber so ist es bequemer.
./o5mfilter eingabedatei.osm --out-count
@Frank:
Stimmt, das ist eine Eigenart von JOSM. Lässt sich unter Linux aber leicht umwandeln:
tr \' \" <josmdatei.osm >osmdatei.osm