Hi Andrzej, I did not see that with MapSource or Basecamp. Did you test with a device? Gerd popej wrote

Hi Gerd,

now problem is reversed, cycleway is always found first. If I set routing for a car, and then I start a route form a point on road with cycleway, then route uses opposite cycleway. I think previous version was more safe.

-- Best regards, Andrzej

_______________________________________________ mkgmap-dev mailing list

mkgmap-dev@.org

http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

-- View this message in context: http://gis.19327.n5.nabble.com/Patch-v5-correct-make-cycleways-tp5800981p580... Sent from the Mkgmap Development mailing list archive at Nabble.com.

Hi Andrzej, I think Garmin always ignores route restrictions for the start and end of a route if no alternative exists. So you should not expect it to route away from the bad way. It tested with some different route that use a few more streets, and found no problems and very different route for car and bicycle. Gerd Date: Tue, 25 Mar 2014 18:46:28 +0100 From: popej@poczta.onet.pl To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] [Patch v5] correct make-cycleways Hi Gerd, I observe problem in MapSoruce and BaseCamp. See attached picture, there is a route for a car on a cycleway. Second route shows proper result for a car. -- Best regards, Andrzej _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Hi Andrzej, as I said, I found no problems with the new patch, with the previous versions bicycle routing did not work (large detours avoiding the cycle ways). I don't see a new problem in your example. When you plan a route that starts and ends on the same arc, Garmins algo doesn't care about access restrictions. You can see that as well on footways. If I got you right, you fear that one selects the wrong way when planning a route. Or will also the device select the wrong way ? For example, if I configure car routing and start at the place shown in your picture, will the device chose the bicycle arc instead of the car arc? Gerd popej wrote

Hi Gerd,

so actually what problems are solved when mkgmap creates the cycleway first?

IMO the only difference will be at cases like in my example. "Cycleway first" makes problem for car routing while "original first" makes problem for bicycle routing. I would prefer proper car routing.

-- Best regards, Andrzej _______________________________________________ mkgmap-dev mailing list

mkgmap-dev@.org

http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

-- View this message in context: http://gis.19327.n5.nabble.com/Patch-v5-correct-make-cycleways-tp5800981p580... Sent from the Mkgmap Development mailing list archive at Nabble.com.

Hi Andrzej, I prefer v5: - for bicycle, the u-turns are gone, inverse route are equal - for car routing also works, except for the small problem that you describe. I can post some samples where v4 is much worser than v5, I remember routing with bicycle from http://www.openstreetmap.org/?mlat=48.85798&mlon=2.35887#map=19/48.85798/2.3... to http://www.openstreetmap.org/node/2650495593 looked very wrong. Gerd popej wrote

Hi Gerd,

see my previous comments to v4 patch. I haven't found any problems. I have downloaded your gdb example and for me routing was correct. There is a small detour in one route, since it starts on one-way road. But maybe I miss some other problems?

I agree with you that we can't avoid problems, when route starts at road with cycleway. But this is the only case, when I notice difference between v4 and v5. And I prefer v4.

-- Best regards, Andrzej _______________________________________________ mkgmap-dev mailing list

mkgmap-dev@.org

http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

-- View this message in context: http://gis.19327.n5.nabble.com/Patch-v5-correct-make-cycleways-tp5800981p580... Sent from the Mkgmap Development mailing list archive at Nabble.com.

Hi Andrzej,

I wouldn't say it is a small problem. Any car route to or from an address, which happened to be on a one-way road with opposite cycleway, could lead you wrong-way.

OK, did not see that before, but you are right. That is really a "no go".

Consider area near your test route. I see at least 10 cycleways nearby, maybe 20-30% of addresses is affected in this area.

Have you noticed, that car route for your example is wrong-way too?

No, but I did not care as I selected the bicycle ways. I also did not notice that Basecamp - unlike MapSource - doesn't allow to select the way (car or bicycle), at least I did not find out how, so it always choses the first way :-( That makes it likely that the device will also select the wrong type of way. Conclusion: - No matter what method we use either car or bicycle routing is not perfect (this is also true for styles that use continue to create additional ways) - Until that is solved by Garmin, I agree that we should prefer correct car routing and accept detours for bicycles in a general purpose map, so the car road should come first. Attached is version 6 of the patch which is like v5, just reverses the order of ways. Besides, I would prefer to add a few lines to the default style and remove both all hard coded make-cycleway options. Gerd

Hi Andrzej, thanks for your help :-) With --preserve-element-order the ways are passed to the style in the order of the input file. Each time the style creates a line, it is added to either the list of roads (if routable) or the list of non-routable ways. Roads are processed in order of appearance, other lines are processed in order of appearance, but roads are added after non-routable lines. So, to match the version 6 of the patch, the style should first add the road for the car, than the road for the bicycle. I did not yet look at non-routable overlaying lines (e.g. to show bicycle lanes). I'll commit the patch v6 on friday if I hear no complains. I would be glad to receive a patch for the default style that allows us to remove the make-cycleway option. Gerd

Date: Wed, 26 Mar 2014 14:31:47 +0100 From: popej@poczta.onet.pl To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] [Patch v5] correct make-cycleways

Hi Gerd,

I have tested a bit patch v6 and it seems to be OK.

What is the order of roads if cycleway is created as a duplicate in style? Will it be the same as order of declaration in style or reversed?

Using style gives possibility to change road type. This is another factor, which maybe could help.

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

Hi Gerd, probably patch v6 makes opposite-cycleway obligatory, I get them without any option. I have tried simplified version of ligfietser declarations for style and current mkgmap r3129. This has created a cycleway before original road with all the problems like in v5. Additionally there is a problem with house numbers which becomes attached to cycleway. In my case cycleway has a name modified to include "(cycleway)", so I would expect that addr:street of a point shouldn't match. Version with cycleway created after original road would be quite complex, I have dropped this idea. -- Best regards, Andrzej

Hi Gerd,

You should not get them without any option unless you modify the style.

I can't trace what is the primary cause of the problem. I have removed "make-opposite-cycleway" from options and added following lines to default style: highway=* & ( cycleway=opposite | cycleway=opposite_lane | cycleway=opposite_track | oneway:bicycle=no | bicycle:oneway=no ) { set oppoway=yes } highway=* & ( oneway=yes | oneway=1 | oneway=true | oneway=-1 ) & oppoway=yes {set oneway=no; set access=no; set bicycle=yes; name '${name} (rower)' } [0x10 road_speed=1 road_class=1 resolution 24 continue] If I compile map with trunk r3129 then I get additional cycleway with name including "(rower)". If I compile with patched mkgmap, I get two additional cycleways, one with "(rower)" in name, second with "(Cycleway)", exactly like when I use option "make-opposite-cycleway". No problem with default style - no additional cycleway, when no changes in style. I have attached modified style, a data sample and a batch for mkgmap. Watch the way: http://www.openstreetmap.org/way/226392273

what about keeping only the make-opposite-cycleway option?

That is the only option, which I use. I don't see advantages of other cycleways options. But maybe there are some? -- Best regards, Andrzej

Andrzej wrote:

Version with cycleway created after original road would be quite complex, I have dropped this idea.

Here is an example how to do that: 1) block the original highway for cycling: oneway=* & (cycleway=opposite | cycleway=opposite_lane | cycleway=opposite_track | oneway:bicycle=no | bicycle:oneway=no) {set bicycle=no; set mkgmap:cycleway=yes} 2) use continue with_actions for some roads where we can expect opposite cycleways highway=unclassified [0x06 road_class=0 road_speed=3 resolution 21 continue with_actions] continue with_actions also for highway=tertiary, residential, living_street, service 3) create an opposite cycleway, remove the oneway tags and set access open only for bicycle: mkgmap:cycleway=yes {set access=no; set oneway=no; set bicycle=yes} [0x10 road_speed=1 road_class=1] 4) stop continue processing for those highways without mkgmap:cycleway (highway=tertiary|highway=unclassified|highway=residential|highway=living_street|highway=service) & mkgmap:cycleway!=yes {delete 'highway'} The only problem is that when someone starts routing for cycling in a opposite cycleway street, Garmin first thinks it is oneway (doesnt see the underlying mkgmap:cycleway) and at the end of the street, the routing makes a u-turn. See https://www.dropbox.com/s/xikkso92iaszkdb/opposite_cycleway.jpg Blue arrow: oneway for cars, green for cycling.

Hi Andrzej, popej wrote

One question: could the opposite cycleway be limited to layer 0? I don't see any advantages to extend it to lower resolution layers.

you decide that in the style. The artificial cycleways have the tag mkgmap:synthesised=yes Gerd -- View this message in context: http://gis.19327.n5.nabble.com/Patch-v5-correct-make-cycleways-tp5800981p580... Sent from the Mkgmap Development mailing list archive at Nabble.com.

Hi Andrzej,

patch v7 solves problem with second cycleway, support for make-opposite-cycleways seems to be correct too.

puh :-) Quite a lot of version for such a small patch ;-)

...

The artificial cycleways have the tag mkgmap:synthesised=yes

I can't guess how to use it. Could you provide an example?

no :-( I thought that it could be done with a single ike this highway=* & mkgmap:synthesised=yes & bicycle=yes [0x04 road_class=2 road_speed=3 resolution 24] but we probably also want different road classes for the cycleways depending on the highway=* tag value. Maybe we can code a solution in the <finalize> section? Something like highway=* & mkgmap:synthesised=yes & mkgmap:bicycle=yes { set mkgmap:resolution-min = 24 } That would work similar to the mkgmap:road-class-min=* tag. The problem with this is that the original idea was that an "Element type definition" (the stuff in the square brakets) is a constant, and the code required to allow tags like mkgmap:road-class-min=* is very error-prone. Gerd

Hi Paco, paco.tyson wrote

...

It creates the cycleway first (with access for bicycles only) and forbids bicycle for the normal way.

Why do you forbid routing a bicycle on the normal way although it's allowed ? Is this done with the default style or is it hardcoded ?

the patch doesn't change the default style. The patch works more or less like the lines in Minkos sample: http://gis.19327.n5.nabble.com/Patch-v4-distorted-lines-with-make-opposite-c... It first creates a copy of the way, adds some tags to allow bicycle routing in both directions and passes this copy to the style. Next, it adds bicycle=no to the original way and passes that also to the style. Of course, this only happens when the option --make-opposite-cycleway or --make-cycle-way is active. Gerd -- View this message in context: http://gis.19327.n5.nabble.com/Patch-v5-correct-make-cycleways-tp5800981p580... Sent from the Mkgmap Development mailing list archive at Nabble.com.