
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.
I am not sure, but would it be possible to skip the multipolygon processing of type=boundary relations when you only want to draw boundary lines (no polygons)?
I don't think so. I am not up2date what the latest recommendations in the wiki are but if the boundaries follow the multipolygon rules the ways itself should not be tagged (although it is tolerated and mostly done). So without the mp processing you get lots of ways without any tags.
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.
I give an exmaple for another: http://www.openstreetmap.org/browse/way/27503381 It is tagged with admin_level = 7 boundary = administrative
but is a member of 4 boundaries (2 x 7 and 2 x 8). So in the end you get 4 lines with distinct border information but only if multipolygons are processed. Maybe you can do that with the relations style file too? I don't know.
I think I did implement this in the default style a year or more ago. This is what the style actions do in the relations file:
(type=boundary | type=multipolygon)& boundary=administrative& name=* { apply { set mkgmap:boundary_name='$(mkgmap:boundary_name)/${name}' | '${name}'; } }
The $() syntax is something that I implemented. It will apply all the names from the relations on the relation members.
And this is the relevant rule from the lines file:
boundary=administrative { name '${mkgmap:boundary_name}' }
In other news, there are more and more boundaries being defined for Finland. I think I will soon have to switch to --index and generating the map with MapSource. Currently, I am using mkgmap r2001, so that I get the half-broken way search with reasonable city names. After r2008 (the branches/location merge) without --index, all streets seem to be assigned to one town (Nurmijärvi), even though the boundaries are valid.
r2001 is from the locator branch, isn't it?
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.
Is there any special reason why you use the locator branch without --index? There should be no advantage to the trunk without --index.
The special reason is my reluctance to use a closed-source Windows program on my Linux system. As far as I can see, there is an advantage of using the old trunk. It will apparently assign streets in the street search index to the closest place node. The location branch merge would assign each street around my area to addr:postcode=01900 addr:city=Nurmijärvi. I have not checked if the city assignment is different in other tiles.
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". Can you please check if you see a difference? If so it would be good to check why there is a difference. WanMil
I do know that the street search requires --index in order to work properly on most devices. The street search sort-of works on the Edge 705 if I enter any housenumber (such as 1) and a street name. Then I get to select the street and city (I guess the list is from the current tile, or from a 100km radius or so). The location of the street will about mid-way in the street (or way segment).
Best regards,
Marko _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev