oneway reverse patch
Hi all, did anybody try this patch attached to this post regarding reversed oneways? http://gis.19327.n5.nabble.com/mkgmap-ToDo-list-tp5803388p5803456.html If anybody is interested in this, I'll create a version that checks the style version file. Idea: If the version is 2 or higher, use the code in the patch, else not. Gerd
Hi Gerd, I think this is also not a clean solution. What happens if the road itself uses a directed symbol? AFAIK your patch handles only non-roads? From my point of view the only clean solution is to reverse all tags. That should not be too complicated copying some parts from the JOSM class. WanMil
Hi all,
did anybody try this patch attached to this post regarding reversed oneways?
http://gis.19327.n5.nabble.com/mkgmap-ToDo-list-tp5803388p5803456.html
If anybody is interested in this, I'll create a version that checks the style version file. Idea: If the version is 2 or higher, use the code in the patch, else not.
Gerd
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi WanMil, okay, I agree that this would be the best solution. I've started a new refactoring branch today, I'd like to finish this work first. Maybe you can look at it: I plan to evaluate all tags used in RoadMerger once in ConvertedWay and place them in fields (most of them are booleans). RoadMerger should then call ConvertedWay.isSimilar() which will implement most of the compare routines now implemented in RoadMerger.Road. Does that sound okay for you? Gerd
Date: Sat, 19 Apr 2014 16:12:06 +0200 From: wmgcnfg@web.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] oneway reverse patch
Hi Gerd,
I think this is also not a clean solution. What happens if the road itself uses a directed symbol? AFAIK your patch handles only non-roads?
From my point of view the only clean solution is to reverse all tags. That should not be too complicated copying some parts from the JOSM class.
WanMil
Hi all,
did anybody try this patch attached to this post regarding reversed oneways?
http://gis.19327.n5.nabble.com/mkgmap-ToDo-list-tp5803388p5803456.html
If anybody is interested in this, I'll create a version that checks the style version file. Idea: If the version is 2 or higher, use the code in the patch, else not.
Gerd
_______________________________________________ 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
Hi Gerd,
Hi WanMil,
okay, I agree that this would be the best solution.
I've started a new refactoring branch today, I'd like to finish this work first.
Ok, anyhow I will slowly start with some tests with the tag reverser. I think most of it will be static so it won't hurt if other things are refactored.
Maybe you can look at it: I plan to evaluate all tags used in RoadMerger once in ConvertedWay and place them in fields (most of them are booleans). RoadMerger should then call ConvertedWay.isSimilar() which will implement most of the compare routines now implemented in RoadMerger.Road. Does that sound okay for you?
I don't see the big advantage now but I am sure you have a good idea why it helps :-) One small comment: I have some doubts that it is a good idea to put the isSimilar() method to the ConvertedWay class. There is a similar approach in MapElement. But the implementation does not really help. Maybe there are also different views at different stages of the processing if two elements are similar or not. So better leave the isSimilar method at the RoadMerger who knows better if the two elements can be merged or not. WanMil
Gerd
Date: Sat, 19 Apr 2014 16:12:06 +0200 From: wmgcnfg@web.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] oneway reverse patch
Hi Gerd,
I think this is also not a clean solution. What happens if the road itself uses a directed symbol? AFAIK your patch handles only non-roads?
From my point of view the only clean solution is to reverse all tags. That should not be too complicated copying some parts from the JOSM class.
WanMil
Hi all,
did anybody try this patch attached to this post regarding reversed oneways?
http://gis.19327.n5.nabble.com/mkgmap-ToDo-list-tp5803388p5803456.html
If anybody is interested in this, I'll create a version that checks the style version file. Idea: If the version is 2 or higher, use the code in the patch, else not.
Gerd
_______________________________________________ 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
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi WanMil,
Ok, anyhow I will slowly start with some tests with the tag reverser. I think most of it will be static so it won't hurt if other things are refactored. Great. If you can implement it in HighwayHooks it should not create problems.
Maybe you can look at it: I plan to evaluate all tags used in RoadMerger once in ConvertedWay and place them in fields (most of them are booleans). RoadMerger should then call ConvertedWay.isSimilar() which will implement most of the compare routines now implemented in RoadMerger.Road. Does that sound okay for you?
I don't see the big advantage now but I am sure you have a good idea why it helps :-) One small comment: I have some doubts that it is a good idea to put the isSimilar() method to the ConvertedWay class. There is a similar approach in MapElement. But the implementation does not really help. Maybe there are also different views at different stages of the processing if two elements are similar or not. So better leave the isSimilar method at the RoadMerger who knows better if the two elements can be merged or not.
Good point. My idea is that RoadMerger should use the ConvertedWay instances instead of creating new Road instances, but most of the code in RoadMerger is in the Road class. Gerd
Is this patch still needed? I must say it didn't work at all anyhow so far. I think the problem is that for many ways I don't add oneway tag, but still need the reversal to work as in 2013. Here is a list of direction dependant tags - that also if no oneway present MUST make sure that road is not reversed or old behaviour kept: incline bicycle:left bicycle:right oneway:bicycle bicycle:oneway cycleway:left cycleway:right (and maybe some others I right now don't recall). So far I haven't been able to render a correct map, with or without patch. But I noticed that the patch doesn't apply clean anymore and conflicts - so is there something for the better? Far too often the bicycle way has been on the wrong side of the road, or arrows showing difficult to bike uphill (incline & mtb:scale:uphill>1) way arrows showing wrong direction! (P.S. I'm basically still detached from fast internet and can only start playing around from next Monday). On 20.04.2014 13:45, Gerd Petermann wrote:
Hi WanMil,
Ok, anyhow I will slowly start with some tests with the tag reverser. I think most of it will be static so it won't hurt if other things are refactored. Great. If you can implement it in HighwayHooks it should not create problems.
Maybe you can look at it: I plan to evaluate all tags used in RoadMerger once in ConvertedWay and place them in fields (most of them are booleans). RoadMerger should then call ConvertedWay.isSimilar() which will implement most of the compare routines now implemented in RoadMerger.Road. Does that sound okay for you?
I don't see the big advantage now but I am sure you have a good idea
why
it helps :-) One small comment: I have some doubts that it is a good idea to put the isSimilar() method to the ConvertedWay class. There is a similar approach in MapElement. But the implementation does not really help. Maybe there are also different views at different stages of the processing if two elements are similar or not. So better leave the isSimilar method at the RoadMerger who knows better if the two elements can be merged or not.
Good point. My idea is that RoadMerger should use the ConvertedWay instances instead of creating new Road instances, but most of the code in RoadMerger is in the Road class.
Gerd
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
I dont have any difficulties with mkgmap showing arrows in the wrong direction, or routing going the wrong way. I do see that sometimes the bike lane is drawn on the wrong side of the road, but this is a Garmin bug. In Mapsource and Basecamp it is rendered on the correct side, but on the newer Garmins it is rendered on the opposite (wrong) side. On older units it is rendered ok. Garmin is aware of this issue but hasn't done anything for years.
On 24.04.2014 23:14, Minko wrote:
I dont have any difficulties with mkgmap showing arrows in the wrong direction, or routing going the wrong way. Well it didn't seem to work for me (at least using the patch with the most up to date mkgmap trunk version last Thursday) I do see that sometimes the bike lane is drawn on the wrong side of the road, but this is a Garmin bug. In Mapsource and Basecamp it is rendered on the correct side, but on the newer Garmins it is rendered on the opposite (wrong) side. On older units it is rendered ok. Garmin is aware of this issue but hasn't done anything for years. That's a bug - correct. But actually it's not sometimes, but all the time - I was first to report this over 3 years ago on the us garmin forum (mapsource 6.14) and actually one dev sometimes even promised to fix it but never got to do it. All asymetric lines are rendered the opposite side on Computer vs GPS unit (I think mapsource 6.13 is same side as GPS however). Garmin doesn't care as they never used asymetric lines (I was the first one to do so using transparency) - the only had asymetric lines in so far as older GPS units/mapsource 6.13 didn't render 2,4,6,8,... pixel lines actually in the middle (only 1,3,5 where actually centered) - and now that they started using asymetric lines - they don't have them dependent on direction...
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Felix, the problem with oneway=-1 should not appear often. If I got you right you say that there is another problem with roads that have a direction? Can you give an example ? Just the OSM id of a way that causes problems with your style. Maybe we find that Minkos style has the same problem, maybe we find that Minko found a better solution. Gerd
Date: Thu, 24 Apr 2014 23:26:53 +0800 From: extremecarver@gmail.com To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] oneway reverse patch
On 24.04.2014 23:14, Minko wrote:
I dont have any difficulties with mkgmap showing arrows in the wrong direction, or routing going the wrong way. Well it didn't seem to work for me (at least using the patch with the most up to date mkgmap trunk version last Thursday) I do see that sometimes the bike lane is drawn on the wrong side of the road, but this is a Garmin bug. In Mapsource and Basecamp it is rendered on the correct side, but on the newer Garmins it is rendered on the opposite (wrong) side. On older units it is rendered ok. Garmin is aware of this issue but hasn't done anything for years. That's a bug - correct. But actually it's not sometimes, but all the time - I was first to report this over 3 years ago on the us garmin forum (mapsource 6.14) and actually one dev sometimes even promised to fix it but never got to do it. All asymetric lines are rendered the opposite side on Computer vs GPS unit (I think mapsource 6.13 is same side as GPS however). Garmin doesn't care as they never used asymetric lines (I was the first one to do so using transparency) - the only had asymetric lines in so far as older GPS units/mapsource 6.13 didn't render 2,4,6,8,... pixel lines actually in the middle (only 1,3,5 where actually centered) - and now that they started using asymetric lines - they don't have them dependent on direction...
_______________________________________________ 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
I don't think that Minkos style shows cycleways on the left/right side of a road - am I wrong? - Anyhow they would usually have a oneway tag already in OSM data. Also definitely no uphill/downhill arrows - which nearly never actually have a oneway tag (and only sometimes I add one during processing). The routing I don't want to stress right now - I still have to play a bit on that due to the rather recent Basecamp changes again... (as I usually want to have routing in both directions, but at different priority). I probably won't be able to get hard facts till monday with OSM links... (I cannot access my own SVN server - and mkgmap SVN is taking ages and often not responding either here). On 24.04.2014 23:35, Gerd Petermann wrote:
Hi Felix,
the problem with oneway=-1 should not appear often. If I got you right you say that there is another problem with roads that have a direction? Can you give an example ? Just the OSM id of a way that causes problems with your style. Maybe we find that Minkos style has the same problem, maybe we find that Minko found a better solution.
Gerd
Date: Thu, 24 Apr 2014 23:26:53 +0800 From: extremecarver@gmail.com To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] oneway reverse patch
On 24.04.2014 23:14, Minko wrote:
I dont have any difficulties with mkgmap showing arrows in the wrong direction, or routing going the wrong way. Well it didn't seem to work for me (at least using the patch with the most up to date mkgmap trunk version last Thursday) I do see that sometimes the bike lane is drawn on the wrong side of the road, but this is a Garmin bug. In Mapsource and Basecamp it is rendered on the correct side, but on the newer Garmins it is rendered on the opposite (wrong) side. On older units it is rendered ok. Garmin is aware of this issue but hasn't done anything for years. That's a bug - correct. But actually it's not sometimes, but all the time - I was first to report this over 3 years ago on the us garmin forum (mapsource 6.14) and actually one dev sometimes even promised to fix it but never got to do it. All asymetric lines are rendered the opposite side on Computer vs GPS unit (I think mapsource 6.13 is same side as GPS however). Garmin doesn't care as they never used asymetric lines (I was the first one to do so using transparency) - the only had asymetric lines in so far as older GPS units/mapsource 6.13 didn't render 2,4,6,8,... pixel lines actually in the middle (only 1,3,5 where actually centered) - and now that they started using asymetric lines - they don't have them dependent on direction...
_______________________________________________ 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
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Felix, okay, so let's wait for some details from you next week. Gerd Date: Thu, 24 Apr 2014 23:49:06 +0800 From: extremecarver@gmail.com To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] oneway reverse patch I don't think that Minkos style shows cycleways on the left/right side of a road - am I wrong? - Anyhow they would usually have a oneway tag already in OSM data. Also definitely no uphill/downhill arrows - which nearly never actually have a oneway tag (and only sometimes I add one during processing). The routing I don't want to stress right now - I still have to play a bit on that due to the rather recent Basecamp changes again... (as I usually want to have routing in both directions, but at different priority). I probably won't be able to get hard facts till monday with OSM links... (I cannot access my own SVN server - and mkgmap SVN is taking ages and often not responding either here). On 24.04.2014 23:35, Gerd Petermann wrote: Hi Felix, the problem with oneway=-1 should not appear often. If I got you right you say that there is another problem with roads that have a direction? Can you give an example ? Just the OSM id of a way that causes problems with your style. Maybe we find that Minkos style has the same problem, maybe we find that Minko found a better solution. Gerd > Date: Thu, 24 Apr 2014 23:26:53 +0800 > From: extremecarver@gmail.com > To: mkgmap-dev@lists.mkgmap.org.uk > Subject: Re: [mkgmap-dev] oneway reverse patch > > > On 24.04.2014 23:14, Minko wrote: > > I dont have any difficulties with mkgmap showing arrows in the wrong direction, or routing going the wrong way. > Well it didn't seem to work for me (at least using the patch with the > most up to date mkgmap trunk version last Thursday) > > I do see that sometimes the bike lane is drawn on the wrong side of the road, but this is a Garmin bug. > > In Mapsource and Basecamp it is rendered on the correct side, but on the newer Garmins it is rendered on the opposite (wrong) side. On older units it is rendered ok. > > Garmin is aware of this issue but hasn't done anything for years. > That's a bug - correct. But actually it's not sometimes, but all the > time - I was first to report this over 3 years ago on the us garmin > forum (mapsource 6.14) and actually one dev sometimes even promised to > fix it but never got to do it. All asymetric lines are rendered the > opposite side on Computer vs GPS unit (I think mapsource 6.13 is same > side as GPS however). Garmin doesn't care as they never used asymetric > lines (I was the first one to do so using transparency) - the only had > asymetric lines in so far as older GPS units/mapsource 6.13 didn't > render 2,4,6,8,... pixel lines actually in the middle (only 1,3,5 where > actually centered) - and now that they started using asymetric lines - > they don't have them dependent on direction... > > > > _______________________________________________ > > 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 _______________________________________________ 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
Yes I render cycleway:left and cycleway:right too. And as you say, they are always on the wrong side on the GPS. Interesting to know that Garmin uses asymmetric lines independent of the road direction. If we only could find out how they do this... Felix wrote
I don't think that Minkos style shows cycleways on the left/right side of a road - am I wrong? - Anyhow they would usually have a oneway tag already in OSM data. Also definitely no uphill/downhill arrows - which nearly never actually have a oneway tag (and only sometimes I add one during processing).
Nope, with independent I meant - they only use it for features where it doesn't matter. Namely Routes. Never seen asymetric lines in any other use. But I haven't seen all .typ files from Garmin - but try to always get the newest demo maps and anlyze the .typfile. Lately been a bit lazy on that though... On 25.04.2014 00:39, Minko wrote:
Yes I render cycleway:left and cycleway:right too. And as you say, they are always on the wrong side on the GPS. Interesting to know that Garmin uses asymmetric lines independent of the road direction. If we only could find out how they do this...
Felix wrote
I don't think that Minkos style shows cycleways on the left/right side of a road - am I wrong? - Anyhow they would usually have a oneway tag already in OSM data. Also definitely no uphill/downhill arrows - which nearly never actually have a oneway tag (and only sometimes I add one during processing).
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Ups - but forgot to say. I think in 99% of all cases - cycleway:left and cycleway:right are used on streets which feature oneway=yes... less often oneway=-1 and even less often no oneway at all. Streets with oneway=yes are fine. I'm talking about no oneway tag from OSM data at all, or oneway=-1 set in style (but no oneway from OSM data) or no oneway at all. Only on those there are problems - so you're not likely to notice them I think.... On 25 April 2014 00:39, Minko <ligfietser@online.nl> wrote:
Yes I render cycleway:left and cycleway:right too. And as you say, they are always on the wrong side on the GPS. Interesting to know that Garmin uses asymmetric lines independent of the road direction. If we only could find out how they do this...
Felix wrote
I don't think that Minkos style shows cycleways on the left/right side of a road - am I wrong? - Anyhow they would usually have a oneway tag already in OSM data. Also definitely no uphill/downhill arrows - which nearly never actually have a oneway tag (and only sometimes I add one during processing).
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
I dont have multiple routable lines for cycleway:right or cycleway:left. Those roads have just one routable line in my styles, and one non-routable line to render this cycleway lane or track. Do you use two routable lines, one for highway=* and one for cycleway:right=track?
Ups - but forgot to say. I think in 99% of all cases - cycleway:left and cycleway:right are used on streets which feature oneway=yes... less often oneway=-1 and even less often no oneway at all. Streets with oneway=yes are fine. I'm talking about no oneway tag from OSM data at all, or oneway=-1 set in style (but no oneway from OSM data) or no oneway at all. Only on those there are problems - so you're not likely to notice them I think....
Hi Felix, if your style interprets a tag like a oneway=yes you should add that tag. This might prevent problems caused by the RoadMerger, which might reverse lines which are not oneways. If you find or set oneway=-1, the current implementation will reverse the way. If you add multiple routable lines for one OSM way, one with, one without the oneway tag, you will see unpredictable directions if such a way is modified by the WrongAngleFixer and the type is direction dependent. The WrongAngleFixer assumes that the points in all ways with the same OSM id are equal, so it optimizes one way and copies the points to the others. This will fail if they have different oneway attributes. If you think this could be the cause of the problem, I should be able to provide a fix. Gerd Date: Fri, 25 Apr 2014 01:00:18 +0800 From: extremecarver@gmail.com To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] oneway reverse patch Ups - but forgot to say. I think in 99% of all cases - cycleway:left and cycleway:right are used on streets which feature oneway=yes... less often oneway=-1 and even less often no oneway at all. Streets with oneway=yes are fine. I'm talking about no oneway tag from OSM data at all, or oneway=-1 set in style (but no oneway from OSM data) or no oneway at all. Only on those there are problems - so you're not likely to notice them I think.... On 25 April 2014 00:39, Minko <ligfietser@online.nl> wrote: Yes I render cycleway:left and cycleway:right too. And as you say, they are always on the wrong side on the GPS. Interesting to know that Garmin uses asymmetric lines independent of the road direction. If we only could find out how they do this... Felix wrote
I don't think that Minkos style shows cycleways on the left/right side
of a road - am I wrong? - Anyhow they would usually have a oneway tag
already in OSM data.
Also definitely no uphill/downhill arrows - which nearly never
actually have a oneway tag (and only sometimes I add one during
processing).
_______________________________________________ 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
Yes I both add opposite oneway on the same road as well as only one oneway or no oneway. It is highly important that the order is followed strictly and continue vs continue with actions is strictly enacted in order. All reversing should happen at the time its placed in the style. !! Sometimes I reverse a way 3 times during processing. All I can say right now its a bit of a mess On Apr 25, 2014 2:24 AM, "Gerd Petermann" <gpetermann_muenchen@hotmail.com> wrote:
Hi Felix,
if your style interprets a tag like a oneway=yes you should add that tag. This might prevent problems caused by the RoadMerger, which might reverse lines which are not oneways. If you find or set oneway=-1, the current implementation will reverse the way. If you add multiple routable lines for one OSM way, one with, one without the oneway tag, you will see unpredictable directions if such a way is modified by the WrongAngleFixer and the type is direction dependent. The WrongAngleFixer assumes that the points in all ways with the same OSM id are equal, so it optimizes one way and copies the points to the others. This will fail if they have different oneway attributes. If you think this could be the cause of the problem, I should be able to provide a fix.
Gerd
------------------------------ Date: Fri, 25 Apr 2014 01:00:18 +0800 From: extremecarver@gmail.com To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] oneway reverse patch
Ups - but forgot to say. I think in 99% of all cases - cycleway:left and cycleway:right are used on streets which feature oneway=yes... less often oneway=-1 and even less often no oneway at all. Streets with oneway=yes are fine. I'm talking about no oneway tag from OSM data at all, or oneway=-1 set in style (but no oneway from OSM data) or no oneway at all. Only on those there are problems - so you're not likely to notice them I think....
On 25 April 2014 00:39, Minko <ligfietser@online.nl> wrote:
Yes I render cycleway:left and cycleway:right too. And as you say, they are always on the wrong side on the GPS. Interesting to know that Garmin uses asymmetric lines independent of the road direction. If we only could find out how they do this...
Felix wrote
I don't think that Minkos style shows cycleways on the left/right side of a road - am I wrong? - Anyhow they would usually have a oneway tag already in OSM data. Also definitely no uphill/downhill arrows - which nearly never actually have a oneway tag (and only sometimes I add one during processing).
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
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Oh and I of course also add multiple routable lines sometimes. Up to 6 per way in osm as 7 produces crashes on garmins side. Often one routable line has direction but no oneway while the copy is higher importance for routing and oneway (and might be reversed). I need to reverse sometimes to save on the number of lines in type file too - other times its about routing! On Apr 25, 2014 9:19 AM, "Felix Hartmann" <extremecarver@gmail.com> wrote:
Yes I both add opposite oneway on the same road as well as only one oneway or no oneway. It is highly important that the order is followed strictly and continue vs continue with actions is strictly enacted in order. All reversing should happen at the time its placed in the style. !!
Sometimes I reverse a way 3 times during processing. All I can say right now its a bit of a mess On Apr 25, 2014 2:24 AM, "Gerd Petermann" <gpetermann_muenchen@hotmail.com> wrote:
Hi Felix,
if your style interprets a tag like a oneway=yes you should add that tag. This might prevent problems caused by the RoadMerger, which might reverse lines which are not oneways. If you find or set oneway=-1, the current implementation will reverse the way. If you add multiple routable lines for one OSM way, one with, one without the oneway tag, you will see unpredictable directions if such a way is modified by the WrongAngleFixer and the type is direction dependent. The WrongAngleFixer assumes that the points in all ways with the same OSM id are equal, so it optimizes one way and copies the points to the others. This will fail if they have different oneway attributes. If you think this could be the cause of the problem, I should be able to provide a fix.
Gerd
------------------------------ Date: Fri, 25 Apr 2014 01:00:18 +0800 From: extremecarver@gmail.com To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] oneway reverse patch
Ups - but forgot to say. I think in 99% of all cases - cycleway:left and cycleway:right are used on streets which feature oneway=yes... less often oneway=-1 and even less often no oneway at all. Streets with oneway=yes are fine. I'm talking about no oneway tag from OSM data at all, or oneway=-1 set in style (but no oneway from OSM data) or no oneway at all. Only on those there are problems - so you're not likely to notice them I think....
On 25 April 2014 00:39, Minko <ligfietser@online.nl> wrote:
Yes I render cycleway:left and cycleway:right too. And as you say, they are always on the wrong side on the GPS. Interesting to know that Garmin uses asymmetric lines independent of the road direction. If we only could find out how they do this...
Felix wrote
I don't think that Minkos style shows cycleways on the left/right side of a road - am I wrong? - Anyhow they would usually have a oneway tag already in OSM data. Also definitely no uphill/downhill arrows - which nearly never actually have a oneway tag (and only sometimes I add one during processing).
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
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Oh forgot to mention. I also sometimes set oneway yes. Then continue and oneway -1 then contune. All non routable. I don't use continue with actions so I depend on strict work down of lines file as routable non oneway road copies follow On Apr 25, 2014 9:25 AM, "Felix Hartmann" <extremecarver@gmail.com> wrote:
Oh and I of course also add multiple routable lines sometimes. Up to 6 per way in osm as 7 produces crashes on garmins side. Often one routable line has direction but no oneway while the copy is higher importance for routing and oneway (and might be reversed). I need to reverse sometimes to save on the number of lines in type file too - other times its about routing! On Apr 25, 2014 9:19 AM, "Felix Hartmann" <extremecarver@gmail.com> wrote:
Yes I both add opposite oneway on the same road as well as only one oneway or no oneway. It is highly important that the order is followed strictly and continue vs continue with actions is strictly enacted in order. All reversing should happen at the time its placed in the style. !!
Sometimes I reverse a way 3 times during processing. All I can say right now its a bit of a mess On Apr 25, 2014 2:24 AM, "Gerd Petermann" < gpetermann_muenchen@hotmail.com> wrote:
Hi Felix,
if your style interprets a tag like a oneway=yes you should add that tag. This might prevent problems caused by the RoadMerger, which might reverse lines which are not oneways. If you find or set oneway=-1, the current implementation will reverse the way. If you add multiple routable lines for one OSM way, one with, one without the oneway tag, you will see unpredictable directions if such a way is modified by the WrongAngleFixer and the type is direction dependent. The WrongAngleFixer assumes that the points in all ways with the same OSM id are equal, so it optimizes one way and copies the points to the others. This will fail if they have different oneway attributes. If you think this could be the cause of the problem, I should be able to provide a fix.
Gerd
------------------------------ Date: Fri, 25 Apr 2014 01:00:18 +0800 From: extremecarver@gmail.com To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] oneway reverse patch
Ups - but forgot to say. I think in 99% of all cases - cycleway:left and cycleway:right are used on streets which feature oneway=yes... less often oneway=-1 and even less often no oneway at all. Streets with oneway=yes are fine. I'm talking about no oneway tag from OSM data at all, or oneway=-1 set in style (but no oneway from OSM data) or no oneway at all. Only on those there are problems - so you're not likely to notice them I think....
On 25 April 2014 00:39, Minko <ligfietser@online.nl> wrote:
Yes I render cycleway:left and cycleway:right too. And as you say, they are always on the wrong side on the GPS. Interesting to know that Garmin uses asymmetric lines independent of the road direction. If we only could find out how they do this...
Felix wrote
I don't think that Minkos style shows cycleways on the left/right side of a road - am I wrong? - Anyhow they would usually have a oneway tag already in OSM data. Also definitely no uphill/downhill arrows - which nearly never actually have a oneway tag (and only sometimes I add one during processing).
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
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Felix, okay, I think that this explains your problems. The current code in mkgmap simply doesn't expect lines based on the same OSM way to go in different directions. I am pretty sure that you get unpredictable results when doing that. In most places I don't see a problem to support that, but I fear that the code for restriction relations will be a problem. Thinking about it... Gerd Date: Fri, 25 Apr 2014 09:30:54 +0800 From: extremecarver@gmail.com To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] oneway reverse patch Oh forgot to mention. I also sometimes set oneway yes. Then continue and oneway -1 then contune. All non routable. I don't use continue with actions so I depend on strict work down of lines file as routable non oneway road copies follow On Apr 25, 2014 9:25 AM, "Felix Hartmann" <extremecarver@gmail.com> wrote: Oh and I of course also add multiple routable lines sometimes. Up to 6 per way in osm as 7 produces crashes on garmins side. Often one routable line has direction but no oneway while the copy is higher importance for routing and oneway (and might be reversed). I need to reverse sometimes to save on the number of lines in type file too - other times its about routing! On Apr 25, 2014 9:19 AM, "Felix Hartmann" <extremecarver@gmail.com> wrote: Yes I both add opposite oneway on the same road as well as only one oneway or no oneway. It is highly important that the order is followed strictly and continue vs continue with actions is strictly enacted in order. All reversing should happen at the time its placed in the style. !! Sometimes I reverse a way 3 times during processing. All I can say right now its a bit of a mess On Apr 25, 2014 2:24 AM, "Gerd Petermann" <gpetermann_muenchen@hotmail.com> wrote: Hi Felix, if your style interprets a tag like a oneway=yes you should add that tag. This might prevent problems caused by the RoadMerger, which might reverse lines which are not oneways. If you find or set oneway=-1, the current implementation will reverse the way. If you add multiple routable lines for one OSM way, one with, one without the oneway tag, you will see unpredictable directions if such a way is modified by the WrongAngleFixer and the type is direction dependent. The WrongAngleFixer assumes that the points in all ways with the same OSM id are equal, so it optimizes one way and copies the points to the others. This will fail if they have different oneway attributes. If you think this could be the cause of the problem, I should be able to provide a fix. Gerd Date: Fri, 25 Apr 2014 01:00:18 +0800 From: extremecarver@gmail.com To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] oneway reverse patch Ups - but forgot to say. I think in 99% of all cases - cycleway:left and cycleway:right are used on streets which feature oneway=yes... less often oneway=-1 and even less often no oneway at all. Streets with oneway=yes are fine. I'm talking about no oneway tag from OSM data at all, or oneway=-1 set in style (but no oneway from OSM data) or no oneway at all. Only on those there are problems - so you're not likely to notice them I think.... On 25 April 2014 00:39, Minko <ligfietser@online.nl> wrote: Yes I render cycleway:left and cycleway:right too. And as you say, they are always on the wrong side on the GPS. Interesting to know that Garmin uses asymmetric lines independent of the road direction. If we only could find out how they do this... Felix wrote
I don't think that Minkos style shows cycleways on the left/right side
of a road - am I wrong? - Anyhow they would usually have a oneway tag
already in OSM data.
Also definitely no uphill/downhill arrows - which nearly never
actually have a oneway tag (and only sometimes I add one during
processing).
_______________________________________________ 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 _______________________________________________ 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
On 25.04.2014 12:26, Gerd Petermann wrote:
Hi Felix,
okay, I think that this explains your problems. The current code in mkgmap simply doesn't expect lines based on the same OSM way to go in different directions. I am pretty sure that you get unpredictable results when doing that.
In most places I don't see a problem to support that, but I fear that the code for restriction relations will be a problem. Thinking about it... Well I'm still using --no-turn-restrictions anyhow....
However I would see a second possibility. Create another file in the style-file called direction-dependent-lines where one lists all types (0x????? 0x?? 0x???? .... ) that mkmgap may not reverse because the outcome is dependent on the direction of the way due to the layout chosen in the typfile. Or add all tags - but that would be less reliable. Anyhow - the turn-restrictions are still a mystery to me - both in mkgmap as well as in OSM. I'm pretty sure 50% of the turn restrictions in OSM will not be followed by cyclists (either they actually don't have to, or there are quicker possibilities (e.g. using the footway crossing) or simply knowing that noone cares what cyclists do in that case... Especially I would say no cyclists respects right turn restriction in drive-right countries (and some vice-versa for drive-left). Therefore for now I still prefer to completly disrespect them in the map.
Gerd
------------------------------------------------------------------------ Date: Fri, 25 Apr 2014 09:30:54 +0800 From: extremecarver@gmail.com To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] oneway reverse patch
Oh forgot to mention. I also sometimes set oneway yes. Then continue and oneway -1 then contune. All non routable. I don't use continue with actions so I depend on strict work down of lines file as routable non oneway road copies follow
On Apr 25, 2014 9:25 AM, "Felix Hartmann" <extremecarver@gmail.com <mailto:extremecarver@gmail.com>> wrote:
Oh and I of course also add multiple routable lines sometimes. Up to 6 per way in osm as 7 produces crashes on garmins side. Often one routable line has direction but no oneway while the copy is higher importance for routing and oneway (and might be reversed). I need to reverse sometimes to save on the number of lines in type file too - other times its about routing!
On Apr 25, 2014 9:19 AM, "Felix Hartmann" <extremecarver@gmail.com <mailto:extremecarver@gmail.com>> wrote:
Yes I both add opposite oneway on the same road as well as only one oneway or no oneway. It is highly important that the order is followed strictly and continue vs continue with actions is strictly enacted in order. All reversing should happen at the time its placed in the style. !!
Sometimes I reverse a way 3 times during processing. All I can say right now its a bit of a mess
On Apr 25, 2014 2:24 AM, "Gerd Petermann" <gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com>> wrote:
Hi Felix,
if your style interprets a tag like a oneway=yes you should add that tag. This might prevent problems caused by the RoadMerger, which might reverse lines which are not oneways. If you find or set oneway=-1, the current implementation will reverse the way. If you add multiple routable lines for one OSM way, one with, one without the oneway tag, you will see unpredictable directions if such a way is modified by the WrongAngleFixer and the type is direction dependent. The WrongAngleFixer assumes that the points in all ways with the same OSM id are equal, so it optimizes one way and copies the points to the others. This will fail if they have different oneway attributes. If you think this could be the cause of the problem, I should be able to provide a fix.
Gerd
------------------------------------------------------------------------ Date: Fri, 25 Apr 2014 01:00:18 +0800 From: extremecarver@gmail.com <mailto:extremecarver@gmail.com> To: mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] oneway reverse patch
Ups - but forgot to say. I think in 99% of all cases - cycleway:left and cycleway:right are used on streets which feature oneway=yes... less often oneway=-1 and even less often no oneway at all. Streets with oneway=yes are fine. I'm talking about no oneway tag from OSM data at all, or oneway=-1 set in style (but no oneway from OSM data) or no oneway at all. Only on those there are problems - so you're not likely to notice them I think....
On 25 April 2014 00:39, Minko <ligfietser@online.nl <mailto:ligfietser@online.nl>> wrote:
Yes I render cycleway:left and cycleway:right too. And as you say, they are always on the wrong side on the GPS. Interesting to know that Garmin uses asymmetric lines independent of the road direction. If we only could find out how they do this...
Felix wrote > I don't think that Minkos style shows cycleways on the left/right side > of a road - am I wrong? - Anyhow they would usually have a oneway tag > already in OSM data. > Also definitely no uphill/downhill arrows - which nearly never > actually have a oneway tag (and only sometimes I add one during > processing). _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk <mailto: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 <mailto: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 <mailto: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
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Felix, the reversing has a reason. It is needed for routing. Some days ago WanMil asked in a pm if it isn't possible to skip the reversing and change the way how the data is written to the img file. I answered that this is complicated, but maybe I was wrong. The img file has the information that a way is a oneway. We save both the forward arc and the reverse arc between two routing nodes. If I got that right we just have to make sure that we mark the correct arc as forward/reverse. I'll try to create a small test style that creates multiple ways with conflicting oneway tags and see what happens. There are so many places were this matters. If I can't find a good solution, you may send a sample style and test data next week. Gerd Date: Fri, 25 Apr 2014 13:43:51 +0800 From: extremecarver@gmail.com To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] oneway reverse patch On 25.04.2014 12:26, Gerd Petermann wrote: Hi Felix, okay, I think that this explains your problems. The current code in mkgmap simply doesn't expect lines based on the same OSM way to go in different directions. I am pretty sure that you get unpredictable results when doing that. In most places I don't see a problem to support that, but I fear that the code for restriction relations will be a problem. Thinking about it... Well I'm still using --no-turn-restrictions anyhow.... However I would see a second possibility. Create another file in the style-file called direction-dependent-lines where one lists all types (0x????? 0x?? 0x???? .... ) that mkmgap may not reverse because the outcome is dependent on the direction of the way due to the layout chosen in the typfile. Or add all tags - but that would be less reliable. Anyhow - the turn-restrictions are still a mystery to me - both in mkgmap as well as in OSM. I'm pretty sure 50% of the turn restrictions in OSM will not be followed by cyclists (either they actually don't have to, or there are quicker possibilities (e.g. using the footway crossing) or simply knowing that noone cares what cyclists do in that case... Especially I would say no cyclists respects right turn restriction in drive-right countries (and some vice-versa for drive-left). Therefore for now I still prefer to completly disrespect them in the map. Gerd Date: Fri, 25 Apr 2014 09:30:54 +0800 From: extremecarver@gmail.com To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] oneway reverse patch Oh forgot to mention. I also sometimes set oneway yes. Then continue and oneway -1 then contune. All non routable. I don't use continue with actions so I depend on strict work down of lines file as routable non oneway road copies follow On Apr 25, 2014 9:25 AM, "Felix Hartmann" <extremecarver@gmail.com> wrote: Oh and I of course also add multiple routable lines sometimes. Up to 6 per way in osm as 7 produces crashes on garmins side. Often one routable line has direction but no oneway while the copy is higher importance for routing and oneway (and might be reversed). I need to reverse sometimes to save on the number of lines in type file too - other times its about routing! On Apr 25, 2014 9:19 AM, "Felix Hartmann" <extremecarver@gmail.com> wrote: Yes I both add opposite oneway on the same road as well as only one oneway or no oneway. It is highly important that the order is followed strictly and continue vs continue with actions is strictly enacted in order. All reversing should happen at the time its placed in the style. !! Sometimes I reverse a way 3 times during processing. All I can say right now its a bit of a mess On Apr 25, 2014 2:24 AM, "Gerd Petermann" <gpetermann_muenchen@hotmail.com> wrote: Hi Felix, if your style interprets a tag like a oneway=yes you should add that tag. This might prevent problems caused by the RoadMerger, which might reverse lines which are not oneways. If you find or set oneway=-1, the current implementation will reverse the way. If you add multiple routable lines for one OSM way, one with, one without the oneway tag, you will see unpredictable directions if such a way is modified by the WrongAngleFixer and the type is direction dependent. The WrongAngleFixer assumes that the points in all ways with the same OSM id are equal, so it optimizes one way and copies the points to the others. This will fail if they have different oneway attributes. If you think this could be the cause of the problem, I should be able to provide a fix. Gerd Date: Fri, 25 Apr 2014 01:00:18 +0800 From: extremecarver@gmail.com To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] oneway reverse patch Ups - but forgot to say. I think in 99% of all cases - cycleway:left and cycleway:right are used on streets which feature oneway=yes... less often oneway=-1 and even less often no oneway at all. Streets with oneway=yes are fine. I'm talking about no oneway tag from OSM data at all, or oneway=-1 set in style (but no oneway from OSM data) or no oneway at all. Only on those there are problems - so you're not likely to notice them I think.... On 25 April 2014 00:39, Minko <ligfietser@online.nl> wrote: Yes I render cycleway:left and cycleway:right too. And as you say, they are always on the wrong side on the GPS. Interesting to know that Garmin uses asymmetric lines independent of the road direction. If we only could find out how they do this... Felix wrote > I don't think that Minkos style shows cycleways on the left/right side > of a road - am I wrong? - Anyhow they would usually have a oneway tag > already in OSM data. > Also definitely no uphill/downhill arrows - which nearly never > actually have a oneway tag (and only sometimes I add one during > processing). _______________________________________________ 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 _______________________________________________ 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 _______________________________________________ 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
participants (4)
-
Felix Hartmann -
Gerd Petermann -
Minko -
WanMil