Line direction flag, merging etc
Hi Gerd and others I'm starting a dedicated thread as previous posts are split between various svn commits. Looking at the current trunk code and ignore-oneway-for-lines.patch, there are bits I don't understand or didn't expect. This is what I hope for: --line-types-with-direction lists the lineTypes for which the initial state of the hasDirection flag is considered true. It should be independent of --allow-reverse-merge (see later). The purpose of this is to reduce the need to edit styles and clarity as to which lineTypes are displayed with direction. In the following, road means line with [road_class, road_speed], so includes ferries. Style processing, having produced a line/road, sets hasDirection, in order of precedence: 1/ value of mkgmap:has-direction if tag exists 2/ true if oneway road 3/ true if in line-types-with-direction list RoadMerger merges roads with same lineType, names, class, speed, oneway and hasDirection. It must not reverse oneway or hasDirection=true roads when doing this. I don't think we need --allow-reverse-merge. LineMergeFilter operates for level > 0. It merges any line/road with the same lineType, names, hasDirection. It must not reverse hasDirection=true. Ticker
Considering the question of hasDirection and resolution. If the same lineType looks identical, regardless of hasDirection, then there is no point in setting hasDirection=true as the only effect will be to inhibit merging. To get the look of direction at high-res and no-direction when zoomed out, different lineTypes have to be used, with the style controlling this with [resolution-range] and [continue] If the lineType representation can be changed with hasDirection, again elements for the different levels should be produced, but can have {set mkgmap:has-direction=yes} for the high-res and =no for the low -res Ticker
Hi Ticker, I do see a need for the --allow-reverse-merge option, at least for those styles which rely on the old behaviour that lines are not reversed unless oneway=-1 is found. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Montag, 17. Mai 2021 12:49 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Line direction flag, merging etc Considering the question of hasDirection and resolution. If the same lineType looks identical, regardless of hasDirection, then there is no point in setting hasDirection=true as the only effect will be to inhibit merging. To get the look of direction at high-res and no-direction when zoomed out, different lineTypes have to be used, with the style controlling this with [resolution-range] and [continue] If the lineType representation can be changed with hasDirection, again elements for the different levels should be produced, but can have {set mkgmap:has-direction=yes} for the high-res and =no for the low -res Ticker _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd Sorry - in my mind, old versions also tried reversing if allowed. Ticker On Mon, 2021-05-17 at 11:13 +0000, Gerd Petermann wrote:
Hi Ticker,
I do see a need for the --allow-reverse-merge option, at least for those styles which rely on the old behaviour that lines are not reversed unless oneway=-1 is found.
Gerd
Hi Gerd I've rearranged the direction flag setting logic a bit, taking bits from ignore-oneway-for-line.patch It ignores oneway except for roads and allows direction to be set false even for routable oneways. I've tested routing when oneway=true, hasDirection=false on eTrex HCx and gpsMapEdit and it respected the oneway. I couldn't find any references to the {style}/overlays file in any documentation, but my reading of the code is that first substitution element will get the full MapRoad info, including the hasDirection flag and the MapLine copies will get also get the hasDirection flag. Ticker On Mon, 2021-05-17 at 11:29 +0100, Ticker Berkin wrote:
Hi Gerd and others
I'm starting a dedicated thread as previous posts are split between various svn commits.
Looking at the current trunk code and ignore-oneway-for-lines.patch, there are bits I don't understand or didn't expect.
This is what I hope for:
--line-types-with-direction lists the lineTypes for which the initial state of the hasDirection flag is considered true. It should be independent of --allow-reverse-merge (see later). The purpose of this is to reduce the need to edit styles and clarity as to which lineTypes are displayed with direction.
In the following, road means line with [road_class, road_speed], so includes ferries.
Style processing, having produced a line/road, sets hasDirection, in order of precedence: 1/ value of mkgmap:has-direction if tag exists 2/ true if oneway road 3/ true if in line-types-with-direction list
RoadMerger merges roads with same lineType, names, class, speed, oneway and hasDirection. It must not reverse oneway or hasDirection=true roads when doing this.
I don't think we need --allow-reverse-merge.
LineMergeFilter operates for level > 0. It merges any line/road with the same lineType, names, hasDirection. It must not reverse hasDirection=true.
Ticker
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Ticker, not sure what you want to achive? I agree that the evaluation of the --line-types-with-direction option should not depend on the --allow-reverse-merge option. Seems like an alternative to the solution in r4719 : https://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4719 but without the correction for the unit test. Reg. overlays: Yes, first element just gets a different type, the others are forced to be MapLine. First element might also be a non-routable line. The OpenFietsmap Styles use them, see https://github.com/ligfietser/mkgmap-style-sheets Do you see a need for the possibility to have oneway roads which don't have the direction flag set? In trunk it will not matter reg. merging, in the branch it might allow more merging in the overview map. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Montag, 17. Mai 2021 17:06 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Line direction flag, merging etc Hi Gerd I've rearranged the direction flag setting logic a bit, taking bits from ignore-oneway-for-line.patch It ignores oneway except for roads and allows direction to be set false even for routable oneways. I've tested routing when oneway=true, hasDirection=false on eTrex HCx and gpsMapEdit and it respected the oneway. I couldn't find any references to the {style}/overlays file in any documentation, but my reading of the code is that first substitution element will get the full MapRoad info, including the hasDirection flag and the MapLine copies will get also get the hasDirection flag. Ticker On Mon, 2021-05-17 at 11:29 +0100, Ticker Berkin wrote:
Hi Gerd and others
I'm starting a dedicated thread as previous posts are split between various svn commits.
Looking at the current trunk code and ignore-oneway-for-lines.patch, there are bits I don't understand or didn't expect.
This is what I hope for:
--line-types-with-direction lists the lineTypes for which the initial state of the hasDirection flag is considered true. It should be independent of --allow-reverse-merge (see later). The purpose of this is to reduce the need to edit styles and clarity as to which lineTypes are displayed with direction.
In the following, road means line with [road_class, road_speed], so includes ferries.
Style processing, having produced a line/road, sets hasDirection, in order of precedence: 1/ value of mkgmap:has-direction if tag exists 2/ true if oneway road 3/ true if in line-types-with-direction list
RoadMerger merges roads with same lineType, names, class, speed, oneway and hasDirection. It must not reverse oneway or hasDirection=true roads when doing this.
I don't think we need --allow-reverse-merge.
LineMergeFilter operates for level > 0. It merges any line/road with the same lineType, names, hasDirection. It must not reverse hasDirection=true.
Ticker
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd The ambition was to be able to turn off hasDirection if [oneway=yes/-1] (roads only) and/or --lines-types-with-direction would have it on. As I'd never noticed the compass direction on oneway roads, I thought I might as well turn it off. It also allowed me to test if this combination causes other problems. When LineMergeFilter does reversals it might be able to merge more. This might help some of Felix's problems - has-direction can be turned off for everything - towards the end of lines: <finalise> ... oneway=* {set mkgmap:has-direction=no} I presume r4719 was ignore-oneway-for-lines.patch and I took elements from this, but redid the oneway/road handling slightly so it was all in the same place. I've updated the patch to include the unit test change. Ticker On Mon, 2021-05-17 at 15:38 +0000, Gerd Petermann wrote:
Hi Ticker,
not sure what you want to achive? I agree that the evaluation of the --line-types-with-direction option should not depend on the --allow-reverse-merge option.
Seems like an alternative to the solution in r4719 : https://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4719 but without the correction for the unit test. Reg. overlays: Yes, first element just gets a different type, the others are forced to be MapLine. First element might also be a non-routable line. The OpenFietsmap Styles use them, see https://github.com/ligfietser/mkgmap-style-sheets
Do you see a need for the possibility to have oneway roads which don't have the direction flag set? In trunk it will not matter reg. merging, in the branch it might allow more merging in the overview map.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Montag, 17. Mai 2021 17:06 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Line direction flag, merging etc
Hi Gerd
I've rearranged the direction flag setting logic a bit, taking bits from ignore-oneway-for-line.patch
It ignores oneway except for roads and allows direction to be set false even for routable oneways. I've tested routing when oneway=true, hasDirection=false on eTrex HCx and gpsMapEdit and it respected the oneway.
I couldn't find any references to the {style}/overlays file in any documentation, but my reading of the code is that first substitution element will get the full MapRoad info, including the hasDirection flag and the MapLine copies will get also get the hasDirection flag.
Ticker
On Mon, 2021-05-17 at 11:29 +0100, Ticker Berkin wrote:
Hi Gerd and others
I'm starting a dedicated thread as previous posts are split between various svn commits.
Looking at the current trunk code and ignore-oneway-for -lines.patch, there are bits I don't understand or didn't expect.
This is what I hope for:
--line-types-with-direction lists the lineTypes for which the initial state of the hasDirection flag is considered true. It should be independent of --allow-reverse-merge (see later). The purpose of this is to reduce the need to edit styles and clarity as to which lineTypes are displayed with direction.
In the following, road means line with [road_class, road_speed], so includes ferries.
Style processing, having produced a line/road, sets hasDirection, in order of precedence: 1/ value of mkgmap:has-direction if tag exists 2/ true if oneway road 3/ true if in line-types-with-direction list
RoadMerger merges roads with same lineType, names, class, speed, oneway and hasDirection. It must not reverse oneway or hasDirection=true roads when doing this.
I don't think we need --allow-reverse-merge.
LineMergeFilter operates for level > 0. It merges any line/road with the same lineType, names, hasDirection. It must not reverse hasDirection=true.
Ticker
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Ticker, I just noticed that NET also contains a oneway flag, so I think it should be OK to have the direction flag in RGN be independant from oneway in NET /NOD. Not sure if I use your patch for trunk or merge it into the low-res-opt branch. I think only the branch cares about it because the LineMerger in trunk doesn't reverse-merge. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Montag, 17. Mai 2021 19:37 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Line direction flag, merging etc Hi Gerd The ambition was to be able to turn off hasDirection if [oneway=yes/-1] (roads only) and/or --lines-types-with-direction would have it on. As I'd never noticed the compass direction on oneway roads, I thought I might as well turn it off. It also allowed me to test if this combination causes other problems. When LineMergeFilter does reversals it might be able to merge more. This might help some of Felix's problems - has-direction can be turned off for everything - towards the end of lines: <finalise> ... oneway=* {set mkgmap:has-direction=no} I presume r4719 was ignore-oneway-for-lines.patch and I took elements from this, but redid the oneway/road handling slightly so it was all in the same place. I've updated the patch to include the unit test change. Ticker On Mon, 2021-05-17 at 15:38 +0000, Gerd Petermann wrote:
Hi Ticker,
not sure what you want to achive? I agree that the evaluation of the --line-types-with-direction option should not depend on the --allow-reverse-merge option.
Seems like an alternative to the solution in r4719 : https://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4719 but without the correction for the unit test. Reg. overlays: Yes, first element just gets a different type, the others are forced to be MapLine. First element might also be a non-routable line. The OpenFietsmap Styles use them, see https://github.com/ligfietser/mkgmap-style-sheets
Do you see a need for the possibility to have oneway roads which don't have the direction flag set? In trunk it will not matter reg. merging, in the branch it might allow more merging in the overview map.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Montag, 17. Mai 2021 17:06 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Line direction flag, merging etc
Hi Gerd
I've rearranged the direction flag setting logic a bit, taking bits from ignore-oneway-for-line.patch
It ignores oneway except for roads and allows direction to be set false even for routable oneways. I've tested routing when oneway=true, hasDirection=false on eTrex HCx and gpsMapEdit and it respected the oneway.
I couldn't find any references to the {style}/overlays file in any documentation, but my reading of the code is that first substitution element will get the full MapRoad info, including the hasDirection flag and the MapLine copies will get also get the hasDirection flag.
Ticker
On Mon, 2021-05-17 at 11:29 +0100, Ticker Berkin wrote:
Hi Gerd and others
I'm starting a dedicated thread as previous posts are split between various svn commits.
Looking at the current trunk code and ignore-oneway-for -lines.patch, there are bits I don't understand or didn't expect.
This is what I hope for:
--line-types-with-direction lists the lineTypes for which the initial state of the hasDirection flag is considered true. It should be independent of --allow-reverse-merge (see later). The purpose of this is to reduce the need to edit styles and clarity as to which lineTypes are displayed with direction.
In the following, road means line with [road_class, road_speed], so includes ferries.
Style processing, having produced a line/road, sets hasDirection, in order of precedence: 1/ value of mkgmap:has-direction if tag exists 2/ true if oneway road 3/ true if in line-types-with-direction list
RoadMerger merges roads with same lineType, names, class, speed, oneway and hasDirection. It must not reverse oneway or hasDirection=true roads when doing this.
I don't think we need --allow-reverse-merge.
LineMergeFilter operates for level > 0. It merges any line/road with the same lineType, names, hasDirection. It must not reverse hasDirection=true.
Ticker
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd ISTR there are 2 oneway flags in NET/NOD, along with the other access flags! I recommends patching trunk - it fixes --lines-types-with-direction and should clarify possible problems/solutions for Felix. Ticker On Tue, 2021-05-18 at 08:56 +0000, Gerd Petermann wrote:
Hi Ticker,
I just noticed that NET also contains a oneway flag, so I think it should be OK to have the direction flag in RGN be independant from oneway in NET /NOD.
Not sure if I use your patch for trunk or merge it into the low-res -opt branch. I think only the branch cares about it because the LineMerger in trunk doesn't reverse-merge.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Montag, 17. Mai 2021 19:37 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Line direction flag, merging etc
Hi Gerd
The ambition was to be able to turn off hasDirection if [oneway=yes/ -1] (roads only) and/or --lines-types-with-direction would have it on.
As I'd never noticed the compass direction on oneway roads, I thought I might as well turn it off. It also allowed me to test if this combination causes other problems. When LineMergeFilter does reversals it might be able to merge more.
This might help some of Felix's problems - has-direction can be turned off for everything - towards the end of lines:
<finalise> ... oneway=* {set mkgmap:has-direction=no}
I presume r4719 was ignore-oneway-for-lines.patch and I took elements from this, but redid the oneway/road handling slightly so it was all in the same place.
I've updated the patch to include the unit test change.
Ticker
On Mon, 2021-05-17 at 15:38 +0000, Gerd Petermann wrote:
Hi Ticker,
not sure what you want to achive? I agree that the evaluation of the --line-types-with-direction option should not depend on the --allow-reverse-merge option.
Seems like an alternative to the solution in r4719 : https://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=47 19 but without the correction for the unit test. Reg. overlays: Yes, first element just gets a different type, the others are forced to be MapLine. First element might also be a non-routable line. The OpenFietsmap Styles use them, see https://github.com/ligfietser/mkgmap-style-sheets
Do you see a need for the possibility to have oneway roads which don't have the direction flag set? In trunk it will not matter reg. merging, in the branch it might allow more merging in the overview map.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Montag, 17. Mai 2021 17:06 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Line direction flag, merging etc
Hi Gerd
I've rearranged the direction flag setting logic a bit, taking bits from ignore-oneway-for-line.patch
It ignores oneway except for roads and allows direction to be set false even for routable oneways. I've tested routing when oneway=true, hasDirection=false on eTrex HCx and gpsMapEdit and it respected the oneway.
I couldn't find any references to the {style}/overlays file in any documentation, but my reading of the code is that first substitution element will get the full MapRoad info, including the hasDirection flag and the MapLine copies will get also get the hasDirection flag.
Ticker
On Mon, 2021-05-17 at 11:29 +0100, Ticker Berkin wrote:
Hi Gerd and others
I'm starting a dedicated thread as previous posts are split between various svn commits.
Looking at the current trunk code and ignore-oneway-for -lines.patch, there are bits I don't understand or didn't expect.
This is what I hope for:
--line-types-with-direction lists the lineTypes for which the initial state of the hasDirection flag is considered true. It should be independent of --allow-reverse-merge (see later). The purpose of this is to reduce the need to edit styles and clarity as to which lineTypes are displayed with direction.
In the following, road means line with [road_class, road_speed], so includes ferries.
Style processing, having produced a line/road, sets hasDirection, in order of precedence: 1/ value of mkgmap:has-direction if tag exists 2/ true if oneway road 3/ true if in line-types-with-direction list
RoadMerger merges roads with same lineType, names, class, speed, oneway and hasDirection. It must not reverse oneway or hasDirection=true roads when doing this.
I don't think we need --allow-reverse-merge.
LineMergeFilter operates for level > 0. It merges any line/road with the same lineType, names, hasDirection. It must not reverse hasDirection=true.
Ticker
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Ticker, in the branch I found a solution which doesn't set the direction flag for overlay lines when the OSM way is a oneway and a road with overlay type is created. With your patch still ALL lines created from the overlay type have the direction flag set in that case. Tested this with the unchanged OFM style without any new options. Do you see something wrong in the current branch version r4723? I think it's clearer. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Dienstag, 18. Mai 2021 13:00 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Line direction flag, merging etc Hi Gerd ISTR there are 2 oneway flags in NET/NOD, along with the other access flags! I recommends patching trunk - it fixes --lines-types-with-direction and should clarify possible problems/solutions for Felix. Ticker On Tue, 2021-05-18 at 08:56 +0000, Gerd Petermann wrote:
Hi Ticker,
I just noticed that NET also contains a oneway flag, so I think it should be OK to have the direction flag in RGN be independant from oneway in NET /NOD.
Not sure if I use your patch for trunk or merge it into the low-res -opt branch. I think only the branch cares about it because the LineMerger in trunk doesn't reverse-merge.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Montag, 17. Mai 2021 19:37 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Line direction flag, merging etc
Hi Gerd
The ambition was to be able to turn off hasDirection if [oneway=yes/ -1] (roads only) and/or --lines-types-with-direction would have it on.
As I'd never noticed the compass direction on oneway roads, I thought I might as well turn it off. It also allowed me to test if this combination causes other problems. When LineMergeFilter does reversals it might be able to merge more.
This might help some of Felix's problems - has-direction can be turned off for everything - towards the end of lines:
<finalise> ... oneway=* {set mkgmap:has-direction=no}
I presume r4719 was ignore-oneway-for-lines.patch and I took elements from this, but redid the oneway/road handling slightly so it was all in the same place.
I've updated the patch to include the unit test change.
Ticker
On Mon, 2021-05-17 at 15:38 +0000, Gerd Petermann wrote:
Hi Ticker,
not sure what you want to achive? I agree that the evaluation of the --line-types-with-direction option should not depend on the --allow-reverse-merge option.
Seems like an alternative to the solution in r4719 : https://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=47 19 but without the correction for the unit test. Reg. overlays: Yes, first element just gets a different type, the others are forced to be MapLine. First element might also be a non-routable line. The OpenFietsmap Styles use them, see https://github.com/ligfietser/mkgmap-style-sheets
Do you see a need for the possibility to have oneway roads which don't have the direction flag set? In trunk it will not matter reg. merging, in the branch it might allow more merging in the overview map.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Montag, 17. Mai 2021 17:06 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Line direction flag, merging etc
Hi Gerd
I've rearranged the direction flag setting logic a bit, taking bits from ignore-oneway-for-line.patch
It ignores oneway except for roads and allows direction to be set false even for routable oneways. I've tested routing when oneway=true, hasDirection=false on eTrex HCx and gpsMapEdit and it respected the oneway.
I couldn't find any references to the {style}/overlays file in any documentation, but my reading of the code is that first substitution element will get the full MapRoad info, including the hasDirection flag and the MapLine copies will get also get the hasDirection flag.
Ticker
On Mon, 2021-05-17 at 11:29 +0100, Ticker Berkin wrote:
Hi Gerd and others
I'm starting a dedicated thread as previous posts are split between various svn commits.
Looking at the current trunk code and ignore-oneway-for -lines.patch, there are bits I don't understand or didn't expect.
This is what I hope for:
--line-types-with-direction lists the lineTypes for which the initial state of the hasDirection flag is considered true. It should be independent of --allow-reverse-merge (see later). The purpose of this is to reduce the need to edit styles and clarity as to which lineTypes are displayed with direction.
In the following, road means line with [road_class, road_speed], so includes ferries.
Style processing, having produced a line/road, sets hasDirection, in order of precedence: 1/ value of mkgmap:has-direction if tag exists 2/ true if oneway road 3/ true if in line-types-with-direction list
RoadMerger merges roads with same lineType, names, class, speed, oneway and hasDirection. It must not reverse oneway or hasDirection=true roads when doing this.
I don't think we need --allow-reverse-merge.
LineMergeFilter operates for level > 0. It merges any line/road with the same lineType, names, hasDirection. It must not reverse hasDirection=true.
Ticker
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Ticker, this would be my intended patch for trunk, it makes StyledConverter in branch and trunk identical. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com> Gesendet: Dienstag, 18. Mai 2021 14:35 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Line direction flag, merging etc Hi Ticker, in the branch I found a solution which doesn't set the direction flag for overlay lines when the OSM way is a oneway and a road with overlay type is created. With your patch still ALL lines created from the overlay type have the direction flag set in that case. Tested this with the unchanged OFM style without any new options. Do you see something wrong in the current branch version r4723? I think it's clearer. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Dienstag, 18. Mai 2021 13:00 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Line direction flag, merging etc Hi Gerd ISTR there are 2 oneway flags in NET/NOD, along with the other access flags! I recommends patching trunk - it fixes --lines-types-with-direction and should clarify possible problems/solutions for Felix. Ticker On Tue, 2021-05-18 at 08:56 +0000, Gerd Petermann wrote:
Hi Ticker,
I just noticed that NET also contains a oneway flag, so I think it should be OK to have the direction flag in RGN be independant from oneway in NET /NOD.
Not sure if I use your patch for trunk or merge it into the low-res -opt branch. I think only the branch cares about it because the LineMerger in trunk doesn't reverse-merge.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Montag, 17. Mai 2021 19:37 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Line direction flag, merging etc
Hi Gerd
The ambition was to be able to turn off hasDirection if [oneway=yes/ -1] (roads only) and/or --lines-types-with-direction would have it on.
As I'd never noticed the compass direction on oneway roads, I thought I might as well turn it off. It also allowed me to test if this combination causes other problems. When LineMergeFilter does reversals it might be able to merge more.
This might help some of Felix's problems - has-direction can be turned off for everything - towards the end of lines:
<finalise> ... oneway=* {set mkgmap:has-direction=no}
I presume r4719 was ignore-oneway-for-lines.patch and I took elements from this, but redid the oneway/road handling slightly so it was all in the same place.
I've updated the patch to include the unit test change.
Ticker
On Mon, 2021-05-17 at 15:38 +0000, Gerd Petermann wrote:
Hi Ticker,
not sure what you want to achive? I agree that the evaluation of the --line-types-with-direction option should not depend on the --allow-reverse-merge option.
Seems like an alternative to the solution in r4719 : https://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=47 19 but without the correction for the unit test. Reg. overlays: Yes, first element just gets a different type, the others are forced to be MapLine. First element might also be a non-routable line. The OpenFietsmap Styles use them, see https://github.com/ligfietser/mkgmap-style-sheets
Do you see a need for the possibility to have oneway roads which don't have the direction flag set? In trunk it will not matter reg. merging, in the branch it might allow more merging in the overview map.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Montag, 17. Mai 2021 17:06 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Line direction flag, merging etc
Hi Gerd
I've rearranged the direction flag setting logic a bit, taking bits from ignore-oneway-for-line.patch
It ignores oneway except for roads and allows direction to be set false even for routable oneways. I've tested routing when oneway=true, hasDirection=false on eTrex HCx and gpsMapEdit and it respected the oneway.
I couldn't find any references to the {style}/overlays file in any documentation, but my reading of the code is that first substitution element will get the full MapRoad info, including the hasDirection flag and the MapLine copies will get also get the hasDirection flag.
Ticker
On Mon, 2021-05-17 at 11:29 +0100, Ticker Berkin wrote:
Hi Gerd and others
I'm starting a dedicated thread as previous posts are split between various svn commits.
Looking at the current trunk code and ignore-oneway-for -lines.patch, there are bits I don't understand or didn't expect.
This is what I hope for:
--line-types-with-direction lists the lineTypes for which the initial state of the hasDirection flag is considered true. It should be independent of --allow-reverse-merge (see later). The purpose of this is to reduce the need to edit styles and clarity as to which lineTypes are displayed with direction.
In the following, road means line with [road_class, road_speed], so includes ferries.
Style processing, having produced a line/road, sets hasDirection, in order of precedence: 1/ value of mkgmap:has-direction if tag exists 2/ true if oneway road 3/ true if in line-types-with-direction list
RoadMerger merges roads with same lineType, names, class, speed, oneway and hasDirection. It must not reverse oneway or hasDirection=true roads when doing this.
I don't think we need --allow-reverse-merge.
LineMergeFilter operates for level > 0. It merges any line/road with the same lineType, names, hasDirection. It must not reverse hasDirection=true.
Ticker
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd The code in low-res-opt looks like ignore-oneway-for-lines.patch. The disadvantage of this, as I see it, is that has-direction can't be forced false for one-way roads. I think my version is clearer. Considering substitute lines from /overlays: I had intended that they all (first and duplicates) have the same has -direction value as the original. An alternative is that the first has the original has-direction value and the duplicate set has-direction solely from lineTypesWithDirection. I don't know which is better. Ticker On Tue, 2021-05-18 at 12:35 +0000, Gerd Petermann wrote:
Hi Ticker,
in the branch I found a solution which doesn't set the direction flag for overlay lines when the OSM way is a oneway and a road with overlay type is created. With your patch still ALL lines created from the overlay type have the direction flag set in that case. Tested this with the unchanged OFM style without any new options.
Do you see something wrong in the current branch version r4723? I think it's clearer.
Gerd
Hi Ticker, I don't see that oneway forces direction flag when the tag mkgmap:has-direction=no is set in the branch. Did you try it? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Dienstag, 18. Mai 2021 15:53 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Line direction flag, merging etc Hi Gerd The code in low-res-opt looks like ignore-oneway-for-lines.patch. The disadvantage of this, as I see it, is that has-direction can't be forced false for one-way roads. I think my version is clearer. Considering substitute lines from /overlays: I had intended that they all (first and duplicates) have the same has -direction value as the original. An alternative is that the first has the original has-direction value and the duplicate set has-direction solely from lineTypesWithDirection. I don't know which is better. Ticker On Tue, 2021-05-18 at 12:35 +0000, Gerd Petermann wrote:
Hi Ticker,
in the branch I found a solution which doesn't set the direction flag for overlay lines when the OSM way is a oneway and a road with overlay type is created. With your patch still ALL lines created from the overlay type have the direction flag set in that case. Tested this with the unchanged OFM style without any new options.
Do you see something wrong in the current branch version r4723? I think it's clearer.
Gerd
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Ticker, sorry, you are right. The branch forces the direction flag for oneway roads. Now I don't like both versions :( Have to think again about this.... Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com> Gesendet: Dienstag, 18. Mai 2021 16:01 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Line direction flag, merging etc Hi Ticker, I don't see that oneway forces direction flag when the tag mkgmap:has-direction=no is set in the branch. Did you try it? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Dienstag, 18. Mai 2021 15:53 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Line direction flag, merging etc Hi Gerd The code in low-res-opt looks like ignore-oneway-for-lines.patch. The disadvantage of this, as I see it, is that has-direction can't be forced false for one-way roads. I think my version is clearer. Considering substitute lines from /overlays: I had intended that they all (first and duplicates) have the same has -direction value as the original. An alternative is that the first has the original has-direction value and the duplicate set has-direction solely from lineTypesWithDirection. I don't know which is better. Ticker On Tue, 2021-05-18 at 12:35 +0000, Gerd Petermann wrote:
Hi Ticker,
in the branch I found a solution which doesn't set the direction flag for overlay lines when the OSM way is a oneway and a road with overlay type is created. With your patch still ALL lines created from the overlay type have the direction flag set in that case. Tested this with the unchanged OFM style without any new options.
Do you see something wrong in the current branch version r4723? I think it's clearer.
Gerd
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd I had tried it on some in-between version that I think had equivalent logic to the patch and it didn't get overridden. Doesn't the final (or only) lineAdder set it unconditionally for oneway roads? If I've misread it I'll build and test. Ticker On Tue, 2021-05-18 at 14:01 +0000, Gerd Petermann wrote:
Hi Ticker,
I don't see that oneway forces direction flag when the tag mkgmap:has -direction=no is set in the branch. Did you try it?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Dienstag, 18. Mai 2021 15:53 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Line direction flag, merging etc
Hi Gerd
The code in low-res-opt looks like ignore-oneway-for-lines.patch. The disadvantage of this, as I see it, is that has-direction can't be forced false for one-way roads.
I think my version is clearer.
Considering substitute lines from /overlays:
I had intended that they all (first and duplicates) have the same has -direction value as the original.
An alternative is that the first has the original has-direction value and the duplicate set has-direction solely from lineTypesWithDirection.
I don't know which is better.
Ticker
On Tue, 2021-05-18 at 12:35 +0000, Gerd Petermann wrote:
Hi Ticker,
in the branch I found a solution which doesn't set the direction flag for overlay lines when the OSM way is a oneway and a road with overlay type is created. With your patch still ALL lines created from the overlay type have the direction flag set in that case. Tested this with the unchanged OFM style without any new options.
Do you see something wrong in the current branch version r4723? I think it's clearer.
Gerd
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Ticker, this is getting even more ugly than I expected when I wrote that I don't want to support multiple ways to set the flag... Whatever we decide there will be lots of confusion :( With overlay types and --line-types-with-direction it is not clear if one has to list the type that is used in the style or one or more of those that appear on the "replacement" side. The code in the branch only looks at the type used in the style but assumes that the user wants only roads to have the dir-flag. There is no good reason for this. So, I think we need a flag in MapLine which stores the info that mkgmap:has-direction=no was used and we have to evaluate the list for each generated replacement type. The attached patch for the branch should do that. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Dienstag, 18. Mai 2021 16:13 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Line direction flag, merging etc Hi Gerd I had tried it on some in-between version that I think had equivalent logic to the patch and it didn't get overridden. Doesn't the final (or only) lineAdder set it unconditionally for oneway roads? If I've misread it I'll build and test. Ticker On Tue, 2021-05-18 at 14:01 +0000, Gerd Petermann wrote:
Hi Ticker,
I don't see that oneway forces direction flag when the tag mkgmap:has -direction=no is set in the branch. Did you try it?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Dienstag, 18. Mai 2021 15:53 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Line direction flag, merging etc
Hi Gerd
The code in low-res-opt looks like ignore-oneway-for-lines.patch. The disadvantage of this, as I see it, is that has-direction can't be forced false for one-way roads.
I think my version is clearer.
Considering substitute lines from /overlays:
I had intended that they all (first and duplicates) have the same has -direction value as the original.
An alternative is that the first has the original has-direction value and the duplicate set has-direction solely from lineTypesWithDirection.
I don't know which is better.
Ticker
On Tue, 2021-05-18 at 12:35 +0000, Gerd Petermann wrote:
Hi Ticker,
in the branch I found a solution which doesn't set the direction flag for overlay lines when the OSM way is a oneway and a road with overlay type is created. With your patch still ALL lines created from the overlay type have the direction flag set in that case. Tested this with the unchanged OFM style without any new options.
Do you see something wrong in the current branch version r4723? I think it's clearer.
Gerd
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd (& Minko?) overlay files are undocumented and probably unused except in OpenFietsMaps. It is a very restricted way of doing what is now done with [... continue {with_actions}] or, even simpler, something like: tourism=camp_site [0x2b03 resolution 24] [0x2b05 resolution 24] [continue] allows for different resolution ranges, routing attributes etc and now, with {set mkgmap:has-direction= }, explicit control of this for each generated line (although see following). Thinking about my previous suggestion of looking up each overlay copy linetype to set has-direction, this could be very dangerous in allowing different merging/filtering behaviour/filtering between all the copies, so the lines might not overlay each other. I don't think overlays should be allowed to add any ugliness. The lineType as given in the rule should be the one that is checked against --line-types-with-direction. The replacement and all copies should have the same value for has-direction. My implementation preserves the existing behaviour. I think it is quite tidy and it doesn't need another flag in MapLine. Ticker On Tue, 2021-05-18 at 15:03 +0000, Gerd Petermann wrote:
Hi Ticker,
this is getting even more ugly than I expected when I wrote that I don't want to support multiple ways to set the flag... Whatever we decide there will be lots of confusion :(
With overlay types and --line-types-with-direction it is not clear if one has to list the type that is used in the style or one or more of those that appear on the "replacement" side. The code in the branch only looks at the type used in the style but assumes that the user wants only roads to have the dir-flag. There is no good reason for this.
So, I think we need a flag in MapLine which stores the info that mkgmap:has-direction=no was used and we have to evaluate the list for each generated replacement type. The attached patch for the branch should do that.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Dienstag, 18. Mai 2021 16:13 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Line direction flag, merging etc
Hi Gerd
I had tried it on some in-between version that I think had equivalent logic to the patch and it didn't get overridden.
Doesn't the final (or only) lineAdder set it unconditionally for oneway roads? If I've misread it I'll build and test.
Ticker
On Tue, 2021-05-18 at 14:01 +0000, Gerd Petermann wrote:
Hi Ticker,
I don't see that oneway forces direction flag when the tag mkgmap:has -direction=no is set in the branch. Did you try it?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Dienstag, 18. Mai 2021 15:53 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Line direction flag, merging etc
Hi Gerd
The code in low-res-opt looks like ignore-oneway-for-lines.patch. The disadvantage of this, as I see it, is that has-direction can't be forced false for one-way roads.
I think my version is clearer.
Considering substitute lines from /overlays:
I had intended that they all (first and duplicates) have the same has -direction value as the original.
An alternative is that the first has the original has-direction value and the duplicate set has-direction solely from lineTypesWithDirection.
I don't know which is better.
Ticker
On Tue, 2021-05-18 at 12:35 +0000, Gerd Petermann wrote:
Hi Ticker,
in the branch I found a solution which doesn't set the direction flag for overlay lines when the OSM way is a oneway and a road with overlay type is created. With your patch still ALL lines created from the overlay type have the direction flag set in that case. Tested this with the unchanged OFM style without any new options.
Do you see something wrong in the current branch version r4723? I think it's clearer.
Gerd
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Ticker, which "existing behaviour" do you mean? That before r4703? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Dienstag, 18. Mai 2021 17:51 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Line direction flag, merging etc Hi Gerd (& Minko?) overlay files are undocumented and probably unused except in OpenFietsMaps. It is a very restricted way of doing what is now done with [... continue {with_actions}] or, even simpler, something like: tourism=camp_site [0x2b03 resolution 24] [0x2b05 resolution 24] [continue] allows for different resolution ranges, routing attributes etc and now, with {set mkgmap:has-direction= }, explicit control of this for each generated line (although see following). Thinking about my previous suggestion of looking up each overlay copy linetype to set has-direction, this could be very dangerous in allowing different merging/filtering behaviour/filtering between all the copies, so the lines might not overlay each other. I don't think overlays should be allowed to add any ugliness. The lineType as given in the rule should be the one that is checked against --line-types-with-direction. The replacement and all copies should have the same value for has-direction. My implementation preserves the existing behaviour. I think it is quite tidy and it doesn't need another flag in MapLine. Ticker On Tue, 2021-05-18 at 15:03 +0000, Gerd Petermann wrote:
Hi Ticker,
this is getting even more ugly than I expected when I wrote that I don't want to support multiple ways to set the flag... Whatever we decide there will be lots of confusion :(
With overlay types and --line-types-with-direction it is not clear if one has to list the type that is used in the style or one or more of those that appear on the "replacement" side. The code in the branch only looks at the type used in the style but assumes that the user wants only roads to have the dir-flag. There is no good reason for this.
So, I think we need a flag in MapLine which stores the info that mkgmap:has-direction=no was used and we have to evaluate the list for each generated replacement type. The attached patch for the branch should do that.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Dienstag, 18. Mai 2021 16:13 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Line direction flag, merging etc
Hi Gerd
I had tried it on some in-between version that I think had equivalent logic to the patch and it didn't get overridden.
Doesn't the final (or only) lineAdder set it unconditionally for oneway roads? If I've misread it I'll build and test.
Ticker
On Tue, 2021-05-18 at 14:01 +0000, Gerd Petermann wrote:
Hi Ticker,
I don't see that oneway forces direction flag when the tag mkgmap:has -direction=no is set in the branch. Did you try it?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Dienstag, 18. Mai 2021 15:53 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Line direction flag, merging etc
Hi Gerd
The code in low-res-opt looks like ignore-oneway-for-lines.patch. The disadvantage of this, as I see it, is that has-direction can't be forced false for one-way roads.
I think my version is clearer.
Considering substitute lines from /overlays:
I had intended that they all (first and duplicates) have the same has -direction value as the original.
An alternative is that the first has the original has-direction value and the duplicate set has-direction solely from lineTypesWithDirection.
I don't know which is better.
Ticker
On Tue, 2021-05-18 at 12:35 +0000, Gerd Petermann wrote:
Hi Ticker,
in the branch I found a solution which doesn't set the direction flag for overlay lines when the OSM way is a oneway and a road with overlay type is created. With your patch still ALL lines created from the overlay type have the direction flag set in that case. Tested this with the unchanged OFM style without any new options.
Do you see something wrong in the current branch version r4723? I think it's clearer.
Gerd
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd Yes Ticker On Tue, 2021-05-18 at 15:56 +0000, Gerd Petermann wrote:
Hi Ticker,
which "existing behaviour" do you mean? That before r4703?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Dienstag, 18. Mai 2021 17:51 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Line direction flag, merging etc
Hi Gerd (& Minko?)
overlay files are undocumented and probably unused except in OpenFietsMaps. It is a very restricted way of doing what is now done with [... continue {with_actions}] or, even simpler, something like:
tourism=camp_site [0x2b03 resolution 24] [0x2b05 resolution 24]
[continue] allows for different resolution ranges, routing attributes etc and now, with {set mkgmap:has-direction= }, explicit control of this for each generated line (although see following).
Thinking about my previous suggestion of looking up each overlay copy linetype to set has-direction, this could be very dangerous in allowing different merging/filtering behaviour/filtering between all the copies, so the lines might not overlay each other.
I don't think overlays should be allowed to add any ugliness. The lineType as given in the rule should be the one that is checked against --line-types-with-direction. The replacement and all copies should have the same value for has-direction.
My implementation preserves the existing behaviour. I think it is quite tidy and it doesn't need another flag in MapLine.
Ticker
Hi Ticker, I didn't notice that overlays are not documented. They appear in doc\styles\files.txt but it seems this part is commented out, so the text doesn't make it into the pdf. The major difference with overlays compared to [continue] is the data flow. The lines from overlays where possibly merged/reverse-merged by RoadMerger, they are even processed by the housenumber code. In that way they are better than lines from [continue] : They also have the added number nodes and there are fewer objects while StyledConverter is active, so theoretically they should perform better. Anyhow, the concept is old and maybe we should even deprecate it. I've committed your patch with small changes reg. oneway evaluation. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Dienstag, 18. Mai 2021 17:51 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Line direction flag, merging etc Hi Gerd (& Minko?) overlay files are undocumented and probably unused except in OpenFietsMaps. It is a very restricted way of doing what is now done with [... continue {with_actions}] or, even simpler, something like: tourism=camp_site [0x2b03 resolution 24] [0x2b05 resolution 24] [continue] allows for different resolution ranges, routing attributes etc and now, with {set mkgmap:has-direction= }, explicit control of this for each generated line (although see following). Thinking about my previous suggestion of looking up each overlay copy linetype to set has-direction, this could be very dangerous in allowing different merging/filtering behaviour/filtering between all the copies, so the lines might not overlay each other. I don't think overlays should be allowed to add any ugliness. The lineType as given in the rule should be the one that is checked against --line-types-with-direction. The replacement and all copies should have the same value for has-direction. My implementation preserves the existing behaviour. I think it is quite tidy and it doesn't need another flag in MapLine. Ticker On Tue, 2021-05-18 at 15:03 +0000, Gerd Petermann wrote:
Hi Ticker,
this is getting even more ugly than I expected when I wrote that I don't want to support multiple ways to set the flag... Whatever we decide there will be lots of confusion :(
With overlay types and --line-types-with-direction it is not clear if one has to list the type that is used in the style or one or more of those that appear on the "replacement" side. The code in the branch only looks at the type used in the style but assumes that the user wants only roads to have the dir-flag. There is no good reason for this.
So, I think we need a flag in MapLine which stores the info that mkgmap:has-direction=no was used and we have to evaluate the list for each generated replacement type. The attached patch for the branch should do that.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Dienstag, 18. Mai 2021 16:13 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Line direction flag, merging etc
Hi Gerd
I had tried it on some in-between version that I think had equivalent logic to the patch and it didn't get overridden.
Doesn't the final (or only) lineAdder set it unconditionally for oneway roads? If I've misread it I'll build and test.
Ticker
On Tue, 2021-05-18 at 14:01 +0000, Gerd Petermann wrote:
Hi Ticker,
I don't see that oneway forces direction flag when the tag mkgmap:has -direction=no is set in the branch. Did you try it?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Dienstag, 18. Mai 2021 15:53 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Line direction flag, merging etc
Hi Gerd
The code in low-res-opt looks like ignore-oneway-for-lines.patch. The disadvantage of this, as I see it, is that has-direction can't be forced false for one-way roads.
I think my version is clearer.
Considering substitute lines from /overlays:
I had intended that they all (first and duplicates) have the same has -direction value as the original.
An alternative is that the first has the original has-direction value and the duplicate set has-direction solely from lineTypesWithDirection.
I don't know which is better.
Ticker
On Tue, 2021-05-18 at 12:35 +0000, Gerd Petermann wrote:
Hi Ticker,
in the branch I found a solution which doesn't set the direction flag for overlay lines when the OSM way is a oneway and a road with overlay type is created. With your patch still ALL lines created from the overlay type have the direction flag set in that case. Tested this with the unchanged OFM style without any new options.
Do you see something wrong in the current branch version r4723? I think it's clearer.
Gerd
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd and anyone who uses the style/overlays file It seems that /overlays were on their way to being depreciated. Should this be made formal unless objections are received from style-writers who can't easily convert to [continue]? Is there scope for using more of the special handling of overlays when multiple lines are generated from a single OSM way? I notice one instance where it does this. Ticker On Wed, 2021-05-19 at 05:37 +0000, Gerd Petermann wrote:
Hi Ticker,
I didn't notice that overlays are not documented. They appear in doc\styles\files.txt but it seems this part is commented out, so the text doesn't make it into the pdf.
The major difference with overlays compared to [continue] is the data flow. The lines from overlays where possibly merged/reverse-merged by RoadMerger, they are even processed by the housenumber code. In that way they are better than lines from [continue] : They also have the added number nodes and there are fewer objects while StyledConverter is active, so theoretically they should perform better.
Anyhow, the concept is old and maybe we should even deprecate it.
I've committed your patch with small changes reg. oneway evaluation.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Dienstag, 18. Mai 2021 17:51 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Line direction flag, merging etc
Hi Gerd (& Minko?)
overlay files are undocumented and probably unused except in OpenFietsMaps. It is a very restricted way of doing what is now done with [... continue {with_actions}] or, even simpler, something like:
tourism=camp_site [0x2b03 resolution 24] [0x2b05 resolution 24]
[continue] allows for different resolution ranges, routing attributes etc and now, with {set mkgmap:has-direction= }, explicit control of this for each generated line (although see following).
Thinking about my previous suggestion of looking up each overlay copy linetype to set has-direction, this could be very dangerous in allowing different merging/filtering behaviour/filtering between all the copies, so the lines might not overlay each other.
I don't think overlays should be allowed to add any ugliness. The lineType as given in the rule should be the one that is checked against --line-types-with-direction. The replacement and all copies should have the same value for has-direction.
My implementation preserves the existing behaviour. I think it is quite tidy and it doesn't need another flag in MapLine.
Ticker
On Tue, 2021-05-18 at 15:03 +0000, Gerd Petermann wrote:
Hi Ticker,
this is getting even more ugly than I expected when I wrote that I don't want to support multiple ways to set the flag... Whatever we decide there will be lots of confusion :(
With overlay types and --line-types-with-direction it is not clear if one has to list the type that is used in the style or one or more of those that appear on the "replacement" side. The code in the branch only looks at the type used in the style but assumes that the user wants only roads to have the dir-flag. There is no good reason for this.
So, I think we need a flag in MapLine which stores the info that mkgmap:has-direction=no was used and we have to evaluate the list for each generated replacement type. The attached patch for the branch should do that.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Dienstag, 18. Mai 2021 16:13 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Line direction flag, merging etc
Hi Gerd
I had tried it on some in-between version that I think had equivalent logic to the patch and it didn't get overridden.
Doesn't the final (or only) lineAdder set it unconditionally for oneway roads? If I've misread it I'll build and test.
Ticker
On Tue, 2021-05-18 at 14:01 +0000, Gerd Petermann wrote:
Hi Ticker,
I don't see that oneway forces direction flag when the tag mkgmap:has -direction=no is set in the branch. Did you try it?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Dienstag, 18. Mai 2021 15:53 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Line direction flag, merging etc
Hi Gerd
The code in low-res-opt looks like ignore-oneway-for-lines.patch. The disadvantage of this, as I see it, is that has-direction can't be forced false for one-way roads.
I think my version is clearer.
Considering substitute lines from /overlays:
I had intended that they all (first and duplicates) have the same has -direction value as the original.
An alternative is that the first has the original has-direction value and the duplicate set has-direction solely from lineTypesWithDirection.
I don't know which is better.
Ticker
On Tue, 2021-05-18 at 12:35 +0000, Gerd Petermann wrote:
Hi Ticker,
in the branch I found a solution which doesn't set the direction flag for overlay lines when the OSM way is a oneway and a road with overlay type is created. With your patch still ALL lines created from the overlay type have the direction flag set in that case. Tested this with the unchanged OFM style without any new options.
Do you see something wrong in the current branch version r4723? I think it's clearer.
Gerd
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
participants (2)
-
Gerd Petermann -
Ticker Berkin