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@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev