[mkgmap-dev] mergeroads branch

Fri Sep 13 17:59:49 BST 2013

okay, finally I managed to rewrite my style -- woohaa - neded about 10 
hours of CTRL-H and controlling the results....

I just noticed that versus the patched version of mkgmap trunk filesize 
increased by about 1%. Overall the rendering speed made no difference or 
maybe even increased 1-2% (well I used ignore-maxspeeds all the time, 
maybe for some the branch is actually faster - even though I now only 
look at bicycle, access, foot tags, and in some cases motorcar - leaving 
all other access tags untreated). I deem the size increase is due to 
looking at the turn angle which was not done in the available patch.

Actually, could the turn angle and merge road setting be adjustable 
somewhere (or quick explanation?). I think I don't want to have any 
angle restrictions - except no merging of roads where another road 
crosses with at least 3° to max 177° angle (and 183-357°), but I would 
have to play around with it to see implications on (long-distance)-routing.

I would like that all possible highways should be joined if no other 
highway is crossing it / junction. However as I often use copies of the 
same way, with different road_class/road_speed restrictions , I hope 
that theese unreal junctions do not stop the merging of roads. Also 
nonroutable lines shouldn't be looked at all when merging roads (so you 
can have the same amount of merge no matter if you use a second line for 
display and another line for routing, or add a line for a bridge).
I will try to check that with gpsmapedit in the following days...

As for mapping private to no, I could implement that without too much 
hassle.
As for the other values like destination, permissive, and so on - I just 
hope mkgmap ignores them just like yes is ignored.

I do hope that setting { add mkgmap:access=yes } works by setting all 
not yet set access values to yes.
while {set mkgmap:access=yes} should overwrite all previously set 
mkgmap:access; mkgmap:motorcycle, mkgmap:bicycle and so on...

Then it would be in line with previous workflow. Actually the above 
mechanism is pretty essential - else I will have to spend days if not 
weeks to completely rewrite access handling....

Felix (will go to bed now, local time is 1AM  and no more time to check 
the resulting map about routing quality).
On 13.09.2013 10:41, Felix Hartmann wrote:
> oh what happens if I do
> {delete mkgmap:access=no/yes}  -- will it only delete the tag per se, 
> or will it set mkgmap:bicycle or mkgmap:motorcar as well? I hope it 
> does the same as until now, namely just deleting the tag (as the 
> actions/consequences of the tag should only be evaluated once the 0x?? 
> part is handled.....
>
>
> what happens if I have the following line
> bicycle=* {set mkgmap:bicycle='${bicycle}' }
> will only bicycle=no be regarded, or will bicycle=private also be set 
> as no?
> will mkgmap crash/produce an error if bicycle=dismount or any other 
> non recognised values is present?
>
>
> I must say, the new access handling is really complicated - at least 
> on my style. I'm trying to rewrite it to produce the old behaviour 
> since well 3-4 hours, but still not near halfway...