[mkgmap-dev] mergeroads branch

Fri Sep 13 21:52:25 BST 2013

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

Wow, you seem to have an epic style :-)

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

The branch is more accurate with merging. The patch merged some roads 
that should not be merged...
I do not expect better rendering speed because merging is applied to 
roads only. All other ways are merged by the merge-lines option which is 
the default since r2586.

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

Ways are not merged if the angle ([-180;180]) between them is greater 
than 130° or lower than -130°.
I can add an mkgmap option for the angle but the number of merges that 
are restricted by the angle is quite small. We had the approach to 
remove some options so I think adding a new option is not very good.

But you can play with it. You can change the max angle and enable a log 
message in line 265 and 266 of the RoadMerger class.

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

Ways are merged only if their garmin type, road class/speed and a 
special list of tags are identical. The special list of tags contains 
all tags that are evaluated by mkgmap after the style processing.

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

Nonroutable lines are not merged by the new merger. They are merged by 
the --merge-lines option.

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

Current behaviour is:
1. mkgmap:access=no? => Set all garmin access flags to no. Ignore all 
other mkgmap:* access tags like mkgmap:bike.
2. mkgmap:carpool=yes? => Set only the hardcoded garmin access flags 
carpool, emergency and bus to yes, all others to no. Ignore all other 
mkgmap:* access tags.
3. Else: Set all garmin access flags to yes unless the mkgmap:* tag is 
set to no.

I am thinking about that especially in rule 1 ignoring all other tags 
might not be useful for style implementors. Would it be better to have 
mkgmap:access=yes/no as a default? So if mkgmap:access=no all garmin 
flags are set to no. But if mkgmap:bike is set to yes the garmin access 
flag for bikes is also set to yes.

WanMil

>
> 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...
>
>
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>