[mkgmap-dev] Question reg. precompiled bounds

Thu Jan 17 19:12:33 GMT 2013

> 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 at web.de
>  > To: mkgmap-dev at 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_with_--drop-author).
>
>  > 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
>  >