Hi Gerd oneway tag no longer influences the direction flag of non-routable lines. Note that oneway=-1 still means line is reversed and oneway=yes is set. I think this is only needed if the linetype is listed under --line-types-with-direction If not listed here nor routable oneway=-1 is as irrelevant as oneway=yes I do not understand why we would have different handling of onway=yes and oneway=-1 Reversing the road should not be needed because it does not matter for the layout, nor for the routing. -- Felix Hartman - Openmtbmap.org & VeloMap.org
Hi Felix, "this is only needed ..." what exactly refers "this" to? oneway=-1 requires a reversing of roads because the IMG format doesn't allow to store the information that it is a reversed oneway. The current code checks the oneway tag first. It does this since r2944, see https://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=2944 It's probably not needed for lines without a direction and it might safe a few cpu cycles to avoid that reversing. Anyhow, with --allow-reverse-merge the order of points in lines without direction might be reversed again. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver@gmail.com> Gesendet: Montag, 17. Mai 2021 04:52 An: Development list for mkgmap Betreff: [mkgmap-dev] 4179 Hi Gerd oneway tag no longer influences the direction flag of non-routable lines. Note that oneway=-1 still means line is reversed and oneway=yes is set. I think this is only needed if the linetype is listed under --line-types-with-direction If not listed here nor routable oneway=-1 is as irrelevant as oneway=yes I do not understand why we would have different handling of onway=yes and oneway=-1 Reversing the road should not be needed because it does not matter for the layout, nor for the routing. -- Felix Hartman - Openmtbmap.org & VeloMap.org
This in referring the the commit message. I think mkgmap in that case simply should not reverse the lines at all. I did not know that --allow-reverse-merge will be able to reverse them again. But yes I think mkgmap could skip reversing such lines. Meaning only look at oneway status for lines that are on the line--types-with-direction list or routable. Doing that in style is rather complicated, and likely using quite a lot of CPU cycles too. On Mon, 17 May 2021 at 13:43, Gerd Petermann < gpetermann_muenchen@hotmail.com> wrote:
Hi Felix,
"this is only needed ..." what exactly refers "this" to?
oneway=-1 requires a reversing of roads because the IMG format doesn't allow to store the information that it is a reversed oneway.
The current code checks the oneway tag first. It does this since r2944, see https://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=2944 It's probably not needed for lines without a direction and it might safe a few cpu cycles to avoid that reversing. Anyhow, with --allow-reverse-merge the order of points in lines without direction might be reversed again.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver@gmail.com> Gesendet: Montag, 17. Mai 2021 04:52 An: Development list for mkgmap Betreff: [mkgmap-dev] 4179
Hi Gerd
oneway tag no longer influences the direction flag of non-routable lines. Note that oneway=-1 still means line is reversed and oneway=yes is set.
I think this is only needed if the linetype is listed under --line-types-with-direction If not listed here nor routable oneway=-1 is as irrelevant as oneway=yes
I do not understand why we would have different handling of onway=yes and oneway=-1 Reversing the road should not be needed because it does not matter for the layout, nor for the routing. -- Felix Hartman - Openmtbmap.org & VeloMap.org
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org
Hi Felix, I don't understand what the problem is. I think we agreed that the oneway tag should not influence the direction flag for non-routable lines. Only the mkgmap:has-direction tag or the --types-with-direction list should be evaluated. Do we still agree about that? Is about the rules for oneway=-1 reg. left/right? Those lines clearly have a direction, don't they? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver@gmail.com> Gesendet: Montag, 17. Mai 2021 08:09 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] 4179 This in referring the the commit message. I think mkgmap in that case simply should not reverse the lines at all. I did not know that --allow-reverse-merge will be able to reverse them again. But yes I think mkgmap could skip reversing such lines. Meaning only look at oneway status for lines that are on the line--types-with-direction list or routable. Doing that in style is rather complicated, and likely using quite a lot of CPU cycles too. On Mon, 17 May 2021 at 13:43, Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>> wrote: Hi Felix, "this is only needed ..." what exactly refers "this" to? oneway=-1 requires a reversing of roads because the IMG format doesn't allow to store the information that it is a reversed oneway. The current code checks the oneway tag first. It does this since r2944, see https://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=2944 It's probably not needed for lines without a direction and it might safe a few cpu cycles to avoid that reversing. Anyhow, with --allow-reverse-merge the order of points in lines without direction might be reversed again. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag von Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com>> Gesendet: Montag, 17. Mai 2021 04:52 An: Development list for mkgmap Betreff: [mkgmap-dev] 4179 Hi Gerd oneway tag no longer influences the direction flag of non-routable lines. Note that oneway=-1 still means line is reversed and oneway=yes is set. I think this is only needed if the linetype is listed under --line-types-with-direction If not listed here nor routable oneway=-1 is as irrelevant as oneway=yes I do not understand why we would have different handling of onway=yes and oneway=-1 Reversing the road should not be needed because it does not matter for the layout, nor for the routing. -- Felix Hartman - Openmtbmap.org & VeloMap.org _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Felix Hartman - Openmtbmap.org & VeloMap.org
Well I think we already list all lines which cannot be reversed in the line--types-with-direction, in addition to that roads with oneway cannot be reversed at level 0 (but at all other levels - in my opinion). lines that are not routable but have a oneway attribute, and are not listed - do not need to be evaluated for oneway at all IMHO. So also not needed to reverse oneway=-1 for them. But yes it likely does not matter much if afterwards they are reversed anyhow... For line--types-with-direction it would be best to give a resolution limit for each type, so if resolution is lower than associated lines can be reversed. If no resolution given then assume they can be reversed. That is still the trickiest one. E.g. line--types-with-direction=0x0a(22), 0x10100(24) - 24 meaning any associated way can be reversed from resolution 23 onwards in order to be merged. If no resolution is given assume they can be reversed at any resolution. On Mon, 17 May 2021 at 15:46, Gerd Petermann < gpetermann_muenchen@hotmail.com> wrote:
Hi Felix,
I don't understand what the problem is. I think we agreed that the oneway tag should not influence the direction flag for non-routable lines. Only the mkgmap:has-direction tag or the --types-with-direction list should be evaluated. Do we still agree about that?
Is about the rules for oneway=-1 reg. left/right? Those lines clearly have a direction, don't they?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver@gmail.com> Gesendet: Montag, 17. Mai 2021 08:09 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] 4179
This in referring the the commit message. I think mkgmap in that case simply should not reverse the lines at all. I did not know that --allow-reverse-merge will be able to reverse them again. But yes I think mkgmap could skip reversing such lines. Meaning only look at oneway status for lines that are on the line--types-with-direction list or routable. Doing that in style is rather complicated, and likely using quite a lot of CPU cycles too.
On Mon, 17 May 2021 at 13:43, Gerd Petermann < gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>> wrote: Hi Felix,
"this is only needed ..." what exactly refers "this" to?
oneway=-1 requires a reversing of roads because the IMG format doesn't allow to store the information that it is a reversed oneway.
The current code checks the oneway tag first. It does this since r2944, see https://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=2944 It's probably not needed for lines without a direction and it might safe a few cpu cycles to avoid that reversing. Anyhow, with --allow-reverse-merge the order of points in lines without direction might be reversed again.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag von Felix Hartmann < extremecarver@gmail.com<mailto:extremecarver@gmail.com>> Gesendet: Montag, 17. Mai 2021 04:52 An: Development list for mkgmap Betreff: [mkgmap-dev] 4179
Hi Gerd
oneway tag no longer influences the direction flag of non-routable lines. Note that oneway=-1 still means line is reversed and oneway=yes is set.
I think this is only needed if the linetype is listed under --line-types-with-direction If not listed here nor routable oneway=-1 is as irrelevant as oneway=yes
I do not understand why we would have different handling of onway=yes and oneway=-1 Reversing the road should not be needed because it does not matter for the layout, nor for the routing. -- Felix Hartman - Openmtbmap.org & VeloMap.org
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org
Hi Felix, why don't make it simple? Routable roads with oneway=-1 have to be reversed. Non-routable lines with oneway=-1 have to be reversed if has-direction is present. If has-direction is present, road is not reversible for merging at all layers. I don't understand your suggestion for non-reversible road limited to some resolutions. I can't imagine what is the use of it, but maybe you have some example. Anyway, I see it like that: - there are rare cases for it if any, - even if the line remains non-reversible at all levels, there is not much difference for a whole map, - if you really need that kind of solution, you can create 2 different objects for different layers. -- Best regards, Andrzej
The case was that many of those roads are created by continue. If the main road is merged but the direction dependant road not - then at lower resolutions the DP filter will create a mess. This is only relevant for 21 or lower I feel. 22-24 it's all right. Most overlays will be right in that resolution. Even though I have loads of those overlays, luckily those that are direction dependent are only in resolution 24 and 23. Some people may have overlays at lower resolution however. All lines created with continue at resolution lower 23 are problematic concerning this matter. And because I have lots of overview - E.g. oneway arrows, oneway streets are loads, there is quite a difference in map size regarding oneway roads being merged from resolution 23 onwards or not. I think it makes up for around 1.5% map size. The 1.5% is not the problem, but that primary roads, highways and so on are usually mapped with two lines, and each one has oneway attached. Then quite a bit of the optimization is lost if those roads are not merged. As for me highways are not routable, I just delete the oneway in style before processing... Could skip that if non routable lines do not care for oneway. Same for railways (and railways as well are displayed to quite a low resolution. Fixed by deleting oneway for railway=* & highway!=* On Mon, 17 May 2021 at 18:39, Andrzej Popowski <popej@poczta.onet.pl> wrote:
Hi Felix,
why don't make it simple?
Routable roads with oneway=-1 have to be reversed. Non-routable lines with oneway=-1 have to be reversed if has-direction is present. If has-direction is present, road is not reversible for merging at all layers.
I don't understand your suggestion for non-reversible road limited to some resolutions. I can't imagine what is the use of it, but maybe you have some example. Anyway, I see it like that: - there are rare cases for it if any, - even if the line remains non-reversible at all levels, there is not much difference for a whole map, - if you really need that kind of solution, you can create 2 different objects for different layers.
-- Best regards, Andrzej _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org
Hi Felix!
If the main road is merged but the direction dependant road not - then at lower resolutions the DP filter will create a mess
But direction dependent road are merged, aren't they?
And because I have lots of overview - E.g. oneway arrows, oneway streets are loads, there is quite a difference in map size regarding oneway roads being merged from resolution 23 onwards or not.
As I understand, dropping has-direction attribute will allow to merge roads with reversing (when option allow-reverse-merge is active). This means that you can get arrows in wrong direction. Is this acceptable? -- Best regards, Andrzej
I think Gerd said that now those underlying roads/lines are merged for level 1 and higher. He said to merge them until someone complains. Merging as in reversing their direction so longer segments can be merged. All roads that can be merged without changing direction are merged anyhow. Allow-reverse-merge does not reverse lines that have an direction tag set, or are listed in the option to exclude them (which sets direction for them). Without allow reverse merge no roads are reversed at all. With it any road that has no direction tag or oneway tag set will be reversed if it can improve the merge length. On Tue, 18 May 2021 at 00:27, Andrzej Popowski <popej@poczta.onet.pl> wrote:
Hi Felix!
If the main road is merged but the direction dependant road not - then at lower resolutions the DP filter will create a mess
But direction dependent road are merged, aren't they?
And because I have lots of overview - E.g. oneway arrows, oneway streets are loads, there is quite a difference in map size regarding oneway roads being merged from resolution 23 onwards or not.
As I understand, dropping has-direction attribute will allow to merge roads with reversing (when option allow-reverse-merge is active). This means that you can get arrows in wrong direction. Is this acceptable?
-- Best regards, Andrzej _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org
Hi Felix, no idea what you mean with "underlying roads/lines are merged for level 1 and higher". The RoadMerger merges roads which have the same attributes. Min- and max-resolution are also attributes which must match. The LineMerger still doesn't merge roads. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver@gmail.com> Gesendet: Montag, 17. Mai 2021 18:33 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] 4179 I think Gerd said that now those underlying roads/lines are merged for level 1 and higher. He said to merge them until someone complains. Merging as in reversing their direction so longer segments can be merged. All roads that can be merged without changing direction are merged anyhow. Allow-reverse-merge does not reverse lines that have an direction tag set, or are listed in the option to exclude them (which sets direction for them). Without allow reverse merge no roads are reversed at all. With it any road that has no direction tag or oneway tag set will be reversed if it can improve the merge length. On Tue, 18 May 2021 at 00:27, Andrzej Popowski <popej@poczta.onet.pl<mailto:popej@poczta.onet.pl>> wrote: Hi Felix!
If the main road is merged but the direction dependant road not - then at lower resolutions the DP filter will create a mess
But direction dependent road are merged, aren't they?
And because I have lots of overview - E.g. oneway arrows, oneway streets are loads, there is quite a difference in map size regarding oneway roads being merged from resolution 23 onwards or not.
As I understand, dropping has-direction attribute will allow to merge roads with reversing (when option allow-reverse-merge is active). This means that you can get arrows in wrong direction. Is this acceptable? -- Best regards, Andrzej _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Felix Hartman - Openmtbmap.org & VeloMap.org
Hi Felix, then what about proposed:
For line--types-with-direction it would be best to give a resolution limit for each type, so if resolution is lower than associated lines can be reversed.
Does it means, that you accept wrong direction at lower resolution? -- Best regards, Andrzej
I meant if there is a line created with continue - and that line is on the --line-types-with-direction list, the other copies of that line Or roads should be merged too. And I think roads should be reversed and merged as much as possible to - also at resolution 24 if not oneway-1 or on the --line-types-with-direction with list. However some people may feel that is a single copy of that line is on the --line-types-with-direction list, then none of those copies should be merged at level 0, but maybe on other levels or none at no levels at all. And I also use different linetypes for roads - so highways get thinner when zooming out. I think this makes a lot of sense for secondary to highway. Not soo much for others. That is anyhow why I feel roads only exist at level 0, from level 1 onwards there are only lines, not roads. Now for one object in OSM I sometimes create up to 10 copies - 5 due to different level, 4 for additional features and 1 invisible line that is actually responsible for routing. Having the road invisible overcomes the problem that there are few routable line types - so only solution is to make many roads invisible and only map the very common ones to a visible line type. So there is a pretty big implication on the total size if due to one of those 10 copies having the direction set or oneway set, all other 9 cannot be reversed to be merged, or not be merged at all. Also the name is not identical. E.g. I will create one line for a mtb route, another line for a hiking route. Maybe even several lines so you can see all route names. Also several copies (up to 4, previously even more but in new generation devices that lead to crashes) are routable. Also helps in merging - if you have one road for a relation that always has the same name, only at intersections with other roads this cannot be merged. While if there are maybe changes in the name tag, or other subtleties less can be merged. I really feel merge as much as possible and consider everything a line from level 1 onwards. On Tue, 18 May 2021 at 01:02, Andrzej Popowski <popej@poczta.onet.pl> wrote:
Hi Felix,
then what about proposed:
For line--types-with-direction it would be best to give a resolution limit for each type, so if resolution is lower than associated lines can be reversed.
Does it means, that you accept wrong direction at lower resolution?
-- Best regards, Andrzej _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org
Oh yeah - what may not happen is the following hypothetical example 1. route=mtb (set line) (can be merged and reversed) 2. highway=x (set road - is not reversed merged - maybe because of oneway tag) 3. route=hiking (set line - however because the 2. highway was not reversed, while the 1 route was reversed - this is now using a different direction than 1). 1. and 3. while being possible to be reversed - have to be reversed identical. (because in my style mtb routes are on the right side, hiking routes on the left side). 2. can be reversed because it is in the center. I do not are if 1. and 3 are exchanged. Meaning it is fine if they are left or right, but they are not allowed to be both left or both right. So they can be reversed, but if 1. is reversed, 3 had to be reversed to. I have quite a few such cases in my style and as long as the reversing is consistent, and not dependent on the order in the style, this is fine. e.g this could create a problem? 1. route=mtb (can be reversed) 2. highway=oneway (downhill only at high priority) [set oneway=1} continue (sometimes with, sometimes without actions) - cannot be reversed because of oneway. 3. {delette oneway if for 2. continue with actions was used I use intermediary keys to restore an actual oneway should there have been one.} 3. route=hiking (can be reversed - but if it is reversed also route=mtb has to be reversed). On Tue, 18 May 2021 at 01:28, Felix Hartmann <extremecarver@gmail.com> wrote:
I meant if there is a line created with continue - and that line is on the --line-types-with-direction list, the other copies of that line Or roads should be merged too. And I think roads should be reversed and merged as much as possible to - also at resolution 24 if not oneway-1 or on the --line-types-with-direction with list. However some people may feel that is a single copy of that line is on the --line-types-with-direction list, then none of those copies should be merged at level 0, but maybe on other levels or none at no levels at all. And I also use different linetypes for roads - so highways get thinner when zooming out. I think this makes a lot of sense for secondary to highway. Not soo much for others. That is anyhow why I feel roads only exist at level 0, from level 1 onwards there are only lines, not roads.
Now for one object in OSM I sometimes create up to 10 copies - 5 due to different level, 4 for additional features and 1 invisible line that is actually responsible for routing. Having the road invisible overcomes the problem that there are few routable line types - so only solution is to make many roads invisible and only map the very common ones to a visible line type. So there is a pretty big implication on the total size if due to one of those 10 copies having the direction set or oneway set, all other 9 cannot be reversed to be merged, or not be merged at all. Also the name is not identical. E.g. I will create one line for a mtb route, another line for a hiking route. Maybe even several lines so you can see all route names. Also several copies (up to 4, previously even more but in new generation devices that lead to crashes) are routable. Also helps in merging - if you have one road for a relation that always has the same name, only at intersections with other roads this cannot be merged. While if there are maybe changes in the name tag, or other subtleties less can be merged.
I really feel merge as much as possible and consider everything a line from level 1 onwards.
On Tue, 18 May 2021 at 01:02, Andrzej Popowski <popej@poczta.onet.pl> wrote:
Hi Felix,
then what about proposed:
For line--types-with-direction it would be best to give a resolution limit for each type, so if resolution is lower than associated lines can be reversed.
Does it means, that you accept wrong direction at lower resolution?
-- Best regards, Andrzej _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org
-- Felix Hartman - Openmtbmap.org & VeloMap.org
Hi Felix, If a line has a direction (which means it should not be reversed) you have to mark it as such. There is no longer any automatism which tries to guess what you want. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver@gmail.com> Gesendet: Montag, 17. Mai 2021 19:38 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] 4179 Oh yeah - what may not happen is the following hypothetical example 1. route=mtb (set line) (can be merged and reversed) 2. highway=x (set road - is not reversed merged - maybe because of oneway tag) 3. route=hiking (set line - however because the 2. highway was not reversed, while the 1 route was reversed - this is now using a different direction than 1). 1. and 3. while being possible to be reversed - have to be reversed identical. (because in my style mtb routes are on the right side, hiking routes on the left side). 2. can be reversed because it is in the center. I do not are if 1. and 3 are exchanged. Meaning it is fine if they are left or right, but they are not allowed to be both left or both right. So they can be reversed, but if 1. is reversed, 3 had to be reversed to. I have quite a few such cases in my style and as long as the reversing is consistent, and not dependent on the order in the style, this is fine. e.g this could create a problem? 1. route=mtb (can be reversed) 2. highway=oneway (downhill only at high priority) [set oneway=1} continue (sometimes with, sometimes without actions) - cannot be reversed because of oneway. 3. {delette oneway if for 2. continue with actions was used I use intermediary keys to restore an actual oneway should there have been one.} 3. route=hiking (can be reversed - but if it is reversed also route=mtb has to be reversed). On Tue, 18 May 2021 at 01:28, Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com>> wrote: I meant if there is a line created with continue - and that line is on the --line-types-with-direction list, the other copies of that line Or roads should be merged too. And I think roads should be reversed and merged as much as possible to - also at resolution 24 if not oneway-1 or on the --line-types-with-direction with list. However some people may feel that is a single copy of that line is on the --line-types-with-direction list, then none of those copies should be merged at level 0, but maybe on other levels or none at no levels at all. And I also use different linetypes for roads - so highways get thinner when zooming out. I think this makes a lot of sense for secondary to highway. Not soo much for others. That is anyhow why I feel roads only exist at level 0, from level 1 onwards there are only lines, not roads. Now for one object in OSM I sometimes create up to 10 copies - 5 due to different level, 4 for additional features and 1 invisible line that is actually responsible for routing. Having the road invisible overcomes the problem that there are few routable line types - so only solution is to make many roads invisible and only map the very common ones to a visible line type. So there is a pretty big implication on the total size if due to one of those 10 copies having the direction set or oneway set, all other 9 cannot be reversed to be merged, or not be merged at all. Also the name is not identical. E.g. I will create one line for a mtb route, another line for a hiking route. Maybe even several lines so you can see all route names. Also several copies (up to 4, previously even more but in new generation devices that lead to crashes) are routable. Also helps in merging - if you have one road for a relation that always has the same name, only at intersections with other roads this cannot be merged. While if there are maybe changes in the name tag, or other subtleties less can be merged. I really feel merge as much as possible and consider everything a line from level 1 onwards. On Tue, 18 May 2021 at 01:02, Andrzej Popowski <popej@poczta.onet.pl<mailto:popej@poczta.onet.pl>> wrote: Hi Felix, then what about proposed:
For line--types-with-direction it would be best to give a resolution limit for each type, so if resolution is lower than associated lines can be reversed.
Does it means, that you accept wrong direction at lower resolution? -- Best regards, Andrzej _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Felix Hartman - Openmtbmap.org & VeloMap.org -- Felix Hartman - Openmtbmap.org & VeloMap.org
Yes I know - I list lines which actually have direction in the list or assign direction. My worries - and that changed from version to version a bit are the routes which do not matter which side they are on - but it has to be consistent and not random. Meaning if the direction of a road/line is reversed - then either reverse all other copies of that object if you can reverse them (no direction tag) or do not reverse any. However not reverse the ones that appear after the line that is reversed, but do not reverse the ones that are before in the style. Now of course I could take routes into the non reverse list. However as I display them to low resolution, this would mean a lot of lines that would have better performance and nicer looking if reverse merged, but are not reverse merged because the underlying line maybe had a oneway set and unset, or is oneway and the position of other duplicate lines of that object are in a different position in my style file. On Tue, 18 May 2021 at 01:43, Gerd Petermann < gpetermann_muenchen@hotmail.com> wrote:
Hi Felix,
If a line has a direction (which means it should not be reversed) you have to mark it as such. There is no longer any automatism which tries to guess what you want.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver@gmail.com> Gesendet: Montag, 17. Mai 2021 19:38 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] 4179
Oh yeah - what may not happen is the following hypothetical example
1. route=mtb (set line) (can be merged and reversed) 2. highway=x (set road - is not reversed merged - maybe because of oneway tag) 3. route=hiking (set line - however because the 2. highway was not reversed, while the 1 route was reversed - this is now using a different direction than 1).
1. and 3. while being possible to be reversed - have to be reversed identical. (because in my style mtb routes are on the right side, hiking routes on the left side). 2. can be reversed because it is in the center. I do not are if 1. and 3 are exchanged. Meaning it is fine if they are left or right, but they are not allowed to be both left or both right. So they can be reversed, but if 1. is reversed, 3 had to be reversed to. I have quite a few such cases in my style and as long as the reversing is consistent, and not dependent on the order in the style, this is fine.
e.g this could create a problem?
1. route=mtb (can be reversed) 2. highway=oneway (downhill only at high priority) [set oneway=1} continue (sometimes with, sometimes without actions) - cannot be reversed because of oneway. 3. {delette oneway if for 2. continue with actions was used I use intermediary keys to restore an actual oneway should there have been one.} 3. route=hiking (can be reversed - but if it is reversed also route=mtb has to be reversed).
On Tue, 18 May 2021 at 01:28, Felix Hartmann <extremecarver@gmail.com <mailto:extremecarver@gmail.com>> wrote: I meant if there is a line created with continue - and that line is on the --line-types-with-direction list, the other copies of that line Or roads should be merged too. And I think roads should be reversed and merged as much as possible to - also at resolution 24 if not oneway-1 or on the --line-types-with-direction with list. However some people may feel that is a single copy of that line is on the --line-types-with-direction list, then none of those copies should be merged at level 0, but maybe on other levels or none at no levels at all. And I also use different linetypes for roads - so highways get thinner when zooming out. I think this makes a lot of sense for secondary to highway. Not soo much for others. That is anyhow why I feel roads only exist at level 0, from level 1 onwards there are only lines, not roads.
Now for one object in OSM I sometimes create up to 10 copies - 5 due to different level, 4 for additional features and 1 invisible line that is actually responsible for routing. Having the road invisible overcomes the problem that there are few routable line types - so only solution is to make many roads invisible and only map the very common ones to a visible line type. So there is a pretty big implication on the total size if due to one of those 10 copies having the direction set or oneway set, all other 9 cannot be reversed to be merged, or not be merged at all. Also the name is not identical. E.g. I will create one line for a mtb route, another line for a hiking route. Maybe even several lines so you can see all route names. Also several copies (up to 4, previously even more but in new generation devices that lead to crashes) are routable. Also helps in merging - if you have one road for a relation that always has the same name, only at intersections with other roads this cannot be merged. While if there are maybe changes in the name tag, or other subtleties less can be merged.
I really feel merge as much as possible and consider everything a line from level 1 onwards.
On Tue, 18 May 2021 at 01:02, Andrzej Popowski <popej@poczta.onet.pl <mailto:popej@poczta.onet.pl>> wrote: Hi Felix,
then what about proposed:
For line--types-with-direction it would be best to give a resolution limit for each type, so if resolution is lower than associated lines can be reversed.
Does it means, that you accept wrong direction at lower resolution?
-- Best regards, Andrzej _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org
-- Felix Hartman - Openmtbmap.org & VeloMap.org
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org
Some versions of mkgmap seemed to have created maps where this became a bit random. So sometimes (but rarely) the reversible mtb and hiking routes ended up on the same side of the road.... On Tue, 18 May 2021 at 02:08, Felix Hartmann <extremecarver@gmail.com> wrote:
Yes I know - I list lines which actually have direction in the list or assign direction. My worries - and that changed from version to version a bit are the routes which do not matter which side they are on - but it has to be consistent and not random.
Meaning if the direction of a road/line is reversed - then either reverse all other copies of that object if you can reverse them (no direction tag) or do not reverse any. However not reverse the ones that appear after the line that is reversed, but do not reverse the ones that are before in the style. Now of course I could take routes into the non reverse list. However as I display them to low resolution, this would mean a lot of lines that would have better performance and nicer looking if reverse merged, but are not reverse merged because the underlying line maybe had a oneway set and unset, or is oneway and the position of other duplicate lines of that object are in a different position in my style file.
On Tue, 18 May 2021 at 01:43, Gerd Petermann < gpetermann_muenchen@hotmail.com> wrote:
Hi Felix,
If a line has a direction (which means it should not be reversed) you have to mark it as such. There is no longer any automatism which tries to guess what you want.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver@gmail.com> Gesendet: Montag, 17. Mai 2021 19:38 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] 4179
Oh yeah - what may not happen is the following hypothetical example
1. route=mtb (set line) (can be merged and reversed) 2. highway=x (set road - is not reversed merged - maybe because of oneway tag) 3. route=hiking (set line - however because the 2. highway was not reversed, while the 1 route was reversed - this is now using a different direction than 1).
1. and 3. while being possible to be reversed - have to be reversed identical. (because in my style mtb routes are on the right side, hiking routes on the left side). 2. can be reversed because it is in the center. I do not are if 1. and 3 are exchanged. Meaning it is fine if they are left or right, but they are not allowed to be both left or both right. So they can be reversed, but if 1. is reversed, 3 had to be reversed to. I have quite a few such cases in my style and as long as the reversing is consistent, and not dependent on the order in the style, this is fine.
e.g this could create a problem?
1. route=mtb (can be reversed) 2. highway=oneway (downhill only at high priority) [set oneway=1} continue (sometimes with, sometimes without actions) - cannot be reversed because of oneway. 3. {delette oneway if for 2. continue with actions was used I use intermediary keys to restore an actual oneway should there have been one.} 3. route=hiking (can be reversed - but if it is reversed also route=mtb has to be reversed).
On Tue, 18 May 2021 at 01:28, Felix Hartmann <extremecarver@gmail.com <mailto:extremecarver@gmail.com>> wrote: I meant if there is a line created with continue - and that line is on the --line-types-with-direction list, the other copies of that line Or roads should be merged too. And I think roads should be reversed and merged as much as possible to - also at resolution 24 if not oneway-1 or on the --line-types-with-direction with list. However some people may feel that is a single copy of that line is on the --line-types-with-direction list, then none of those copies should be merged at level 0, but maybe on other levels or none at no levels at all. And I also use different linetypes for roads - so highways get thinner when zooming out. I think this makes a lot of sense for secondary to highway. Not soo much for others. That is anyhow why I feel roads only exist at level 0, from level 1 onwards there are only lines, not roads.
Now for one object in OSM I sometimes create up to 10 copies - 5 due to different level, 4 for additional features and 1 invisible line that is actually responsible for routing. Having the road invisible overcomes the problem that there are few routable line types - so only solution is to make many roads invisible and only map the very common ones to a visible line type. So there is a pretty big implication on the total size if due to one of those 10 copies having the direction set or oneway set, all other 9 cannot be reversed to be merged, or not be merged at all. Also the name is not identical. E.g. I will create one line for a mtb route, another line for a hiking route. Maybe even several lines so you can see all route names. Also several copies (up to 4, previously even more but in new generation devices that lead to crashes) are routable. Also helps in merging - if you have one road for a relation that always has the same name, only at intersections with other roads this cannot be merged. While if there are maybe changes in the name tag, or other subtleties less can be merged.
I really feel merge as much as possible and consider everything a line from level 1 onwards.
On Tue, 18 May 2021 at 01:02, Andrzej Popowski <popej@poczta.onet.pl <mailto:popej@poczta.onet.pl>> wrote: Hi Felix,
then what about proposed:
For line--types-with-direction it would be best to give a resolution limit for each type, so if resolution is lower than associated lines can be reversed.
Does it means, that you accept wrong direction at lower resolution?
-- Best regards, Andrzej _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org
-- Felix Hartman - Openmtbmap.org & VeloMap.org
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org
-- Felix Hartman - Openmtbmap.org & VeloMap.org
Hi Felix, the subject of this thread is 4179 (I guess you meant r4719). So, we are talking about this version, not any older or newer, right? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver@gmail.com> Gesendet: Montag, 17. Mai 2021 20:10 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] 4179 Some versions of mkgmap seemed to have created maps where this became a bit random. So sometimes (but rarely) the reversible mtb and hiking routes ended up on the same side of the road.... On Tue, 18 May 2021 at 02:08, Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com>> wrote: Yes I know - I list lines which actually have direction in the list or assign direction. My worries - and that changed from version to version a bit are the routes which do not matter which side they are on - but it has to be consistent and not random. Meaning if the direction of a road/line is reversed - then either reverse all other copies of that object if you can reverse them (no direction tag) or do not reverse any. However not reverse the ones that appear after the line that is reversed, but do not reverse the ones that are before in the style. Now of course I could take routes into the non reverse list. However as I display them to low resolution, this would mean a lot of lines that would have better performance and nicer looking if reverse merged, but are not reverse merged because the underlying line maybe had a oneway set and unset, or is oneway and the position of other duplicate lines of that object are in a different position in my style file. On Tue, 18 May 2021 at 01:43, Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>> wrote: Hi Felix, If a line has a direction (which means it should not be reversed) you have to mark it as such. There is no longer any automatism which tries to guess what you want. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag von Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com>> Gesendet: Montag, 17. Mai 2021 19:38 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] 4179 Oh yeah - what may not happen is the following hypothetical example 1. route=mtb (set line) (can be merged and reversed) 2. highway=x (set road - is not reversed merged - maybe because of oneway tag) 3. route=hiking (set line - however because the 2. highway was not reversed, while the 1 route was reversed - this is now using a different direction than 1). 1. and 3. while being possible to be reversed - have to be reversed identical. (because in my style mtb routes are on the right side, hiking routes on the left side). 2. can be reversed because it is in the center. I do not are if 1. and 3 are exchanged. Meaning it is fine if they are left or right, but they are not allowed to be both left or both right. So they can be reversed, but if 1. is reversed, 3 had to be reversed to. I have quite a few such cases in my style and as long as the reversing is consistent, and not dependent on the order in the style, this is fine. e.g this could create a problem? 1. route=mtb (can be reversed) 2. highway=oneway (downhill only at high priority) [set oneway=1} continue (sometimes with, sometimes without actions) - cannot be reversed because of oneway. 3. {delette oneway if for 2. continue with actions was used I use intermediary keys to restore an actual oneway should there have been one.} 3. route=hiking (can be reversed - but if it is reversed also route=mtb has to be reversed). On Tue, 18 May 2021 at 01:28, Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>> wrote: I meant if there is a line created with continue - and that line is on the --line-types-with-direction list, the other copies of that line Or roads should be merged too. And I think roads should be reversed and merged as much as possible to - also at resolution 24 if not oneway-1 or on the --line-types-with-direction with list. However some people may feel that is a single copy of that line is on the --line-types-with-direction list, then none of those copies should be merged at level 0, but maybe on other levels or none at no levels at all. And I also use different linetypes for roads - so highways get thinner when zooming out. I think this makes a lot of sense for secondary to highway. Not soo much for others. That is anyhow why I feel roads only exist at level 0, from level 1 onwards there are only lines, not roads. Now for one object in OSM I sometimes create up to 10 copies - 5 due to different level, 4 for additional features and 1 invisible line that is actually responsible for routing. Having the road invisible overcomes the problem that there are few routable line types - so only solution is to make many roads invisible and only map the very common ones to a visible line type. So there is a pretty big implication on the total size if due to one of those 10 copies having the direction set or oneway set, all other 9 cannot be reversed to be merged, or not be merged at all. Also the name is not identical. E.g. I will create one line for a mtb route, another line for a hiking route. Maybe even several lines so you can see all route names. Also several copies (up to 4, previously even more but in new generation devices that lead to crashes) are routable. Also helps in merging - if you have one road for a relation that always has the same name, only at intersections with other roads this cannot be merged. While if there are maybe changes in the name tag, or other subtleties less can be merged. I really feel merge as much as possible and consider everything a line from level 1 onwards. On Tue, 18 May 2021 at 01:02, Andrzej Popowski <popej@poczta.onet.pl<mailto:popej@poczta.onet.pl><mailto:popej@poczta.onet.pl<mailto:popej@poczta.onet.pl>>> wrote: Hi Felix, then what about proposed:
For line--types-with-direction it would be best to give a resolution limit for each type, so if resolution is lower than associated lines can be reversed.
Does it means, that you accept wrong direction at lower resolution? -- Best regards, Andrzej _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Felix Hartman - Openmtbmap.org & VeloMap.org -- Felix Hartman - Openmtbmap.org & VeloMap.org _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Felix Hartman - Openmtbmap.org & VeloMap.org -- Felix Hartman - Openmtbmap.org & VeloMap.org
yes, but I am not sure which version got the the left right mixed up. I think that was the one that ended up being much smaller and better routing however not respecting the oneways correctly too. I do notice that from one compile to another mkgmap sometimes decide to reverse to opposite directions, but since 4709 it seems it always correctly handled the reversible roads to be changed consistently. 4709, 4711, 4715, and 4719 all seem to be correct - but how the DP filter works on roads is changing each version (or each compile). On the other hand lines seem to be very consistently handled. Kinda only visible by selecting lowest detail level in Basecamp. With lowest or lower and zooming out far the maps do look ugly. But I guess this cannot be avoided. Its fine as its much better as too detailled and slow - and usually a map should only be used in normal detail, or differ 1 step. Else the map is really badly designed. If on low resolution the map still looks good - that is fine (I know I could decrease DP filter to make it nicer looking). On Tue, 18 May 2021 at 02:21, Gerd Petermann < gpetermann_muenchen@hotmail.com> wrote:
Hi Felix,
the subject of this thread is 4179 (I guess you meant r4719). So, we are talking about this version, not any older or newer, right?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver@gmail.com> Gesendet: Montag, 17. Mai 2021 20:10 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] 4179
Some versions of mkgmap seemed to have created maps where this became a bit random. So sometimes (but rarely) the reversible mtb and hiking routes ended up on the same side of the road....
On Tue, 18 May 2021 at 02:08, Felix Hartmann <extremecarver@gmail.com <mailto:extremecarver@gmail.com>> wrote: Yes I know - I list lines which actually have direction in the list or assign direction. My worries - and that changed from version to version a bit are the routes which do not matter which side they are on - but it has to be consistent and not random.
Meaning if the direction of a road/line is reversed - then either reverse all other copies of that object if you can reverse them (no direction tag) or do not reverse any. However not reverse the ones that appear after the line that is reversed, but do not reverse the ones that are before in the style. Now of course I could take routes into the non reverse list. However as I display them to low resolution, this would mean a lot of lines that would have better performance and nicer looking if reverse merged, but are not reverse merged because the underlying line maybe had a oneway set and unset, or is oneway and the position of other duplicate lines of that object are in a different position in my style file.
On Tue, 18 May 2021 at 01:43, Gerd Petermann < gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>> wrote: Hi Felix,
If a line has a direction (which means it should not be reversed) you have to mark it as such. There is no longer any automatism which tries to guess what you want.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag von Felix Hartmann < extremecarver@gmail.com<mailto:extremecarver@gmail.com>> Gesendet: Montag, 17. Mai 2021 19:38 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] 4179
Oh yeah - what may not happen is the following hypothetical example
1. route=mtb (set line) (can be merged and reversed) 2. highway=x (set road - is not reversed merged - maybe because of oneway tag) 3. route=hiking (set line - however because the 2. highway was not reversed, while the 1 route was reversed - this is now using a different direction than 1).
1. and 3. while being possible to be reversed - have to be reversed identical. (because in my style mtb routes are on the right side, hiking routes on the left side). 2. can be reversed because it is in the center. I do not are if 1. and 3 are exchanged. Meaning it is fine if they are left or right, but they are not allowed to be both left or both right. So they can be reversed, but if 1. is reversed, 3 had to be reversed to. I have quite a few such cases in my style and as long as the reversing is consistent, and not dependent on the order in the style, this is fine.
e.g this could create a problem?
1. route=mtb (can be reversed) 2. highway=oneway (downhill only at high priority) [set oneway=1} continue (sometimes with, sometimes without actions) - cannot be reversed because of oneway. 3. {delette oneway if for 2. continue with actions was used I use intermediary keys to restore an actual oneway should there have been one.} 3. route=hiking (can be reversed - but if it is reversed also route=mtb has to be reversed).
On Tue, 18 May 2021 at 01:28, Felix Hartmann <extremecarver@gmail.com <mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com>>> wrote: I meant if there is a line created with continue - and that line is on the --line-types-with-direction list, the other copies of that line Or roads should be merged too. And I think roads should be reversed and merged as much as possible to - also at resolution 24 if not oneway-1 or on the --line-types-with-direction with list. However some people may feel that is a single copy of that line is on the --line-types-with-direction list, then none of those copies should be merged at level 0, but maybe on other levels or none at no levels at all. And I also use different linetypes for roads - so highways get thinner when zooming out. I think this makes a lot of sense for secondary to highway. Not soo much for others. That is anyhow why I feel roads only exist at level 0, from level 1 onwards there are only lines, not roads.
Now for one object in OSM I sometimes create up to 10 copies - 5 due to different level, 4 for additional features and 1 invisible line that is actually responsible for routing. Having the road invisible overcomes the problem that there are few routable line types - so only solution is to make many roads invisible and only map the very common ones to a visible line type. So there is a pretty big implication on the total size if due to one of those 10 copies having the direction set or oneway set, all other 9 cannot be reversed to be merged, or not be merged at all. Also the name is not identical. E.g. I will create one line for a mtb route, another line for a hiking route. Maybe even several lines so you can see all route names. Also several copies (up to 4, previously even more but in new generation devices that lead to crashes) are routable. Also helps in merging - if you have one road for a relation that always has the same name, only at intersections with other roads this cannot be merged. While if there are maybe changes in the name tag, or other subtleties less can be merged.
I really feel merge as much as possible and consider everything a line from level 1 onwards.
On Tue, 18 May 2021 at 01:02, Andrzej Popowski <popej@poczta.onet.pl <mailto:popej@poczta.onet.pl><mailto:popej@poczta.onet.pl<mailto: popej@poczta.onet.pl>>> wrote: Hi Felix,
then what about proposed:
For line--types-with-direction it would be best to give a resolution limit for each type, so if resolution is lower than associated lines can be reversed.
Does it means, that you accept wrong direction at lower resolution?
-- Best regards, Andrzej _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org
-- Felix Hartman - Openmtbmap.org & VeloMap.org
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org
-- Felix Hartman - Openmtbmap.org & VeloMap.org
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org
Hi Felix, reg. right/left mixed up: My understanding is that ALL line types which are used with/for overlays and are not symetrical should be marked as "has a direction". Unfortunately I don't know how to recognize them looking at the TYP file. If someone has an idea I could add code to produce the candidates for the --line-types-with-direction list. Maybe use only level 0 for routable lines (as the default style does with roundabouts). This presumes that your routable line types are rendered invisible. I see many non-routable lines with type 0x10508 which seems to be invisible? ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver@gmail.com> Gesendet: Montag, 17. Mai 2021 21:49 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] 4179 yes, but I am not sure which version got the the left right mixed up. I think that was the one that ended up being much smaller and better routing however not respecting the oneways correctly too. I do notice that from one compile to another mkgmap sometimes decide to reverse to opposite directions, but since 4709 it seems it always correctly handled the reversible roads to be changed consistently. 4709, 4711, 4715, and 4719 all seem to be correct - but how the DP filter works on roads is changing each version (or each compile). On the other hand lines seem to be very consistently handled. Kinda only visible by selecting lowest detail level in Basecamp. With lowest or lower and zooming out far the maps do look ugly. But I guess this cannot be avoided. Its fine as its much better as too detailled and slow - and usually a map should only be used in normal detail, or differ 1 step. Else the map is really badly designed. If on low resolution the map still looks good - that is fine (I know I could decrease DP filter to make it nicer looking). On Tue, 18 May 2021 at 02:21, Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>> wrote: Hi Felix, the subject of this thread is 4179 (I guess you meant r4719). So, we are talking about this version, not any older or newer, right? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag von Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com>> Gesendet: Montag, 17. Mai 2021 20:10 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] 4179 Some versions of mkgmap seemed to have created maps where this became a bit random. So sometimes (but rarely) the reversible mtb and hiking routes ended up on the same side of the road.... On Tue, 18 May 2021 at 02:08, Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>> wrote: Yes I know - I list lines which actually have direction in the list or assign direction. My worries - and that changed from version to version a bit are the routes which do not matter which side they are on - but it has to be consistent and not random. Meaning if the direction of a road/line is reversed - then either reverse all other copies of that object if you can reverse them (no direction tag) or do not reverse any. However not reverse the ones that appear after the line that is reversed, but do not reverse the ones that are before in the style. Now of course I could take routes into the non reverse list. However as I display them to low resolution, this would mean a lot of lines that would have better performance and nicer looking if reverse merged, but are not reverse merged because the underlying line maybe had a oneway set and unset, or is oneway and the position of other duplicate lines of that object are in a different position in my style file. On Tue, 18 May 2021 at 01:43, Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>> wrote: Hi Felix, If a line has a direction (which means it should not be reversed) you have to mark it as such. There is no longer any automatism which tries to guess what you want. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>>> im Auftrag von Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>> Gesendet: Montag, 17. Mai 2021 19:38 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] 4179 Oh yeah - what may not happen is the following hypothetical example 1. route=mtb (set line) (can be merged and reversed) 2. highway=x (set road - is not reversed merged - maybe because of oneway tag) 3. route=hiking (set line - however because the 2. highway was not reversed, while the 1 route was reversed - this is now using a different direction than 1). 1. and 3. while being possible to be reversed - have to be reversed identical. (because in my style mtb routes are on the right side, hiking routes on the left side). 2. can be reversed because it is in the center. I do not are if 1. and 3 are exchanged. Meaning it is fine if they are left or right, but they are not allowed to be both left or both right. So they can be reversed, but if 1. is reversed, 3 had to be reversed to. I have quite a few such cases in my style and as long as the reversing is consistent, and not dependent on the order in the style, this is fine. e.g this could create a problem? 1. route=mtb (can be reversed) 2. highway=oneway (downhill only at high priority) [set oneway=1} continue (sometimes with, sometimes without actions) - cannot be reversed because of oneway. 3. {delette oneway if for 2. continue with actions was used I use intermediary keys to restore an actual oneway should there have been one.} 3. route=hiking (can be reversed - but if it is reversed also route=mtb has to be reversed). On Tue, 18 May 2021 at 01:28, Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>>> wrote: I meant if there is a line created with continue - and that line is on the --line-types-with-direction list, the other copies of that line Or roads should be merged too. And I think roads should be reversed and merged as much as possible to - also at resolution 24 if not oneway-1 or on the --line-types-with-direction with list. However some people may feel that is a single copy of that line is on the --line-types-with-direction list, then none of those copies should be merged at level 0, but maybe on other levels or none at no levels at all. And I also use different linetypes for roads - so highways get thinner when zooming out. I think this makes a lot of sense for secondary to highway. Not soo much for others. That is anyhow why I feel roads only exist at level 0, from level 1 onwards there are only lines, not roads. Now for one object in OSM I sometimes create up to 10 copies - 5 due to different level, 4 for additional features and 1 invisible line that is actually responsible for routing. Having the road invisible overcomes the problem that there are few routable line types - so only solution is to make many roads invisible and only map the very common ones to a visible line type. So there is a pretty big implication on the total size if due to one of those 10 copies having the direction set or oneway set, all other 9 cannot be reversed to be merged, or not be merged at all. Also the name is not identical. E.g. I will create one line for a mtb route, another line for a hiking route. Maybe even several lines so you can see all route names. Also several copies (up to 4, previously even more but in new generation devices that lead to crashes) are routable. Also helps in merging - if you have one road for a relation that always has the same name, only at intersections with other roads this cannot be merged. While if there are maybe changes in the name tag, or other subtleties less can be merged. I really feel merge as much as possible and consider everything a line from level 1 onwards. On Tue, 18 May 2021 at 01:02, Andrzej Popowski <popej@poczta.onet.pl<mailto:popej@poczta.onet.pl><mailto:popej@poczta.onet.pl<mailto:popej@poczta.onet.pl>><mailto:popej@poczta.onet.pl<mailto:popej@poczta.onet.pl><mailto:popej@poczta.onet.pl<mailto:popej@poczta.onet.pl>>>> wrote: Hi Felix, then what about proposed:
For line--types-with-direction it would be best to give a resolution limit for each type, so if resolution is lower than associated lines can be reversed.
Does it means, that you accept wrong direction at lower resolution? -- Best regards, Andrzej _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Felix Hartman - Openmtbmap.org & VeloMap.org -- Felix Hartman - Openmtbmap.org & VeloMap.org _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Felix Hartman - Openmtbmap.org & VeloMap.org -- Felix Hartman - Openmtbmap.org & VeloMap.org _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Felix Hartman - Openmtbmap.org & VeloMap.org
well as I said - I think it is actually good if they are reversed - so the same route stays a longer time on the road. With the current versions this works well - it seems all "copies" that can be reversed, are reversed. Even though something is asysmetrical - it does not mean that they may not be reversed. Only lines which really have oneway or show direction should never be reversed. On Tue, 18 May 2021 at 13:10, Gerd Petermann < gpetermann_muenchen@hotmail.com> wrote:
Hi Felix,
reg. right/left mixed up: My understanding is that ALL line types which are used with/for overlays and are not symetrical should be marked as "has a direction". Unfortunately I don't know how to recognize them looking at the TYP file. If someone has an idea I could add code to produce the candidates for the --line-types-with-direction list.
Maybe use only level 0 for routable lines (as the default style does with roundabouts). This presumes that your routable line types are rendered invisible. I see many non-routable lines with type 0x10508 which seems to be invisible?
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver@gmail.com> Gesendet: Montag, 17. Mai 2021 21:49 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] 4179
yes, but I am not sure which version got the the left right mixed up. I think that was the one that ended up being much smaller and better routing however not respecting the oneways correctly too. I do notice that from one compile to another mkgmap sometimes decide to reverse to opposite directions, but since 4709 it seems it always correctly handled the reversible roads to be changed consistently. 4709, 4711, 4715, and 4719 all seem to be correct - but how the DP filter works on roads is changing each version (or each compile). On the other hand lines seem to be very consistently handled. Kinda only visible by selecting lowest detail level in Basecamp. With lowest or lower and zooming out far the maps do look ugly. But I guess this cannot be avoided. Its fine as its much better as too detailled and slow - and usually a map should only be used in normal detail, or differ 1 step. Else the map is really badly designed. If on low resolution the map still looks good - that is fine (I kno w I could decrease DP filter to make it nicer looking).
On Tue, 18 May 2021 at 02:21, Gerd Petermann < gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>> wrote: Hi Felix,
the subject of this thread is 4179 (I guess you meant r4719). So, we are talking about this version, not any older or newer, right?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag von Felix Hartmann < extremecarver@gmail.com<mailto:extremecarver@gmail.com>> Gesendet: Montag, 17. Mai 2021 20:10 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] 4179
Some versions of mkgmap seemed to have created maps where this became a bit random. So sometimes (but rarely) the reversible mtb and hiking routes ended up on the same side of the road....
On Tue, 18 May 2021 at 02:08, Felix Hartmann <extremecarver@gmail.com <mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com>>> wrote: Yes I know - I list lines which actually have direction in the list or assign direction. My worries - and that changed from version to version a bit are the routes which do not matter which side they are on - but it has to be consistent and not random.
Meaning if the direction of a road/line is reversed - then either reverse all other copies of that object if you can reverse them (no direction tag) or do not reverse any. However not reverse the ones that appear after the line that is reversed, but do not reverse the ones that are before in the style. Now of course I could take routes into the non reverse list. However as I display them to low resolution, this would mean a lot of lines that would have better performance and nicer looking if reverse merged, but are not reverse merged because the underlying line maybe had a oneway set and unset, or is oneway and the position of other duplicate lines of that object are in a different position in my style file.
On Tue, 18 May 2021 at 01:43, Gerd Petermann < gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com
<mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com>>> wrote: Hi Felix,
If a line has a direction (which means it should not be reversed) you have to mark it as such. There is no longer any automatism which tries to guess what you want.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>>> im Auftrag von Felix Hartmann < extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto: extremecarver@gmail.com<mailto:extremecarver@gmail.com>>> Gesendet: Montag, 17. Mai 2021 19:38 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] 4179
Oh yeah - what may not happen is the following hypothetical example
1. route=mtb (set line) (can be merged and reversed) 2. highway=x (set road - is not reversed merged - maybe because of oneway tag) 3. route=hiking (set line - however because the 2. highway was not reversed, while the 1 route was reversed - this is now using a different direction than 1).
1. and 3. while being possible to be reversed - have to be reversed identical. (because in my style mtb routes are on the right side, hiking routes on the left side). 2. can be reversed because it is in the center. I do not are if 1. and 3 are exchanged. Meaning it is fine if they are left or right, but they are not allowed to be both left or both right. So they can be reversed, but if 1. is reversed, 3 had to be reversed to. I have quite a few such cases in my style and as long as the reversing is consistent, and not dependent on the order in the style, this is fine.
e.g this could create a problem?
1. route=mtb (can be reversed) 2. highway=oneway (downhill only at high priority) [set oneway=1} continue (sometimes with, sometimes without actions) - cannot be reversed because of oneway. 3. {delette oneway if for 2. continue with actions was used I use intermediary keys to restore an actual oneway should there have been one.} 3. route=hiking (can be reversed - but if it is reversed also route=mtb has to be reversed).
On Tue, 18 May 2021 at 01:28, Felix Hartmann <extremecarver@gmail.com <mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com>><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com>>>> wrote: I meant if there is a line created with continue - and that line is on the --line-types-with-direction list, the other copies of that line Or roads should be merged too. And I think roads should be reversed and merged as much as possible to - also at resolution 24 if not oneway-1 or on the --line-types-with-direction with list. However some people may feel that is a single copy of that line is on the --line-types-with-direction list, then none of those copies should be merged at level 0, but maybe on other levels or none at no levels at all. And I also use different linetypes for roads - so highways get thinner when zooming out. I think this makes a lot of sense for secondary to highway. Not soo much for others. That is anyhow why I feel roads only exist at level 0, from level 1 onwards there are only lines, not roads.
Now for one object in OSM I sometimes create up to 10 copies - 5 due to different level, 4 for additional features and 1 invisible line that is actually responsible for routing. Having the road invisible overcomes the problem that there are few routable line types - so only solution is to make many roads invisible and only map the very common ones to a visible line type. So there is a pretty big implication on the total size if due to one of those 10 copies having the direction set or oneway set, all other 9 cannot be reversed to be merged, or not be merged at all. Also the name is not identical. E.g. I will create one line for a mtb route, another line for a hiking route. Maybe even several lines so you can see all route names. Also several copies (up to 4, previously even more but in new generation devices that lead to crashes) are routable. Also helps in merging - if you have one road for a relation that always has the same name, only at intersections with other roads this cannot be merged. While if there are maybe changes in the name tag, or other subtleties less can be merged.
I really feel merge as much as possible and consider everything a line from level 1 onwards.
On Tue, 18 May 2021 at 01:02, Andrzej Popowski <popej@poczta.onet.pl <mailto:popej@poczta.onet.pl><mailto:popej@poczta.onet.pl<mailto: popej@poczta.onet.pl>><mailto:popej@poczta.onet.pl<mailto: popej@poczta.onet.pl><mailto:popej@poczta.onet.pl<mailto: popej@poczta.onet.pl>>>> wrote: Hi Felix,
then what about proposed:
For line--types-with-direction it would be best to give a resolution limit for each type, so if resolution is lower than associated lines can be reversed.
Does it means, that you accept wrong direction at lower resolution?
-- Best regards, Andrzej _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org
-- Felix Hartman - Openmtbmap.org & VeloMap.org
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org
-- Felix Hartman - Openmtbmap.org & VeloMap.org
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org
participants (3)
-
Andrzej Popowski -
Felix Hartmann -
Gerd Petermann