Hi Minko, my understanding is that you have to add two lines at the end of points, lines and relations, e.g. for the lines file: ... <finalize> include 'inc/compat_lines'; The corresponding include members are in the default style. Gerd

Date: Mon, 9 Dec 2013 22:46:22 +0100 From: ligfietser@online.nl To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] Merge the mergeroads branch?

I'm sorry Wanmil, I'm still not familair with all the mergeroads changes and I'm afraid that my styles wont longer work if it is merged with the trunk version? Or is it backwards compatible with custom styles?

...

I think the mergeroads branch is "functional complete". I want to know if you are happy with all changes?

---

mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Hi Minko, using the compat_* includes should produce the same result as if you use the current trunk so I am interested in the differences. Can you post your style files and describe what's different? Short explanation about the lines below: Each OSM item can have up to four labels. The addlabel function adds one label (which means it sets the first unset tag mkgmap:label:n where n is 1-4). The rules in the compat_* files perform the same operations that are performed by Java source code in the trunk. mkgmap:display_name=* { addlabel '${mkgmap:display_name|subst:;=>/}' } Adds the text of mkgmap:display_name as label and replaces all ";" with "/". mkgmap:label:1!=* & ref=* { addlabel '${ref|part:;:1}' } If the OSM element has no label and there is a ref tag the value of the ref tag is set as first label - but only the part until the first ";". ; was a special character in the trunk because it was used in the Java source code as a separator between labels. The tag ref=A1;A2 setted two labels A1 and A2. WanMil

Thanks for the hint Gerd, that makes the routing work with my styles (I see some minor differences but no big issues). I notice that some labels of cycleroutes are gone (cycleroutes with streetnames now only show streetnames) and I dont understand the labeling of names, for instance what does this all mean:

mkgmap:display_name=* { addlabel '${mkgmap:display_name|subst:;=>/}' } mkgmap:label:1!=* & ref=* { addlabel '${ref|part:;:1}' } etc

Hope Wanmil can document this with examples.

...

my understanding is that you have to add two lines at the end of points, lines and relations, e.g. for the lines file: ... <finalize> include 'inc/compat_lines';

The corresponding include members are in the default style.

Gerd

---

mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Hi Wanmil

I found more issues:

-I notice now that all the place names are not rendered anymore. I have include 'inc/place'; somewhere in the middle of the points file, does this have to be placed at the end in the finalysed section? And I have to mention I didnt use compat_points and compat_polygons.

-The branch version refused to run because I used --ignore-maxspeeds

--ignore-maxspeeds is no longer supported and required. In the branch the same behaviour is achieved by not referencing the maxspeed tag in the style files.

-housenumber search doesnt work, because inc/address is not allowed on top?

What do you mean with inc/address is not allowed on top? In my tests I did not find any problems with housenumber search.

...

using the compat_* includes should produce the same result as if you use the current trunk so I am interested in the differences. Can you post your style files and describe what's different?

It could be that a few mkgmap parameters were not exactly the same. I'll try another test with exactly the same settings later, I first have to repair those issues

I've done a direct comparison between the branch (trunk default style plus compat file) and the trunk (default style). The only differences I found had to do with some ref tags that contains multiple ";". As far as I understand this should not result in a difference in the map file. But maybe I have to test that again.

...

Short explanation about the lines below: Each OSM item can have up to four labels. The addlabel function adds one label (which means it sets the first unset tag mkgmap:label:n where n is 1-4).

Maybe I can use this mkgmap:label to add all cycle route labels? I now use several lines on top of each other, all representing a certain cycleroute relations (lcn, rcn, ncn). I had to do this because I wanted to display all the names. See https://www.dropbox.com/s/2ifcl63hn8f2z1u/trunk.jpg

Usually only the first label is displayed. Sometimes (on some devices) the second label is displayed for routing instructions. The third and fourth label can be used at least for address search.

In the mergeroads version some labels are gone, and also the ref's see https://www.dropbox.com/s/2sldv2q0si7qcp8/mergeroads1.jpg Ignore the differences in map colours, one map is my full version, one is the light version, but they have the same lines file. Link to OSM is http://www.openstreetmap.org/way/93262793

I would like to check that. But I need your complete style files. You can also send them directly to me if you don't want to post them here. WanMil

Thanks Minko! I found a problem with the ref handling (not yet fixed). Second I must have a look how the finalize section works together with continue statements. There might be something wrong. WanMil

Wanmil wrote

...

What do you mean with inc/address is not allowed on top? In my tests I did not find any problems with housenumber search.

See my first issue. Why are all the place pois gone? Do I have to put the include 'inc/address' and inc/place in the finalize section at the end (as you have done in the lines style)?

...

I would like to check that. But I need your complete style files. You can also send them directly to me if you don't want to post them here.

My styles are here http://code.google.com/p/mkgmap-style-sheets/source/browse/trunk/styles/#sty...

Typ file: http://code.google.com/p/mkgmap-style-sheets/source/browse/trunk/#trunk%2Fty...

I only added to the end of the line style this rule

<finalize> # The finalizer section is executed for each element when a rule with an element type matches

# calculate the access rules include 'inc/compat_lines';

And I copied compat_lines to the inc subdirectory In this file I deleted the line include 'inc/roadspeed'; to ignore the maxspeeds

_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Hi Wanmil I tested it again and after some modifications of my styles everything shows up on the map as intended. So the labels are fine now. Some remarks: 1) I had to add this line in my style to make housenumber search work: # Assign the street name for house number search highway=* & name=* { set mkgmap:street='${name}' } This line was not needed in the trunk version. 2) To make the place pois appear again I had to add some rules in the finalize section: <finalize> name=* { name '${name}' } 3) Carpool tag is still not independent from access=no / motorcar=no in Basecamp I tried to clear all the carpool flags with set mkgmap:carpool=no but that doesnt work.

...

2) To make the place pois appear again I had to add some rules in the finalize section:

<finalize> name=* { name '${name}' }

Mmmh, "name=* { name '${name}' }" is the first rule in the compat_points file. But I will check place pois again.

To be sure that I am looking for the right thing: You are using your styles (http://code.google.com/p/mkgmap-style-sheets/source/browse/trunk/styles/#sty...) and add the compat_* includes to the finalize section. Compiling with the branch you don't see any place POI? Can you post a difference because I think I see them...? Thanks! WanMil

...

3) Carpool tag is still not independent from access=no / motorcar=no in Basecamp

I tried to clear all the carpool flags with set mkgmap:carpool=no but that doesnt work.

The carpool handling is independent in the branch. But only if you don't use the compat_* includes.

Hi Wanmil I gave it another try with the default style. At the end of the lines file I added those two lines as you suggested: mkgmap:carpool=yes { set mkgmap:carpool=no } highway=* & mkgmap:carpool!=* { set mkgmap:carpool=yes } This still does not work. I mean: in Basecamp bicycle routing is still avoiding cycleways (unless I uncheck the carpool avoid option). I also tried it with only the first line mkgmap:carpool=yes { set mkgmap:carpool=no } in the finalize section, but this didnt help. Also tried { delete mkgmap:carpool } but this didnt help either. Are there other ways to remove the carpool flag from ways with either access=no or motorcar=no or must we accept this carpool handling is not independent in Basecamp?

Wanmil wrote:

the carpool flag in the branch can only be controlled by the tag mkgmap:carpool.

I don't know if we have to accept the Basecamp handling. I still don't know if the bit which is toggled by mkgmap:carpool is really used for carpool handling. I have done some tests with Mapsource but I couldn't find *any* difference in the routing behaviour. So no matter if the carpool flag was set or not and no matter if the carpool avoidance was set or not, routing was always the same. So I doubt if the bit which we call carpool bit really influences carpool handling.

Neither can I see any difference if a road has mkgmap:carpool=yes or not. So what is the benefit of this mkgmap:carpool tag?

On 18/12/13 09:44, WanMil wrote:

@Steve: did you ever check the impact of the "carpool" bit in the NOD(?) files? Do you think the bit controls the carpool routing?

Mark Burton introduced this bit in 2010 but with a weired behaviour and I am not sure if anyone could test it significantly. See also http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2009q4/005920.html

I've never checked how the carpool bit works. However it must have (or had) an effect in the past on at least some devices. Reported working here: http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2011q3/012140.html In fact there have been observations that it has unwanted side effects http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2011q3/012138.html http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2011q3/012147.html In real life carpool lanes - are just lanes and don't usually affect the whole road but might just prevent access to particular junctions, - have limited times of operation - Only for major highways. Any of these may make it less useful for the uses that people want to use it for. Although we don't know how to control any of these eg. set the times of operation, there might be defaults. Probably every device is different to others too. ..Steve

So it is not a question if real carpool lanes are interesting or not, it would be great if we could control this tag in the mkgmap styles to prevent those unwanted side effects.

Ok, that's possible with the mergeroads branch. Bit is set if mkgmap:carpool=yes/1/true, otherwise it is not set. WanMil

Hi Minko, I will commit some debug code so that you can check yourself which access restrictions are put in the img file. You could also open the img file with GPSMapEdit and check the restrictions. GPSMapEdit does not show the "carpool" bit but I guess you have other restrictions that blocks the street. WanMil

Im afraid this is not working Wanmil. Even if I unset it the roads are still blocked.

...

Ok, that's possible with the mergeroads branch. Bit is set if mkgmap:carpool=yes/1/true, otherwise it is not set.

Thanks Wanmil, I'll do some tests. In the default access style of the branch I found one error: highway=cycleway { add bicycle=yes; add access=no } Correction: highway=cycleway { add bicycle=yes; add foot=yes; add access=no }

If you look at the traffic rules you might be right Thorsten. Pedestrians may only use cycleways if there are no adjacent footways. In general on OSM sidewalks are not mapped very frequently so I would suggest to set access default on yes. Unless mkgmap can detect if there are sidewalks/footways along those cycleways or not, but this is not the case. This is the same discussion as the use_cycleway tag that has been introduced: http://wiki.openstreetmap.org/wiki/Proposed_features/Bicycle_use_cycleway If there are obligatory cycleways along highways a cyclist must use the cycleway and has no access to the main road. Mapping of the main road with bicycle=no is considered wrong by some people. They argue that the router has to solve this. But the problem here is there is no relation between cycleway and main highway or cycleway and footway, so mkgmap can't decide which way is allowed and which way isnt. So the common practice is to map this on OSM: If there are adjacent footways, map the main road with foot=no. This can be a cycleway or other highway. Thorsten wrote:

That's wrong. From OSM: "The highway=cycleway tag indicates a separate way which is mainly or exclusively used by cyclists."

If the "foot=yes" is missing as key, it could be correct and pedestrians are really not allowed there. There are a lot of examples for "highway=cycleway" here in the Nuremberg area, where really only cyclists are allowed, not pedestrians.

Thorsten

Hi Chris, Ok, I read in the cycleways wiki that it is strongly adviced that foot=yes should be tagged on cycleways that are open for pedestrians, didnt know this.

Hi, the default access rules are listed here:

<http://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restrictions>

and you see that the global default is different from the NL default.

For the global default style we should IMHO implement the default global OSM rules.

Chris

On Fri, Dec 20, Minko wrote:

A few more additions:

highway=steps { add foot=yes; add access=no } highway=bridleway { add foot=yes; add access=no }

About access on bridleways i'm not sure. In the UK cyclists are allowed but in the NL's only pedestrians. The default rule is no access for all vehicles and even pedestrians?

Which matches the german law: even pedestrians are not allowed to use a bridleway if there is not a special sign telling them otherwise. Thorsten -- Thorsten Kukuk, Senior Architect SLES & Common Code Base SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)

Wanmil wrote

But you are right highway=bridleway { add foot=yes; add access=no } should be highway=bridleway { add access=no } I will change that.

No, I meant the opposite. It is already set to no which means unroutable.

What about highway=steps? I think the rule is fine?

WanMil

No, I mean highway=steps { set access=no } should be highway=steps { add foot=yes; set access=no }

Thanks Wanmil, I'll do some tests.

In the default access style of the branch I found one error:

highway=cycleway { add bicycle=yes; add access=no }

Correction:

highway=cycleway { add bicycle=yes; add foot=yes; add access=no }

Hi Minko, it's discussable which variant is correct. And that's also country specific... I implemented the restrictions listed at http://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restrictions#... So from my point of view the rule in the branch is ok. WanMil

Hi Wanmil, I have done a few tests with your debug function. It didnt report all roads in the log file, but the ones that were logged gave a good insight of the routing bits that were on and off.

I added two rules to the end of the default branch line style to see what will happen:

highway=cycleway {set mkgmap:carpool=no} highway=primary {set mkgmap:carpool=yes}

Example primary: http://www.openstreetmap.org/way/215516920 215516920 0x3 00000111000 [N237 Utrechtseweg, Utrechtseweg (N237), N237, null]

means bicycle=no, foot=no, carpool=yes, car=yes

cycleway: http://www.openstreetmap.org/way/206642571 206642571 0x7 01101010111 [Utrechtseweg, null, null, null]

means bicycle=yes, foot=no, carpool=no, car=no

Test Basecamp:

1) vehicle=car, carpool avoidance on: routes on primary! avoids cycleways 2) vehicle=car, carpool off: routes on primary, routes on cycleways!

3) vehicle=bicycle, carpool on (=default): routes on primary, avoids cycleways ! 4) vehicle=bicycle, carpool off: routes on primary!, routes on cycleways

5) pedestrian mode: routes on primary, routes on cycleways

Another test: I've set carpool=yes on all unclassified roads highway=unclassified {set mkgmap:carpool=yes} highway=residential {set mkgmap:carpool=yes}

Example http://www.openstreetmap.org/way/6996189 6996189 0x6 00000001000 [Kerkstraat, null, null, null]

carpool=yes

6) carpool on/off doesn't block routing on this road

My conclusions

-The mkgmap:carpool bit seems to have no influence on routing (carpool avoidance on/off) in Basecamp. -no-car=1 or 0 seems only related if carpool avoidance is switched on/off -no-bike is ignored, no-foot is ignored -If carpool avoidance is switched off there are small routing differences in vehicle type which are -I think- caused by the differences in road_classes (situation 2 vs 4)

Thanks for your detailed checks! I think we will get other useful observations once the mergeroads branch is merged. WanMil

Hi Gerd, great! I could not test yet but will do tomorrow. I am thinking about if it is possible to move the handling to a place before the merger? The RoadMerger would not have to care about this option and could also merge roads that were splitted gratuitous by the link-poi-to-ways handling. I encountered with r2868 that ways (at least sometimes) seems to be splitted twice on a POI. Example: x111x111x1111P111x11x111x => x111x111x2222P333x44x444x x = Point P = POI which splits the way in the link-pois-to-way handling n (number) = id of the way to visualize the splitting This might be remerged by the RoadMerger x111x111x2222P222x44x444x WanMil

Hi WanMil,

I've committed a fix for the link-poi-to-ways option. With r2867 the POI of merged ways were ignored. (An alternative to the mkgmap:way-poi-node-ids tag would be a HashSet<Node> in class Way which is only initialised when used. Maybe that would be clearer?)

I also tried to implement the solution that you suggested here: http://gis.19327.n5.nabble.com/mergeroads-branch-tp5776711p5778414.html in the high-prec-branch.

It looked simpler, but it turned out that the code to save the original positions of CoordPOI and later the restoring of the info was much more complex than the treatment in the replace routine.

I think the only problem that can occur with the implementation in r2869 is when two CoordPOI are merged. This is very unlikely, and the corresponding error is very small.

Gerd

...

Date: Mon, 9 Dec 2013 19:59:33 +0100 From: wmgcnfg@web.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: [mkgmap-dev] Merge the mergeroads branch?

I think the mergeroads branch is "functional complete". I want to know if you are happy with all changes?

In such a case I would start to document the changes which need to be done before merging the changes to the trunk.

A short overview of the changes: * Roads are merged which reduces the number of road entries by 7-25% using the default style. This results in slightly better routing calculation times and slightly smaller img file sizes. * The four labels to pois/lines/roads/polygons are no longer assigned automatically. They must be assigned using the 'name' and 'addlabel' function. This also means that ref tags are no longer used as labels automatically. * Access restrictions of roads are now defined by setting special mkgmap:** access tags (e.g. mkgmap:car, mkgmap:foot, mkgmap:bicycle etc.). * mkgmap:carpool does no longer automatically set all access restrictions. In the trunk mkgmap:carpool=yes/1/true lead to set all access restrictions to "no" except emergency, bus and carpool. * The road speed is no longer automatically calculated using the maxspeed tag. New style functions maxspeedkmh() and maxspeedmph() allow style developers to perform the same by setting the mkgmap:road-speed-class tag. * Styles can now have a <finalize> block. This block is executed for each element if an element style definition matches. The finalize block must contain actions only.

There is no need to convert the "old" style files instantly when adding compatibility include files to the finalize block. Example for the lines file: <finalize> include 'inc/compat_lines';

Anyhow I strongly propose to use the new degree of freedom in assigning access restrictions etc. In case you are not convinced about the new features just open the compatibility includes and you will see that access handling in the trunk has some shortcomings.

WanMil _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev