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