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

Fri Aug 26 19:47:30 BST 2011

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 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?

>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.

>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.

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