Hi WanMil,
I am picking up some lose ends...
Great :-)
I tried the combination of both programs with europe.osm.pbf dated 2013-01-12: osmconvert --drop-version europe.osm.pbf -o=europe.o5m osmfilter osmfilter europe.o5m --keep-nodes= --keep-ways-relations="boundary=administrative =postal_code postal_code=" -o=europe-boundaries.o5m osmconvert.exe --fake-version europe-boundaries.o5m -o=europe-boundaries.osm.pbf
osmosis.bat --read-pbf file=europe-boundaries.osm.pbf outPipe.0=data1 --read-pbf file=europe-boundaries.osm.pbf outPipe.0=data2 --tag-filter accept-relations boundary=administrative,postal_code inPipe.0=data1 outPipe.0=6 --used-way inPipe.0=6 outPipe.0=7 --tag-filter reject-relations inPipe.0=data2 outPipe.0=8 --tag-filter accept-ways boundary=administrative,postal_code inPipe.0=8 outPipe.0=9 --used-node inPipe.0=9 outPipe.0=10 --used-node inPipe.0=7 outPipe.0=11 --merge inPipe.0=10 inPipe.1=11 outPipe.0=12 --write-pbf file=europe-boundaries2.osm.pbf omitmetadata=true compress=deflate inPipe.0=12
osmconvert.exe europe-boundaries2.osm.pbf -o=eb2.o5m osmconvert --diff eb2.o5m europe-boundaries.o5m > db.osm
I think the osmosis command drops too much data, for example this relation http://www.openstreetmap.org/browse/relation/1610919 is missing in the output of osmosis.
I agree.
Maybe we should also change mkgmap, for example it ignores this relation http://www.openstreetmap.org/browse/relation/1598874 which is written by osmfilter, but not by osmosis.
I disagree. I think I have seen areas located within boundary=political and boundary=administrative. How do you want to decide which one is the right one? We've also been asked to support place=* polygons. But I don't see that mkgmap should support a broad variety of tagging schemes. By supporting them we also encourage people to use different tagging schemes. OSM must find a tagging scheme that enables mkgmap and other "address finders" to assign valid fields for address search. At the moment the most common schema is boundary=administrative.
On the other hand, it doesn't ignore buildings like this: http://www.openstreetmap.org/browse/relation/1569568 which is only written by osmfilter.
I think it is ok to use all polygons with postal_code=*. But we should merge polygons with the same postal_code in the boundary preprocessor.
I've also created the bounds for each of the files. - europe-boundaries.o5m gives *.bnd files with 418.495.744 bytes eb2.o5m gives 412.499.832 bytes
Summary: I'd prefer running only osmfilter as long as memory is not a problem.
Of course you can. We could also try to improve the osmosis filtering. WanMil
Ciao, Gerd
Date: Sat, 12 Jan 2013 16:55:24 +0100 From: wmgcnfg@web.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] Question reg. precompiled bounds
Hi,
the wiki says that I have two alternatives to extract boundary data from an OSM file, either osmfilter: "fast, resulting files contains some unused stuff that eats memory when precompiling bounds" or osmosis: "slow". What about a combination of both (first osmconvert, than use osmosis to filter the output of osmconvert) ?
Ciao, Gerd
I tried that once but observed problems.
osmconvert/osmfilter with parameter --drop-author generates pbfs that cannot be read with osmosis
(http://wiki.openstreetmap.org/wiki/Talk:Osmconvert#PBF_seems_to_be_incorrect...).
Don't know if that' still the case. Anyhow one could use osmconvert without --drop-author. I also tried that but I did have another problem I don't remember what thas was.
The unused stuff I saw were subrelations of type=collection. There is a warning in the wiki that they shouldn't be used so I don't know if its usage has dropped.
Testing the double filter osmfilter/osmosis would be a good thing to see how much stuff is really superfluos when using osmfilter only.
WanMil