[mkgmap-dev] mergeroads branch

Sat Sep 14 04:23:17 BST 2013

On 13.09.2013 22:52, WanMil wrote:
>> 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 :-)
well that happens if you always add rules as mkgmap gains features, 
maybe at some point I should take a week to rewrite it in cleaner form....
>
>>
>> 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.
okay, I'll check it anyhow sometimes.
>
>>
>> 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.
great.
>
>>
>> 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. if
I don't understand your concern for 1. That's what one can use add for, 
isn't it? well in my opinion the most important is order - because 
that's how the style-file worked so far.
So if I would expect the following behavior (based on the assumption of 
no previous rules):

highway=track, tracktype=grade2, bicycle=no, foot=private

1.
highway=*  tracktype=grade2 {set mkgmap:bicycle=yes}
highway=* & bicycle=no {add mkgmap:access=no}
--- result bicycle=yes - foot=yes, all other set to no (there is no rule 
for foot = private, value is set, so add cannot overwrite it)

1.1
highway=*  tracktype=grade2 {set mkgmap:bicycle=yes}
highway=* & bicycle=no {set mkgmap:access=no}
--- result all access types no, as the second rule comes later and set 
should always overrule.

1.2
highway=*  tracktype=grade2 {add mkgmap:bicycle=yes}
highway=* & bicycle=no {set mkgmap:access=no}
--- result all access types no, as the second rule comes later and set 
should always overrule. As bicycle is only add command - it would be no 
anyhow.

1.3
highway=* & bicycle=no {set mkgmap:access=no}
highway=*  tracktype=grade2 {set mkgmap:bicycle=yes}
-- bicycle=yes, all other access types no. later rule overrules earlier

1.4a
highway=*  tracktype=grade2 {set mkgmap:access=no;set mkgmap:bicycle=yes; }
-- Does mkgmap keep track of order of commands set within one bracket?? 
Well here the case is quite clear anyhow. Set access=no but bicycle=yes

1.4b - heavily conflicting:
highway=*  tracktype=grade2 {set mkgmap:bicycle=yes; set mkgmap:access=no}
-- Does mkgmap keep track of order of commands set within one bracket?? 
If yes the logical answer would be to set all types to no. If not, then 
bicycle=yes and all other =no would be expected.

1.5
bicycle=* {set mkgmap:bicycle='${bicycle}' }
foot=* {set mkgmap:bicycle='${foot}' }
highway=* & tracktype=grade2 {add mkgmap:access=yes}
-- foot = no (there is no rule to convert private to no); bicycle = no; 
all other types set to yes.

1.6
bicycle=* {set mkgmap:bicycle='${bicycle}' }
foot=* {set mkgmap:bicycle='${foot}' }
highway=* & tracktype=grade2 {set mkgmap:access=yes}
-- well last rule is set all to yes, so previous rules don't apply. All 
types to no.


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