logo separator

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

From WanMil wmgcnfg at web.de on Fri Aug 26 20:15:02 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 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 at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev




More information about the mkgmap-dev mailing list