[mkgmap-dev] [PATCH] --ignore-builtin-relations

Fri Aug 26 20:51:14 BST 2011

On Fri, Aug 26, 2011 at 09:15:02PM +0200, WanMil wrote:
>> On Fri, Aug 26, 2011 at 07:02:53PM +0200, WanMil wrote:
>>> Compare processing time:
>>> 1. Compile a map without --route or --net with the CVS version
>>> 2. Compile the same map but remove the turn-restrictions tag from the
>>> builtin-tag-list file.
>>> The tags to remove are:
>>> restriction
>>> except
>>> exception
>>
>> OK, I will test this with --style=route-foot or some other sparse style.
>> Actually, the --ignore-builtin-relations should be improved to remove
>> these tags (as well as boundary and multipolygon) from the
>> builtin-tags-list too.
>
>I think it should be the other way round. Remove the tags from the
>builtin-tag-list and add it to the list of used tags if the tags are
>required. That's the common behaviour of all other hooks and styles.

OK, that makes sense.

Here are 3 test runs:

First, without --ignore-builtin-relations, not touching 
builtin-tags-list:

time java -Xmx1024m -Dlog.config=logging.properties -jar mkgmap.jar 
--max-jobs --product-id=1 --code-page=1252 --adjust-turn-headings 
--remove-short-arcs --country-abbr=FIN --country-name=Finland 
--family-id=2 --family-name=foot --transparent --mapname=61241000 
--description=foot --style=routes-foot finland.osm.pbf

real	4m35.303s
user	4m24.981s
sys	0m2.176s

Second, with --ignore-builtin-relations, not touching builtin-tags-list:

time java -Xmx1024m -Dlog.config=logging.properties -jar mkgmap.jar 
--max-jobs --product-id=1 --code-page=1252 --adjust-turn-headings 
--remove-short-arcs --country-abbr=FIN --country-name=Finland 
--family-id=2 --family-name=foot --transparent 
--ignore-builtin-relations --mapname=60241000 --description=foot 
--style=routes-foot finland.osm.pbf

real	2m47.759s
user	2m39.870s
sys	0m1.932s

Third, with --ignore-builtin-relations, and with the reduced 
builtin-tags-list:

time java -Xmx1024m -Dlog.config=logging.properties -jar mkgmap.jar 
--max-jobs --product-id=1 --code-page=1252 --adjust-turn-headings 
--remove-short-arcs --country-abbr=FIN --country-name=Finland 
--family-id=2 --family-name=foot --transparent 
--ignore-builtin-relations --mapname=62241000 --description=foot 
--style=routes-foot finland.osm.pbf

real	2m46.723s
user	2m40.770s
sys	0m1.876s

The longest run (without --ignore-builtin-relations) did generate some 
log: warnings about turn restrictions and multipolygons. Curiously, 
reducing the builtin-tags-list does not seem to cause any difference, or 
the difference is smaller than the variation (noise) in the execution 
times. I guess that there are relatively few turn restriction relations 
in the input data.

>>Only the built-in processing of type=boundary relations would be 
>>affected. If the style rules specify some processing for boundaries, 
>>then that should still be applied. What does the built-in processing 
>>of type=boundary relations actually do? Does it have any effect if the 
>>style does not define any polygon rules for boundaries?
>
>There is no difference between boundary relations and multipolygon 
>relations at the moment.

With the default style, do you have an example where the built-in 
processing of boundary relations as multipolygons affects the result?

>>No, r2001 from trunk is the last revision before the location branch 
>>was merged to trunk. It was merged in r2008.
>
>Mmmh, http://www.mkgmap.org.uk/svn/wsvn/mkgmap/?op=log&isdir=1& shows 
>the log of the trunk without any revision between 1995 and 2008.

Sorry, I was being inaccurate. Indeed, svn info says that 1995 is the 
last changed revision. I am using 
http://svn.parabola.me.uk/mkgmap/trunk/, effectively r1995.

>There should be no difference regarding address search between 
>revisions before and after merging the locator branch as long as you 
>define --location-autofill=XXX where XXX does not contain "bounds".

OK, I am guilty of not defining --location-autofill. Thanks for the 
hint, I will try to add it. There are broken boundaries in 
finland.osm.pbf, but both Nurmijärvi and my home city Vantaa are 
correct. That is why I was suspecting some bug. Anyway, as long as there 
are any broken boundaries in the input, I think that you can 
legitimately claim "garbage in, garbage out".

	Marko