fix error in LineMergeFilter reg. lines with direction The line merger should not merge lines if one has the direction flag set and the other has not. Problem exists also in trunk. Hmm fixing this stopped all the nice size optimization. Map size got much bigger again. I did not find any place where this mattered. Routing was also not affected badly. Maybe I did not look good enough? I do not see why not to merge them. As long as it`s not the opposite it seems fine... Map size increase/decrease is around 1.5% with my style. So thats quite a big difference. -- Felix Hartman - Openmtbmap.org & VeloMap.org
Hi Felix, yes, size increases if your style sets mkgmap:has-direction=true. I just want to make sure that the direction flag is treated correctly first. As already discussed we might introduce a new option or tag to tell mkgmap the min. level at which the direction has to be kept. You suggested to ignore direction at level > 0, I think it might depend on the style and TYP. I'll play with the OFM style to find out more. The change should not affect routing at all (none of the changes in the low-res-opt branch should). Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver@gmail.com> Gesendet: Donnerstag, 13. Mai 2021 02:59 An: Development list for mkgmap Betreff: [mkgmap-dev] Commit 4710 fix error in LineMergeFilter reg. lines with direction The line merger should not merge lines if one has the direction flag set and the other has not. Problem exists also in trunk. Hmm fixing this stopped all the nice size optimization. Map size got much bigger again. I did not find any place where this mattered. Routing was also not affected badly. Maybe I did not look good enough? I do not see why not to merge them. As long as it`s not the opposite it seems fine... Map size increase/decrease is around 1.5% with my style. So thats quite a big difference. -- Felix Hartman - Openmtbmap.org & VeloMap.org
I kinda feel by default even oneway=yes should only mean do not change direction for level 0. If someone uses a style to have arrows showing the oneway, then only for that arrow line (defined by tag) the direction cannot be reversed. Yes the problem of DP filter rests - I feel this does not matter for resolution 24 and even 23, but if you display arrows for resolution 22 or higher then a tag should not merge the underlying lines. Besides rivers (then also many styles do not have an arrow for rivers, or you could decide to show the arrows only at resolution 24 and 23) few lines will be objection dependent. I will try out now if there is any change in routing - but I will only write again if there unexpectedly is. The sharp angles changed routing for the better for my maps by quite a lot. So maybe with now some less lines being merged, there actually will be a little change for the worse back to the old behavior. Not sure.. On Thu, 13 May 2021 at 14:07, Gerd Petermann < gpetermann_muenchen@hotmail.com> wrote:
Hi Felix,
yes, size increases if your style sets mkgmap:has-direction=true. I just want to make sure that the direction flag is treated correctly first. As already discussed we might introduce a new option or tag to tell mkgmap the min. level at which the direction has to be kept. You suggested to ignore direction at level > 0, I think it might depend on the style and TYP. I'll play with the OFM style to find out more.
The change should not affect routing at all (none of the changes in the low-res-opt branch should).
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver@gmail.com> Gesendet: Donnerstag, 13. Mai 2021 02:59 An: Development list for mkgmap Betreff: [mkgmap-dev] Commit 4710
fix error in LineMergeFilter reg. lines with direction The line merger should not merge lines if one has the direction flag set and the other has not. Problem exists also in trunk.
Hmm fixing this stopped all the nice size optimization. Map size got much bigger again. I did not find any place where this mattered. Routing was also not affected badly. Maybe I did not look good enough?
I do not see why not to merge them. As long as it`s not the opposite it seems fine... Map size increase/decrease is around 1.5% with my style. So thats quite a big difference. -- 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, FYI: I just found out that the current code to detect if the style sets mkgmap:has-direction=true doesn't work. Seems I didn't test this :( The change in r4710 changed only the LineMerger in the branch. Even with r4711 LineMerger only merges roads in maps without NET, at least that's what's intended. My understanding is that r4703 changed routing, possibly also r4704. The merge from trunk also changed routing in the branches (r4706 and r4707). I'm now fixing the detection code, next I'm trying to figure out how to configure the details reg. direction handling. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver@gmail.com> Gesendet: Donnerstag, 13. Mai 2021 09:52 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Commit 4710 I kinda feel by default even oneway=yes should only mean do not change direction for level 0. If someone uses a style to have arrows showing the oneway, then only for that arrow line (defined by tag) the direction cannot be reversed. Yes the problem of DP filter rests - I feel this does not matter for resolution 24 and even 23, but if you display arrows for resolution 22 or higher then a tag should not merge the underlying lines. Besides rivers (then also many styles do not have an arrow for rivers, or you could decide to show the arrows only at resolution 24 and 23) few lines will be objection dependent. I will try out now if there is any change in routing - but I will only write again if there unexpectedly is. The sharp angles changed routing for the better for my maps by quite a lot. So maybe with now some less lines being merged, there actually will be a little change for the worse back to the old behavior. Not sure.. On Thu, 13 May 2021 at 14:07, Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>> wrote: Hi Felix, yes, size increases if your style sets mkgmap:has-direction=true. I just want to make sure that the direction flag is treated correctly first. As already discussed we might introduce a new option or tag to tell mkgmap the min. level at which the direction has to be kept. You suggested to ignore direction at level > 0, I think it might depend on the style and TYP. I'll play with the OFM style to find out more. The change should not affect routing at all (none of the changes in the low-res-opt branch should). 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: Donnerstag, 13. Mai 2021 02:59 An: Development list for mkgmap Betreff: [mkgmap-dev] Commit 4710 fix error in LineMergeFilter reg. lines with direction The line merger should not merge lines if one has the direction flag set and the other has not. Problem exists also in trunk. Hmm fixing this stopped all the nice size optimization. Map size got much bigger again. I did not find any place where this mattered. Routing was also not affected badly. Maybe I did not look good enough? I do not see why not to merge them. As long as it`s not the opposite it seems fine... Map size increase/decrease is around 1.5% with my style. So thats quite a big difference. -- 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
Hi all, I didn't know about mkgmap:has-direction. Good to see there is possibility to protect direction of the line. Please note, there are lines, which aren't roads but really have directions. Some example: - waterway=river, stream, maybe canal, ditch too, - natural=cliff, - man_made=embankment, - sidewalk=left, right. Are there any situation, where mkgmap adds this tag by itself? -- Best regards, Andrzej
Hi Andrzej, the tag was introduced with r4703: https://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4703 Some of the code didn't work until r4713: https://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4713 Are there any situation, where mkgmap adds this tag by itself? I might be added to roads, but because of an error: Only if you use r4713 This is still experimental. I have committed the code in r4703 to allow testing and get usability reports. I'll probably add an alternative option to manage this direction flag based on type and resolution, the current handling seems too complex. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Andrzej Popowski <popej@poczta.onet.pl> Gesendet: Donnerstag, 13. Mai 2021 11:10 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] Commit 4710 Hi all, I didn't know about mkgmap:has-direction. Good to see there is possibility to protect direction of the line. Please note, there are lines, which aren't roads but really have directions. Some example: - waterway=river, stream, maybe canal, ditch too, - natural=cliff, - man_made=embankment, - sidewalk=left, right. Are there any situation, where mkgmap adds this tag by itself? -- Best regards, Andrzej _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi all, I've tried to modify my version of Minkos OFM Lite style to use new tag mkgmap:has-direction=true. I should have done this earlier :( Maybe Felix was right when he suggested to add a new option to specify a list of types which have a direction: http://gis.19327.n8.nabble.com/new-branch-low-res-opt-to-test-improvements-f... It can be very difficult to change an existing style. Minkos OFM style adds the overlay lines (with direction) first and the road last. Another style might do this in another order. Maybe I am overly cautious here. Most important is: We have to make sure that lines with a direction are not reversed because of merging (I think we already might reverse them to handle oneway=-1), else the map will show wrong information. With the --housenumbers option we already sometimes have the problem that an overlay line is not renderend exactly like the underlying road because number nodes are added to the road and not to the overlay line. The effect is that the overlay line(s) are straight where the road bends a little bit. I expect the same problem when mkgmap merges roads because they have no direction and the overlaying ways are not merged because they have different types (e.g. for left/right cycle lanes) I guess I have to produce a test case first to demonstrate the problem... Gerd ________________________________________ Von: Gerd Petermann <gpetermann_muenchen@hotmail.com> Gesendet: Donnerstag, 13. Mai 2021 10:03 An: Development list for mkgmap Betreff: AW: [mkgmap-dev] Commit 4710 Hi Felix, FYI: I just found out that the current code to detect if the style sets mkgmap:has-direction=true doesn't work. Seems I didn't test this :( The change in r4710 changed only the LineMerger in the branch. Even with r4711 LineMerger only merges roads in maps without NET, at least that's what's intended. My understanding is that r4703 changed routing, possibly also r4704. The merge from trunk also changed routing in the branches (r4706 and r4707). I'm now fixing the detection code, next I'm trying to figure out how to configure the details reg. direction handling. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver@gmail.com> Gesendet: Donnerstag, 13. Mai 2021 09:52 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Commit 4710 I kinda feel by default even oneway=yes should only mean do not change direction for level 0. If someone uses a style to have arrows showing the oneway, then only for that arrow line (defined by tag) the direction cannot be reversed. Yes the problem of DP filter rests - I feel this does not matter for resolution 24 and even 23, but if you display arrows for resolution 22 or higher then a tag should not merge the underlying lines. Besides rivers (then also many styles do not have an arrow for rivers, or you could decide to show the arrows only at resolution 24 and 23) few lines will be objection dependent. I will try out now if there is any change in routing - but I will only write again if there unexpectedly is. The sharp angles changed routing for the better for my maps by quite a lot. So maybe with now some less lines being merged, there actually will be a little change for the worse back to the old behavior. Not sure.. On Thu, 13 May 2021 at 14:07, Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>> wrote: Hi Felix, yes, size increases if your style sets mkgmap:has-direction=true. I just want to make sure that the direction flag is treated correctly first. As already discussed we might introduce a new option or tag to tell mkgmap the min. level at which the direction has to be kept. You suggested to ignore direction at level > 0, I think it might depend on the style and TYP. I'll play with the OFM style to find out more. The change should not affect routing at all (none of the changes in the low-res-opt branch should). 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: Donnerstag, 13. Mai 2021 02:59 An: Development list for mkgmap Betreff: [mkgmap-dev] Commit 4710 fix error in LineMergeFilter reg. lines with direction The line merger should not merge lines if one has the direction flag set and the other has not. Problem exists also in trunk. Hmm fixing this stopped all the nice size optimization. Map size got much bigger again. I did not find any place where this mattered. Routing was also not affected badly. Maybe I did not look good enough? I do not see why not to merge them. As long as it`s not the opposite it seems fine... Map size increase/decrease is around 1.5% with my style. So thats quite a big difference. -- 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 just got to test routing - and the current version is a degradation vs the intermediate version from yesterday for my maps. The current version routes better than before, but worse than the intermediate version. As for the list - it is a bit more complicated inside the style but doable. I really do not know what happens to those ways where I first set a direction for an downhill only way with higher priority, then remove the direction for a way that can be used in both directions at lower priority. Maybe sometimes also doing this the other way around. A list with type and max resolution used would be much easier for writing your style. Instead of adding 60-100 lines with the filter it would be done with 10 or so. Canals should not have a direction, they do not flow. Sidewalk=left, right is the same as for the various cylceway,cycletrack options - those are really not reversible. The underlying way could be reversed however - and I guess they are only used for level 0. Oneway arrows for streets are maybe used from resoltuion 24-22 or 24 only. Cliffs are also only high resolution. For me rivers are the only thing which really go into lower resolutions. On Thu, 13 May 2021 at 16:03, Gerd Petermann < gpetermann_muenchen@hotmail.com> wrote:
Hi Felix,
FYI: I just found out that the current code to detect if the style sets mkgmap:has-direction=true doesn't work. Seems I didn't test this :( The change in r4710 changed only the LineMerger in the branch. Even with r4711 LineMerger only merges roads in maps without NET, at least that's what's intended.
My understanding is that r4703 changed routing, possibly also r4704. The merge from trunk also changed routing in the branches (r4706 and r4707).
I'm now fixing the detection code, next I'm trying to figure out how to configure the details reg. direction handling.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver@gmail.com> Gesendet: Donnerstag, 13. Mai 2021 09:52 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Commit 4710
I kinda feel by default even oneway=yes should only mean do not change direction for level 0. If someone uses a style to have arrows showing the oneway, then only for that arrow line (defined by tag) the direction cannot be reversed. Yes the problem of DP filter rests - I feel this does not matter for resolution 24 and even 23, but if you display arrows for resolution 22 or higher then a tag should not merge the underlying lines. Besides rivers (then also many styles do not have an arrow for rivers, or you could decide to show the arrows only at resolution 24 and 23) few lines will be objection dependent.
I will try out now if there is any change in routing - but I will only write again if there unexpectedly is. The sharp angles changed routing for the better for my maps by quite a lot. So maybe with now some less lines being merged, there actually will be a little change for the worse back to the old behavior. Not sure..
On Thu, 13 May 2021 at 14:07, Gerd Petermann < gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>> wrote: Hi Felix,
yes, size increases if your style sets mkgmap:has-direction=true. I just want to make sure that the direction flag is treated correctly first. As already discussed we might introduce a new option or tag to tell mkgmap the min. level at which the direction has to be kept. You suggested to ignore direction at level > 0, I think it might depend on the style and TYP. I'll play with the OFM style to find out more.
The change should not affect routing at all (none of the changes in the low-res-opt branch should).
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: Donnerstag, 13. Mai 2021 02:59 An: Development list for mkgmap Betreff: [mkgmap-dev] Commit 4710
fix error in LineMergeFilter reg. lines with direction The line merger should not merge lines if one has the direction flag set and the other has not. Problem exists also in trunk.
Hmm fixing this stopped all the nice size optimization. Map size got much bigger again. I did not find any place where this mattered. Routing was also not affected badly. Maybe I did not look good enough?
I do not see why not to merge them. As long as it`s not the opposite it seems fine... Map size increase/decrease is around 1.5% with my style. So thats quite a big difference. -- 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, please tell me exactly which versions you tested reg. routing. Note that the branches do not yet contain the latest changes in trunk. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver@gmail.com> Gesendet: Donnerstag, 13. Mai 2021 11:28 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Commit 4710 Well I just got to test routing - and the current version is a degradation vs the intermediate version from yesterday for my maps. The current version routes better than before, but worse than the intermediate version. As for the list - it is a bit more complicated inside the style but doable. I really do not know what happens to those ways where I first set a direction for an downhill only way with higher priority, then remove the direction for a way that can be used in both directions at lower priority. Maybe sometimes also doing this the other way around. A list with type and max resolution used would be much easier for writing your style. Instead of adding 60-100 lines with the filter it would be done with 10 or so. Canals should not have a direction, they do not flow. Sidewalk=left, right is the same as for the various cylceway,cycletrack options - those are really not reversible. The underlying way could be reversed however - and I guess they are only used for level 0. Oneway arrows for streets are maybe used from resoltuion 24-22 or 24 only. Cliffs are also only high resolution. For me rivers are the only thing which really go into lower resolutions. On Thu, 13 May 2021 at 16:03, Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>> wrote: Hi Felix, FYI: I just found out that the current code to detect if the style sets mkgmap:has-direction=true doesn't work. Seems I didn't test this :( The change in r4710 changed only the LineMerger in the branch. Even with r4711 LineMerger only merges roads in maps without NET, at least that's what's intended. My understanding is that r4703 changed routing, possibly also r4704. The merge from trunk also changed routing in the branches (r4706 and r4707). I'm now fixing the detection code, next I'm trying to figure out how to configure the details reg. direction handling. 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: Donnerstag, 13. Mai 2021 09:52 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Commit 4710 I kinda feel by default even oneway=yes should only mean do not change direction for level 0. If someone uses a style to have arrows showing the oneway, then only for that arrow line (defined by tag) the direction cannot be reversed. Yes the problem of DP filter rests - I feel this does not matter for resolution 24 and even 23, but if you display arrows for resolution 22 or higher then a tag should not merge the underlying lines. Besides rivers (then also many styles do not have an arrow for rivers, or you could decide to show the arrows only at resolution 24 and 23) few lines will be objection dependent. I will try out now if there is any change in routing - but I will only write again if there unexpectedly is. The sharp angles changed routing for the better for my maps by quite a lot. So maybe with now some less lines being merged, there actually will be a little change for the worse back to the old behavior. Not sure.. On Thu, 13 May 2021 at 14:07, Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>> wrote: Hi Felix, yes, size increases if your style sets mkgmap:has-direction=true. I just want to make sure that the direction flag is treated correctly first. As already discussed we might introduce a new option or tag to tell mkgmap the min. level at which the direction has to be kept. You suggested to ignore direction at level > 0, I think it might depend on the style and TYP. I'll play with the OFM style to find out more. The change should not affect routing at all (none of the changes in the low-res-opt branch should). 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: Donnerstag, 13. Mai 2021 02:59 An: Development list for mkgmap Betreff: [mkgmap-dev] Commit 4710 fix error in LineMergeFilter reg. lines with direction The line merger should not merge lines if one has the direction flag set and the other has not. Problem exists also in trunk. Hmm fixing this stopped all the nice size optimization. Map size got much bigger again. I did not find any place where this mattered. Routing was also not affected badly. Maybe I did not look good enough? I do not see why not to merge them. As long as it`s not the opposite it seems fine... Map size increase/decrease is around 1.5% with my style. So thats quite a big difference. -- 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 _______________________________________________ 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
I tried 4713 current on branch Vs before the updates 12.05 on branch On Thu, 13 May 2021, 17:42 Gerd Petermann <gpetermann_muenchen@hotmail.com> wrote:
Hi Felix,
please tell me exactly which versions you tested reg. routing. Note that the branches do not yet contain the latest changes in trunk.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver@gmail.com> Gesendet: Donnerstag, 13. Mai 2021 11:28 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Commit 4710
Well I just got to test routing - and the current version is a degradation vs the intermediate version from yesterday for my maps. The current version routes better than before, but worse than the intermediate version.
As for the list - it is a bit more complicated inside the style but doable. I really do not know what happens to those ways where I first set a direction for an downhill only way with higher priority, then remove the direction for a way that can be used in both directions at lower priority. Maybe sometimes also doing this the other way around. A list with type and max resolution used would be much easier for writing your style. Instead of adding 60-100 lines with the filter it would be done with 10 or so. Canals should not have a direction, they do not flow. Sidewalk=left, right is the same as for the various cylceway,cycletrack options - those are really not reversible. The underlying way could be reversed however - and I guess they are only used for level 0. Oneway arrows for streets are maybe used from resoltuion 24-22 or 24 only. Cliffs are also only high resolution. For me rivers are the only thing which really go into lower resolutions.
On Thu, 13 May 2021 at 16:03, Gerd Petermann < gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>> wrote: Hi Felix,
FYI: I just found out that the current code to detect if the style sets mkgmap:has-direction=true doesn't work. Seems I didn't test this :( The change in r4710 changed only the LineMerger in the branch. Even with r4711 LineMerger only merges roads in maps without NET, at least that's what's intended.
My understanding is that r4703 changed routing, possibly also r4704. The merge from trunk also changed routing in the branches (r4706 and r4707).
I'm now fixing the detection code, next I'm trying to figure out how to configure the details reg. direction handling.
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: Donnerstag, 13. Mai 2021 09:52 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Commit 4710
I kinda feel by default even oneway=yes should only mean do not change direction for level 0. If someone uses a style to have arrows showing the oneway, then only for that arrow line (defined by tag) the direction cannot be reversed. Yes the problem of DP filter rests - I feel this does not matter for resolution 24 and even 23, but if you display arrows for resolution 22 or higher then a tag should not merge the underlying lines. Besides rivers (then also many styles do not have an arrow for rivers, or you could decide to show the arrows only at resolution 24 and 23) few lines will be objection dependent.
I will try out now if there is any change in routing - but I will only write again if there unexpectedly is. The sharp angles changed routing for the better for my maps by quite a lot. So maybe with now some less lines being merged, there actually will be a little change for the worse back to the old behavior. Not sure..
On Thu, 13 May 2021 at 14:07, Gerd Petermann < gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com
<mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com>>> wrote: Hi Felix,
yes, size increases if your style sets mkgmap:has-direction=true. I just want to make sure that the direction flag is treated correctly first. As already discussed we might introduce a new option or tag to tell mkgmap the min. level at which the direction has to be kept. You suggested to ignore direction at level > 0, I think it might depend on the style and TYP. I'll play with the OFM style to find out more.
The change should not affect routing at all (none of the changes in the low-res-opt branch should).
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: Donnerstag, 13. Mai 2021 02:59 An: Development list for mkgmap Betreff: [mkgmap-dev] Commit 4710
fix error in LineMergeFilter reg. lines with direction The line merger should not merge lines if one has the direction flag set and the other has not. Problem exists also in trunk.
Hmm fixing this stopped all the nice size optimization. Map size got much bigger again. I did not find any place where this mattered. Routing was also not affected badly. Maybe I did not look good enough?
I do not see why not to merge them. As long as it`s not the opposite it seems fine... Map size increase/decrease is around 1.5% with my style. So thats quite a big difference. -- 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
_______________________________________________ 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
I just looked it up. It must have been 4709 with best routing for me (unlikely but maybe it could have been 4708), while 4711 is a bit worse (but better than before the first changes that made an impact on routing). Both from low-res-opt branch. I haven't tried trunk for quite a while. On Thu, 13 May 2021 at 17:42, Gerd Petermann < gpetermann_muenchen@hotmail.com> wrote:
Hi Felix,
please tell me exactly which versions you tested reg. routing. Note that the branches do not yet contain the latest changes in trunk.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver@gmail.com> Gesendet: Donnerstag, 13. Mai 2021 11:28 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Commit 4710
Well I just got to test routing - and the current version is a degradation vs the intermediate version from yesterday for my maps. The current version routes better than before, but worse than the intermediate version.
As for the list - it is a bit more complicated inside the style but doable. I really do not know what happens to those ways where I first set a direction for an downhill only way with higher priority, then remove the direction for a way that can be used in both directions at lower priority. Maybe sometimes also doing this the other way around. A list with type and max resolution used would be much easier for writing your style. Instead of adding 60-100 lines with the filter it would be done with 10 or so. Canals should not have a direction, they do not flow. Sidewalk=left, right is the same as for the various cylceway,cycletrack options - those are really not reversible. The underlying way could be reversed however - and I guess they are only used for level 0. Oneway arrows for streets are maybe used from resoltuion 24-22 or 24 only. Cliffs are also only high resolution. For me rivers are the only thing which really go into lower resolutions.
On Thu, 13 May 2021 at 16:03, Gerd Petermann < gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>> wrote: Hi Felix,
FYI: I just found out that the current code to detect if the style sets mkgmap:has-direction=true doesn't work. Seems I didn't test this :( The change in r4710 changed only the LineMerger in the branch. Even with r4711 LineMerger only merges roads in maps without NET, at least that's what's intended.
My understanding is that r4703 changed routing, possibly also r4704. The merge from trunk also changed routing in the branches (r4706 and r4707).
I'm now fixing the detection code, next I'm trying to figure out how to configure the details reg. direction handling.
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: Donnerstag, 13. Mai 2021 09:52 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Commit 4710
I kinda feel by default even oneway=yes should only mean do not change direction for level 0. If someone uses a style to have arrows showing the oneway, then only for that arrow line (defined by tag) the direction cannot be reversed. Yes the problem of DP filter rests - I feel this does not matter for resolution 24 and even 23, but if you display arrows for resolution 22 or higher then a tag should not merge the underlying lines. Besides rivers (then also many styles do not have an arrow for rivers, or you could decide to show the arrows only at resolution 24 and 23) few lines will be objection dependent.
I will try out now if there is any change in routing - but I will only write again if there unexpectedly is. The sharp angles changed routing for the better for my maps by quite a lot. So maybe with now some less lines being merged, there actually will be a little change for the worse back to the old behavior. Not sure..
On Thu, 13 May 2021 at 14:07, Gerd Petermann < gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com
<mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com>>> wrote: Hi Felix,
yes, size increases if your style sets mkgmap:has-direction=true. I just want to make sure that the direction flag is treated correctly first. As already discussed we might introduce a new option or tag to tell mkgmap the min. level at which the direction has to be kept. You suggested to ignore direction at level > 0, I think it might depend on the style and TYP. I'll play with the OFM style to find out more.
The change should not affect routing at all (none of the changes in the low-res-opt branch should).
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: Donnerstag, 13. Mai 2021 02:59 An: Development list for mkgmap Betreff: [mkgmap-dev] Commit 4710
fix error in LineMergeFilter reg. lines with direction The line merger should not merge lines if one has the direction flag set and the other has not. Problem exists also in trunk.
Hmm fixing this stopped all the nice size optimization. Map size got much bigger again. I did not find any place where this mattered. Routing was also not affected badly. Maybe I did not look good enough?
I do not see why not to merge them. As long as it`s not the opposite it seems fine... Map size increase/decrease is around 1.5% with my style. So thats quite a big difference. -- 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
_______________________________________________ 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, you totally lost me. There is no version r4713 in the branch. It seems you report the version number that svn shows after an svn update? That's not relevant, you must use svn info to find out the version of your branch. svn update always shows the latest commit, no matter in what branch it was made. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver@gmail.com> Gesendet: Donnerstag, 13. Mai 2021 13:16 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Commit 4710 I just looked it up. It must have been 4709 with best routing for me (unlikely but maybe it could have been 4708), while 4711 is a bit worse (but better than before the first changes that made an impact on routing). Both from low-res-opt branch. I haven't tried trunk for quite a while. On Thu, 13 May 2021 at 17:42, Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>> wrote: Hi Felix, please tell me exactly which versions you tested reg. routing. Note that the branches do not yet contain the latest changes in trunk. 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: Donnerstag, 13. Mai 2021 11:28 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Commit 4710 Well I just got to test routing - and the current version is a degradation vs the intermediate version from yesterday for my maps. The current version routes better than before, but worse than the intermediate version. As for the list - it is a bit more complicated inside the style but doable. I really do not know what happens to those ways where I first set a direction for an downhill only way with higher priority, then remove the direction for a way that can be used in both directions at lower priority. Maybe sometimes also doing this the other way around. A list with type and max resolution used would be much easier for writing your style. Instead of adding 60-100 lines with the filter it would be done with 10 or so. Canals should not have a direction, they do not flow. Sidewalk=left, right is the same as for the various cylceway,cycletrack options - those are really not reversible. The underlying way could be reversed however - and I guess they are only used for level 0. Oneway arrows for streets are maybe used from resoltuion 24-22 or 24 only. Cliffs are also only high resolution. For me rivers are the only thing which really go into lower resolutions. On Thu, 13 May 2021 at 16:03, Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>> wrote: Hi Felix, FYI: I just found out that the current code to detect if the style sets mkgmap:has-direction=true doesn't work. Seems I didn't test this :( The change in r4710 changed only the LineMerger in the branch. Even with r4711 LineMerger only merges roads in maps without NET, at least that's what's intended. My understanding is that r4703 changed routing, possibly also r4704. The merge from trunk also changed routing in the branches (r4706 and r4707). I'm now fixing the detection code, next I'm trying to figure out how to configure the details reg. direction handling. 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: Donnerstag, 13. Mai 2021 09:52 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Commit 4710 I kinda feel by default even oneway=yes should only mean do not change direction for level 0. If someone uses a style to have arrows showing the oneway, then only for that arrow line (defined by tag) the direction cannot be reversed. Yes the problem of DP filter rests - I feel this does not matter for resolution 24 and even 23, but if you display arrows for resolution 22 or higher then a tag should not merge the underlying lines. Besides rivers (then also many styles do not have an arrow for rivers, or you could decide to show the arrows only at resolution 24 and 23) few lines will be objection dependent. I will try out now if there is any change in routing - but I will only write again if there unexpectedly is. The sharp angles changed routing for the better for my maps by quite a lot. So maybe with now some less lines being merged, there actually will be a little change for the worse back to the old behavior. Not sure.. On Thu, 13 May 2021 at 14:07, Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>> wrote: Hi Felix, yes, size increases if your style sets mkgmap:has-direction=true. I just want to make sure that the direction flag is treated correctly first. As already discussed we might introduce a new option or tag to tell mkgmap the min. level at which the direction has to be kept. You suggested to ignore direction at level > 0, I think it might depend on the style and TYP. I'll play with the OFM style to find out more. The change should not affect routing at all (none of the changes in the low-res-opt branch should). 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>><mailto: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>><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>>> Gesendet: Donnerstag, 13. Mai 2021 02:59 An: Development list for mkgmap Betreff: [mkgmap-dev] Commit 4710 fix error in LineMergeFilter reg. lines with direction The line merger should not merge lines if one has the direction flag set and the other has not. Problem exists also in trunk. Hmm fixing this stopped all the nice size optimization. Map size got much bigger again. I did not find any place where this mattered. Routing was also not affected badly. Maybe I did not look good enough? I do not see why not to merge them. As long as it`s not the opposite it seems fine... Map size increase/decrease is around 1.5% with my style. So thats quite a big difference. -- 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>><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 _______________________________________________ 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 _______________________________________________ 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
Yes, 4711 on branch vs best version 4709 on branch. 4709 was best so far. On Thu, 13 May 2021, 19:37 Gerd Petermann <gpetermann_muenchen@hotmail.com> wrote:
Hi Felix,
you totally lost me. There is no version r4713 in the branch. It seems you report the version number that svn shows after an svn update? That's not relevant, you must use svn info to find out the version of your branch. svn update always shows the latest commit, no matter in what branch it was made.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver@gmail.com> Gesendet: Donnerstag, 13. Mai 2021 13:16 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Commit 4710
I just looked it up. It must have been 4709 with best routing for me (unlikely but maybe it could have been 4708), while 4711 is a bit worse (but better than before the first changes that made an impact on routing). Both from low-res-opt branch. I haven't tried trunk for quite a while.
On Thu, 13 May 2021 at 17:42, Gerd Petermann < gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>> wrote: Hi Felix,
please tell me exactly which versions you tested reg. routing. Note that the branches do not yet contain the latest changes in trunk.
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: Donnerstag, 13. Mai 2021 11:28 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Commit 4710
Well I just got to test routing - and the current version is a degradation vs the intermediate version from yesterday for my maps. The current version routes better than before, but worse than the intermediate version.
As for the list - it is a bit more complicated inside the style but doable. I really do not know what happens to those ways where I first set a direction for an downhill only way with higher priority, then remove the direction for a way that can be used in both directions at lower priority. Maybe sometimes also doing this the other way around. A list with type and max resolution used would be much easier for writing your style. Instead of adding 60-100 lines with the filter it would be done with 10 or so. Canals should not have a direction, they do not flow. Sidewalk=left, right is the same as for the various cylceway,cycletrack options - those are really not reversible. The underlying way could be reversed however - and I guess they are only used for level 0. Oneway arrows for streets are maybe used from resoltuion 24-22 or 24 only. Cliffs are also only high resolution. For me rivers are the only thing which really go into lower resolutions.
On Thu, 13 May 2021 at 16:03, Gerd Petermann < gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com
<mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com>>> wrote: Hi Felix,
FYI: I just found out that the current code to detect if the style sets mkgmap:has-direction=true doesn't work. Seems I didn't test this :( The change in r4710 changed only the LineMerger in the branch. Even with r4711 LineMerger only merges roads in maps without NET, at least that's what's intended.
My understanding is that r4703 changed routing, possibly also r4704. The merge from trunk also changed routing in the branches (r4706 and r4707).
I'm now fixing the detection code, next I'm trying to figure out how to configure the details reg. direction handling.
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: Donnerstag, 13. Mai 2021 09:52 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Commit 4710
I kinda feel by default even oneway=yes should only mean do not change direction for level 0. If someone uses a style to have arrows showing the oneway, then only for that arrow line (defined by tag) the direction cannot be reversed. Yes the problem of DP filter rests - I feel this does not matter for resolution 24 and even 23, but if you display arrows for resolution 22 or higher then a tag should not merge the underlying lines. Besides rivers (then also many styles do not have an arrow for rivers, or you could decide to show the arrows only at resolution 24 and 23) few lines will be objection dependent.
I will try out now if there is any change in routing - but I will only write again if there unexpectedly is. The sharp angles changed routing for the better for my maps by quite a lot. So maybe with now some less lines being merged, there actually will be a little change for the worse back to the old behavior. Not sure..
On Thu, 13 May 2021 at 14:07, Gerd Petermann < gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com
<mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com><mailto: gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>> wrote: Hi Felix,
yes, size increases if your style sets mkgmap:has-direction=true. I just want to make sure that the direction flag is treated correctly first. As already discussed we might introduce a new option or tag to tell mkgmap the min. level at which the direction has to be kept. You suggested to ignore direction at level > 0, I think it might depend on the style and TYP. I'll play with the OFM style to find out more.
The change should not affect routing at all (none of the changes in the low-res-opt branch should).
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>><mailto: 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>><mailto: extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto: extremecarver@gmail.com<mailto:extremecarver@gmail.com>>>> Gesendet: Donnerstag, 13. Mai 2021 02:59 An: Development list for mkgmap Betreff: [mkgmap-dev] Commit 4710
fix error in LineMergeFilter reg. lines with direction The line merger should not merge lines if one has the direction flag set and the other has not. Problem exists also in trunk.
Hmm fixing this stopped all the nice size optimization. Map size got much bigger again. I did not find any place where this mattered. Routing was also not affected badly. Maybe I did not look good enough?
I do not see why not to merge them. As long as it`s not the opposite it seems fine... Map size increase/decrease is around 1.5% with my style. So thats quite a big difference. -- 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>><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
_______________________________________________ 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
_______________________________________________ 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
Hi Felix, are you sure that you tested the two versions with exactly the same input? (osm data, style, options)? If the changes in r4710 or r4711 really cause differences in routing quality there must be an error, either in my understanding or in the code. Maybe you can post links to two tiles where routing differs? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver@gmail.com> Gesendet: Donnerstag, 13. Mai 2021 14:24 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Commit 4710 Yes, 4711 on branch vs best version 4709 on branch. 4709 was best so far. On Thu, 13 May 2021, 19:37 Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>> wrote: Hi Felix, you totally lost me. There is no version r4713 in the branch. It seems you report the version number that svn shows after an svn update? That's not relevant, you must use svn info to find out the version of your branch. svn update always shows the latest commit, no matter in what branch it was made. 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: Donnerstag, 13. Mai 2021 13:16 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Commit 4710 I just looked it up. It must have been 4709 with best routing for me (unlikely but maybe it could have been 4708), while 4711 is a bit worse (but better than before the first changes that made an impact on routing). Both from low-res-opt branch. I haven't tried trunk for quite a while. On Thu, 13 May 2021 at 17:42, Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>> wrote: Hi Felix, please tell me exactly which versions you tested reg. routing. Note that the branches do not yet contain the latest changes in trunk. 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: Donnerstag, 13. Mai 2021 11:28 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Commit 4710 Well I just got to test routing - and the current version is a degradation vs the intermediate version from yesterday for my maps. The current version routes better than before, but worse than the intermediate version. As for the list - it is a bit more complicated inside the style but doable. I really do not know what happens to those ways where I first set a direction for an downhill only way with higher priority, then remove the direction for a way that can be used in both directions at lower priority. Maybe sometimes also doing this the other way around. A list with type and max resolution used would be much easier for writing your style. Instead of adding 60-100 lines with the filter it would be done with 10 or so. Canals should not have a direction, they do not flow. Sidewalk=left, right is the same as for the various cylceway,cycletrack options - those are really not reversible. The underlying way could be reversed however - and I guess they are only used for level 0. Oneway arrows for streets are maybe used from resoltuion 24-22 or 24 only. Cliffs are also only high resolution. For me rivers are the only thing which really go into lower resolutions. On Thu, 13 May 2021 at 16:03, Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>> wrote: Hi Felix, FYI: I just found out that the current code to detect if the style sets mkgmap:has-direction=true doesn't work. Seems I didn't test this :( The change in r4710 changed only the LineMerger in the branch. Even with r4711 LineMerger only merges roads in maps without NET, at least that's what's intended. My understanding is that r4703 changed routing, possibly also r4704. The merge from trunk also changed routing in the branches (r4706 and r4707). I'm now fixing the detection code, next I'm trying to figure out how to configure the details reg. direction handling. 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>><mailto: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>><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>>> Gesendet: Donnerstag, 13. Mai 2021 09:52 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Commit 4710 I kinda feel by default even oneway=yes should only mean do not change direction for level 0. If someone uses a style to have arrows showing the oneway, then only for that arrow line (defined by tag) the direction cannot be reversed. Yes the problem of DP filter rests - I feel this does not matter for resolution 24 and even 23, but if you display arrows for resolution 22 or higher then a tag should not merge the underlying lines. Besides rivers (then also many styles do not have an arrow for rivers, or you could decide to show the arrows only at resolution 24 and 23) few lines will be objection dependent. I will try out now if there is any change in routing - but I will only write again if there unexpectedly is. The sharp angles changed routing for the better for my maps by quite a lot. So maybe with now some less lines being merged, there actually will be a little change for the worse back to the old behavior. Not sure.. On Thu, 13 May 2021 at 14:07, Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>>> wrote: Hi Felix, yes, size increases if your style sets mkgmap:has-direction=true. I just want to make sure that the direction flag is treated correctly first. As already discussed we might introduce a new option or tag to tell mkgmap the min. level at which the direction has to be kept. You suggested to ignore direction at level > 0, I think it might depend on the style and TYP. I'll play with the OFM style to find out more. The change should not affect routing at all (none of the changes in the low-res-opt branch should). 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>><mailto: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>>><mailto: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>><mailto: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>><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<mailto:extremecarver@gmail.com>><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>>>> Gesendet: Donnerstag, 13. Mai 2021 02:59 An: Development list for mkgmap Betreff: [mkgmap-dev] Commit 4710 fix error in LineMergeFilter reg. lines with direction The line merger should not merge lines if one has the direction flag set and the other has not. Problem exists also in trunk. Hmm fixing this stopped all the nice size optimization. Map size got much bigger again. I did not find any place where this mattered. Routing was also not affected badly. Maybe I did not look good enough? I do not see why not to merge them. As long as it`s not the opposite it seems fine... Map size increase/decrease is around 1.5% with my style. So thats quite a big difference. -- 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>><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<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 _______________________________________________ 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 _______________________________________________ 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 _______________________________________________ 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
Hi all, I fear I've totally forgotten the case of extended line types. I think the current code doesn't write the direction flag for them and I don't know if they can have a direction. Gerd ________________________________________ Von: Gerd Petermann <gpetermann_muenchen@hotmail.com> Gesendet: Donnerstag, 13. Mai 2021 14:33 An: Development list for mkgmap Betreff: AW: [mkgmap-dev] Commit 4710 Hi Felix, are you sure that you tested the two versions with exactly the same input? (osm data, style, options)? If the changes in r4710 or r4711 really cause differences in routing quality there must be an error, either in my understanding or in the code. Maybe you can post links to two tiles where routing differs? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver@gmail.com> Gesendet: Donnerstag, 13. Mai 2021 14:24 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Commit 4710 Yes, 4711 on branch vs best version 4709 on branch. 4709 was best so far. On Thu, 13 May 2021, 19:37 Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>> wrote: Hi Felix, you totally lost me. There is no version r4713 in the branch. It seems you report the version number that svn shows after an svn update? That's not relevant, you must use svn info to find out the version of your branch. svn update always shows the latest commit, no matter in what branch it was made. 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: Donnerstag, 13. Mai 2021 13:16 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Commit 4710 I just looked it up. It must have been 4709 with best routing for me (unlikely but maybe it could have been 4708), while 4711 is a bit worse (but better than before the first changes that made an impact on routing). Both from low-res-opt branch. I haven't tried trunk for quite a while. On Thu, 13 May 2021 at 17:42, Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>> wrote: Hi Felix, please tell me exactly which versions you tested reg. routing. Note that the branches do not yet contain the latest changes in trunk. 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: Donnerstag, 13. Mai 2021 11:28 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Commit 4710 Well I just got to test routing - and the current version is a degradation vs the intermediate version from yesterday for my maps. The current version routes better than before, but worse than the intermediate version. As for the list - it is a bit more complicated inside the style but doable. I really do not know what happens to those ways where I first set a direction for an downhill only way with higher priority, then remove the direction for a way that can be used in both directions at lower priority. Maybe sometimes also doing this the other way around. A list with type and max resolution used would be much easier for writing your style. Instead of adding 60-100 lines with the filter it would be done with 10 or so. Canals should not have a direction, they do not flow. Sidewalk=left, right is the same as for the various cylceway,cycletrack options - those are really not reversible. The underlying way could be reversed however - and I guess they are only used for level 0. Oneway arrows for streets are maybe used from resoltuion 24-22 or 24 only. Cliffs are also only high resolution. For me rivers are the only thing which really go into lower resolutions. On Thu, 13 May 2021 at 16:03, Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>> wrote: Hi Felix, FYI: I just found out that the current code to detect if the style sets mkgmap:has-direction=true doesn't work. Seems I didn't test this :( The change in r4710 changed only the LineMerger in the branch. Even with r4711 LineMerger only merges roads in maps without NET, at least that's what's intended. My understanding is that r4703 changed routing, possibly also r4704. The merge from trunk also changed routing in the branches (r4706 and r4707). I'm now fixing the detection code, next I'm trying to figure out how to configure the details reg. direction handling. 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>><mailto: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>><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>>> Gesendet: Donnerstag, 13. Mai 2021 09:52 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Commit 4710 I kinda feel by default even oneway=yes should only mean do not change direction for level 0. If someone uses a style to have arrows showing the oneway, then only for that arrow line (defined by tag) the direction cannot be reversed. Yes the problem of DP filter rests - I feel this does not matter for resolution 24 and even 23, but if you display arrows for resolution 22 or higher then a tag should not merge the underlying lines. Besides rivers (then also many styles do not have an arrow for rivers, or you could decide to show the arrows only at resolution 24 and 23) few lines will be objection dependent. I will try out now if there is any change in routing - but I will only write again if there unexpectedly is. The sharp angles changed routing for the better for my maps by quite a lot. So maybe with now some less lines being merged, there actually will be a little change for the worse back to the old behavior. Not sure.. On Thu, 13 May 2021 at 14:07, Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>>> wrote: Hi Felix, yes, size increases if your style sets mkgmap:has-direction=true. I just want to make sure that the direction flag is treated correctly first. As already discussed we might introduce a new option or tag to tell mkgmap the min. level at which the direction has to be kept. You suggested to ignore direction at level > 0, I think it might depend on the style and TYP. I'll play with the OFM style to find out more. The change should not affect routing at all (none of the changes in the low-res-opt branch should). 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>><mailto: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>>><mailto: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>><mailto: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>><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<mailto:extremecarver@gmail.com>><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>>>> Gesendet: Donnerstag, 13. Mai 2021 02:59 An: Development list for mkgmap Betreff: [mkgmap-dev] Commit 4710 fix error in LineMergeFilter reg. lines with direction The line merger should not merge lines if one has the direction flag set and the other has not. Problem exists also in trunk. Hmm fixing this stopped all the nice size optimization. Map size got much bigger again. I did not find any place where this mattered. Routing was also not affected badly. Maybe I did not look good enough? I do not see why not to merge them. As long as it`s not the opposite it seems fine... Map size increase/decrease is around 1.5% with my style. So thats quite a big difference. -- 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>><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<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 _______________________________________________ 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 _______________________________________________ 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 _______________________________________________ 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
Hi Gerd, I don't know particulars about direction flag, that is written into img. Maybe it gives some kind of protection against drawing a line in revers direction? Would be nice to test, if it were possible. Anyway, for me problem is about reversing a line by mkgmap. I think that attribute, which prevents mkgmap from doing it, is necessary to control line merging. -- Best regards, Andrzej
Hi Andrzej, not sure what you mean. There are three ways to tell mkgmap that a line has a direction: 1) oneway=yes / oneway=-1 2) in polish (*.mp) format there is DirIndicator 3) mkgmap:has-direction=true (since r4703) The flag is only written for lines with normal type, but maybe extended types also have a bit for that. Even the bit (0x40) might be the same. A special case occurs with the overview map. The OverviewBuilder ignored the flag, I fixed that only in the low-res-opt branch, see https://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4697 I don't know how or if Garmin software uses the flag with non-routable lines, GpsMapEdit shows an arrow. For a long time mkgmap reverses lines with oneway=-1 (after style processing), because Garmin only has yes/no flag. Does that help? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Andrzej Popowski <popej@poczta.onet.pl> Gesendet: Donnerstag, 13. Mai 2021 17:03 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] Commit 4710 Hi Gerd, I don't know particulars about direction flag, that is written into img. Maybe it gives some kind of protection against drawing a line in revers direction? Would be nice to test, if it were possible. Anyway, for me problem is about reversing a line by mkgmap. I think that attribute, which prevents mkgmap from doing it, is necessary to control line merging. -- Best regards, Andrzej _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd, it is clear, but I was thinking about something else, about merging lines with reversed points. If mkgmap performs that kind of merging, there should be an option to block reversing for a particular object type. I got impression, that mkgmap:has-direction is a flag, that can be used. -- Best regards, Andrzej
Hi Andrzej, yes, sure, the tag mkgmap:has-direction=true was only implemented for that. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Andrzej Popowski <popej@poczta.onet.pl> Gesendet: Donnerstag, 13. Mai 2021 19:36 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] Commit 4710 Hi Gerd, it is clear, but I was thinking about something else, about merging lines with reversed points. If mkgmap performs that kind of merging, there should be an option to block reversing for a particular object type. I got impression, that mkgmap:has-direction is a flag, that can be used. -- Best regards, Andrzej _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd, here example of lines, that shouldn't be merged: https://www.openstreetmap.org/way/481106241 https://www.openstreetmap.org/way/481106244 https://www.openstreetmap.org/way/481106242 I have tested with mkgmap-low-res-opt-r4711 and it works correctly. Lines are not merged with mkgmap:has-direction=true and merged without. -- Best regards, Andrzej
Hi Various thoughts: The 0x40 polyLine direction flag probably has no effect on modern Garmin devices. As Gerd says, GPSMapEdit puts an arrow on lines if it is set. In my notes from testing all line types, I found some cases where an eTrex put compass bearings (N/NE/E/...) on some line types where the top byte was 0x5 (ie this flag was set), so modifying the meaning line types 0x10 to 0x1f. I think they looked like 0x01 to 0x0f but with the compass label. I'll have a go at reproducing this - it was a while ago, I had to hack some mkgmap code, and I can't remember which device it was. Using the existing direction flag logic is overloading it; there is no reason why another flag couldn't be introduced to inhibits line reversal in attempts to merge. However, as the flag is already there, seems to have correct meaning, doesn't have any known harmful effects and might, possibly, be accessible to the TYP representation, then there are many advantages in using it. I notice an old posting by Andrzej saying one-way arrows are displayed on some devices by default when no TYP graphics. @Andrzej - do you have more details about this? An option should allow the default setting of this flag per line Type. It would be expected to be set for the types used for rivers, streams, embankments, coastline.... The style/TYP author is responsible for this. It could be one of the options allowed in style/options. The oneway tag sets it, and it can also be set/cleared with mkgmap:has -direction=yes/no. Should mkgmap:has-direction=no clear the flag if set by one-way? Yes, as long as reversal is also inhibited by oneway. I don't think there is any need for the style system to look for usages of this tag and change behaviour. Ticker
Hi Ticker and all, reg. tests of the 0x40 flag: Attached small patch would be my guess for the lines with extended type. The oneway attribute is stored in NOD and in the direction flag, I think that makes sense. The oneway=yes tag used to set the direction flag since more than 10 years (r738). I do agree now that an option in the style to list types with direction is the better approach, the tag handling is much more complex. The size effects of r4710 reported by Felix show that his style did not set the tag consistently for the same type and I think this can be really tricky. So, I think I'll remove the code for mkgmap:has-direction=true and add a new option to list the types which should be treated as having a direction, e.g. --line-types-with-direction=0x18,0x1f, 0x10005, 0x10006 . The oneway=yes/oneway=-1 tag will continue to set the direction flag. The default style might need some changes to distinguish waterways with direction from others, e.g. I think canals and rivers should have different types. I'll change the option --x-force-reverse-merge to --allow-reverse-merge with the default --allow-reverse-merge=no. These two options will effect RoadMerger and LineMerger. I've not yet made up my mind regarding the reversing of lines (and roads) in LineMerger for the overview map. Felix says there is no need to care about direction in the overvew map. I'll remove the code which tries to propagate the direction flag to underlying roads for now. Let's see first how often this is really needed. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Donnerstag, 13. Mai 2021 23:36 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Commit 4710 Hi Various thoughts: The 0x40 polyLine direction flag probably has no effect on modern Garmin devices. As Gerd says, GPSMapEdit puts an arrow on lines if it is set. In my notes from testing all line types, I found some cases where an eTrex put compass bearings (N/NE/E/...) on some line types where the top byte was 0x5 (ie this flag was set), so modifying the meaning line types 0x10 to 0x1f. I think they looked like 0x01 to 0x0f but with the compass label. I'll have a go at reproducing this - it was a while ago, I had to hack some mkgmap code, and I can't remember which device it was. Using the existing direction flag logic is overloading it; there is no reason why another flag couldn't be introduced to inhibits line reversal in attempts to merge. However, as the flag is already there, seems to have correct meaning, doesn't have any known harmful effects and might, possibly, be accessible to the TYP representation, then there are many advantages in using it. I notice an old posting by Andrzej saying one-way arrows are displayed on some devices by default when no TYP graphics. @Andrzej - do you have more details about this? An option should allow the default setting of this flag per line Type. It would be expected to be set for the types used for rivers, streams, embankments, coastline.... The style/TYP author is responsible for this. It could be one of the options allowed in style/options. The oneway tag sets it, and it can also be set/cleared with mkgmap:has -direction=yes/no. Should mkgmap:has-direction=no clear the flag if set by one-way? Yes, as long as reversal is also inhibited by oneway. I don't think there is any need for the style system to look for usages of this tag and change behaviour. Ticker _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd and others I'll test setting of 0x40 flag for extended and the range of standard types on various devices over the weekend. Is there any real need for the force/allow-reverse-merge options? When you say "remove the code for mkgmap:has-direction", I assume you mean just the style-scan of tags used, rather than inspecting it on a way after style conversion. Styles don't have to use different tags for river/canal once this is all implemented, can choose 1/ don't set the default direction for waterway type, or use mkgmap:has -direction in style and get current behaviour. 2/ default it to direction, clear it with mkgmap:direction=no when used as canal. This approach could be used if the device shows direction markers on rivers that we want to see. 3/ use distinct types and appropriate representation. I think it should be carried through into the overview img. For the dual-carriageway lane merging, I presume it should turn off direction (and one-way). Ticker On Fri, 2021-05-14 at 05:11 +0000, Gerd Petermann wrote:
Hi Ticker and all,
reg. tests of the 0x40 flag: Attached small patch would be my guess for the lines with extended type.
The oneway attribute is stored in NOD and in the direction flag, I think that makes sense. The oneway=yes tag used to set the direction flag since more than 10 years (r738).
I do agree now that an option in the style to list types with direction is the better approach, the tag handling is much more complex. The size effects of r4710 reported by Felix show that his style did not set the tag consistently for the same type and I think this can be really tricky. So, I think I'll remove the code for mkgmap:has-direction=true and add a new option to list the types which should be treated as having a direction, e.g. --line-types-with-direction=0x18,0x1f, 0x10005, 0x10006 . The oneway=yes/oneway=-1 tag will continue to set the direction flag. The default style might need some changes to distinguish waterways with direction from others, e.g. I think canals and rivers should have different types.
I'll change the option --x-force-reverse-merge to --allow-reverse -merge with the default --allow-reverse-merge=no. These two options will effect RoadMerger and LineMerger.
I've not yet made up my mind regarding the reversing of lines (and roads) in LineMerger for the overview map. Felix says there is no need to care about direction in the overvew map.
I'll remove the code which tries to propagate the direction flag to underlying roads for now. Let's see first how often this is really needed.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Donnerstag, 13. Mai 2021 23:36 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Commit 4710
Hi
Various thoughts:
The 0x40 polyLine direction flag probably has no effect on modern Garmin devices. As Gerd says, GPSMapEdit puts an arrow on lines if it is set. In my notes from testing all line types, I found some cases where an eTrex put compass bearings (N/NE/E/...) on some line types where the top byte was 0x5 (ie this flag was set), so modifying the meaning line types 0x10 to 0x1f. I think they looked like 0x01 to 0x0f but with the compass label.
I'll have a go at reproducing this - it was a while ago, I had to hack some mkgmap code, and I can't remember which device it was.
Using the existing direction flag logic is overloading it; there is no reason why another flag couldn't be introduced to inhibits line reversal in attempts to merge. However, as the flag is already there, seems to have correct meaning, doesn't have any known harmful effects and might, possibly, be accessible to the TYP representation, then there are many advantages in using it.
I notice an old posting by Andrzej saying one-way arrows are displayed on some devices by default when no TYP graphics. @Andrzej - do you have more details about this?
An option should allow the default setting of this flag per line Type. It would be expected to be set for the types used for rivers, streams, embankments, coastline.... The style/TYP author is responsible for this. It could be one of the options allowed in style/options.
The oneway tag sets it, and it can also be set/cleared with mkgmap:has -direction=yes/no. Should mkgmap:has-direction=no clear the flag if set by one-way? Yes, as long as reversal is also inhibited by oneway.
I don't think there is any need for the style system to look for usages of this tag and change behaviour.
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 meant I want to remove the evaluation of the special tag mkgmap:has-direction=true and only rely on the new option --line-types-with-direction Do you see a need to have both? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Freitag, 14. Mai 2021 09:22 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Commit 4710 Hi Gerd and others I'll test setting of 0x40 flag for extended and the range of standard types on various devices over the weekend. Is there any real need for the force/allow-reverse-merge options? When you say "remove the code for mkgmap:has-direction", I assume you mean just the style-scan of tags used, rather than inspecting it on a way after style conversion. Styles don't have to use different tags for river/canal once this is all implemented, can choose 1/ don't set the default direction for waterway type, or use mkgmap:has -direction in style and get current behaviour. 2/ default it to direction, clear it with mkgmap:direction=no when used as canal. This approach could be used if the device shows direction markers on rivers that we want to see. 3/ use distinct types and appropriate representation. I think it should be carried through into the overview img. For the dual-carriageway lane merging, I presume it should turn off direction (and one-way). Ticker On Fri, 2021-05-14 at 05:11 +0000, Gerd Petermann wrote:
Hi Ticker and all,
reg. tests of the 0x40 flag: Attached small patch would be my guess for the lines with extended type.
The oneway attribute is stored in NOD and in the direction flag, I think that makes sense. The oneway=yes tag used to set the direction flag since more than 10 years (r738).
I do agree now that an option in the style to list types with direction is the better approach, the tag handling is much more complex. The size effects of r4710 reported by Felix show that his style did not set the tag consistently for the same type and I think this can be really tricky. So, I think I'll remove the code for mkgmap:has-direction=true and add a new option to list the types which should be treated as having a direction, e.g. --line-types-with-direction=0x18,0x1f, 0x10005, 0x10006 . The oneway=yes/oneway=-1 tag will continue to set the direction flag. The default style might need some changes to distinguish waterways with direction from others, e.g. I think canals and rivers should have different types.
I'll change the option --x-force-reverse-merge to --allow-reverse -merge with the default --allow-reverse-merge=no. These two options will effect RoadMerger and LineMerger.
I've not yet made up my mind regarding the reversing of lines (and roads) in LineMerger for the overview map. Felix says there is no need to care about direction in the overvew map.
I'll remove the code which tries to propagate the direction flag to underlying roads for now. Let's see first how often this is really needed.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Donnerstag, 13. Mai 2021 23:36 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Commit 4710
Hi
Various thoughts:
The 0x40 polyLine direction flag probably has no effect on modern Garmin devices. As Gerd says, GPSMapEdit puts an arrow on lines if it is set. In my notes from testing all line types, I found some cases where an eTrex put compass bearings (N/NE/E/...) on some line types where the top byte was 0x5 (ie this flag was set), so modifying the meaning line types 0x10 to 0x1f. I think they looked like 0x01 to 0x0f but with the compass label.
I'll have a go at reproducing this - it was a while ago, I had to hack some mkgmap code, and I can't remember which device it was.
Using the existing direction flag logic is overloading it; there is no reason why another flag couldn't be introduced to inhibits line reversal in attempts to merge. However, as the flag is already there, seems to have correct meaning, doesn't have any known harmful effects and might, possibly, be accessible to the TYP representation, then there are many advantages in using it.
I notice an old posting by Andrzej saying one-way arrows are displayed on some devices by default when no TYP graphics. @Andrzej - do you have more details about this?
An option should allow the default setting of this flag per line Type. It would be expected to be set for the types used for rivers, streams, embankments, coastline.... The style/TYP author is responsible for this. It could be one of the options allowed in style/options.
The oneway tag sets it, and it can also be set/cleared with mkgmap:has -direction=yes/no. Should mkgmap:has-direction=no clear the flag if set by one-way? Yes, as long as reversal is also inhibited by oneway.
I don't think there is any need for the style system to look for usages of this tag and change behaviour.
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
I think it is enough with a simple list. As for why it changed for me is Imho because those lines are mostly created with continue or continue with action and it's really hard to see what happens concerning the other lines related to it. I definitely did not miss any lines in my lines file that should not be reversed. So make it a list, and option for each type other kines created with continue can change direction no, yes, from resolution XX or lower. That would be best. Gives it all options and you can set it how it works best. I still feel I will always use other lines can be reversed to be merged. On Fri, 14 May 2021, 15:32 Gerd Petermann <gpetermann_muenchen@hotmail.com> wrote:
Hi Ticker,
I meant I want to remove the evaluation of the special tag mkgmap:has-direction=true and only rely on the new option --line-types-with-direction
Do you see a need to have both?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Freitag, 14. Mai 2021 09:22 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Commit 4710
Hi Gerd and others
I'll test setting of 0x40 flag for extended and the range of standard types on various devices over the weekend.
Is there any real need for the force/allow-reverse-merge options?
When you say "remove the code for mkgmap:has-direction", I assume you mean just the style-scan of tags used, rather than inspecting it on a way after style conversion.
Styles don't have to use different tags for river/canal once this is all implemented, can choose 1/ don't set the default direction for waterway type, or use mkgmap:has -direction in style and get current behaviour. 2/ default it to direction, clear it with mkgmap:direction=no when used as canal. This approach could be used if the device shows direction markers on rivers that we want to see. 3/ use distinct types and appropriate representation.
I think it should be carried through into the overview img.
For the dual-carriageway lane merging, I presume it should turn off direction (and one-way).
Ticker
On Fri, 2021-05-14 at 05:11 +0000, Gerd Petermann wrote:
Hi Ticker and all,
reg. tests of the 0x40 flag: Attached small patch would be my guess for the lines with extended type.
The oneway attribute is stored in NOD and in the direction flag, I think that makes sense. The oneway=yes tag used to set the direction flag since more than 10 years (r738).
I do agree now that an option in the style to list types with direction is the better approach, the tag handling is much more complex. The size effects of r4710 reported by Felix show that his style did not set the tag consistently for the same type and I think this can be really tricky. So, I think I'll remove the code for mkgmap:has-direction=true and add a new option to list the types which should be treated as having a direction, e.g. --line-types-with-direction=0x18,0x1f, 0x10005, 0x10006 . The oneway=yes/oneway=-1 tag will continue to set the direction flag. The default style might need some changes to distinguish waterways with direction from others, e.g. I think canals and rivers should have different types.
I'll change the option --x-force-reverse-merge to --allow-reverse -merge with the default --allow-reverse-merge=no. These two options will effect RoadMerger and LineMerger.
I've not yet made up my mind regarding the reversing of lines (and roads) in LineMerger for the overview map. Felix says there is no need to care about direction in the overvew map.
I'll remove the code which tries to propagate the direction flag to underlying roads for now. Let's see first how often this is really needed.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Donnerstag, 13. Mai 2021 23:36 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Commit 4710
Hi
Various thoughts:
The 0x40 polyLine direction flag probably has no effect on modern Garmin devices. As Gerd says, GPSMapEdit puts an arrow on lines if it is set. In my notes from testing all line types, I found some cases where an eTrex put compass bearings (N/NE/E/...) on some line types where the top byte was 0x5 (ie this flag was set), so modifying the meaning line types 0x10 to 0x1f. I think they looked like 0x01 to 0x0f but with the compass label.
I'll have a go at reproducing this - it was a while ago, I had to hack some mkgmap code, and I can't remember which device it was.
Using the existing direction flag logic is overloading it; there is no reason why another flag couldn't be introduced to inhibits line reversal in attempts to merge. However, as the flag is already there, seems to have correct meaning, doesn't have any known harmful effects and might, possibly, be accessible to the TYP representation, then there are many advantages in using it.
I notice an old posting by Andrzej saying one-way arrows are displayed on some devices by default when no TYP graphics. @Andrzej - do you have more details about this?
An option should allow the default setting of this flag per line Type. It would be expected to be set for the types used for rivers, streams, embankments, coastline.... The style/TYP author is responsible for this. It could be one of the options allowed in style/options.
The oneway tag sets it, and it can also be set/cleared with mkgmap:has -direction=yes/no. Should mkgmap:has-direction=no clear the flag if set by one-way? Yes, as long as reversal is also inhibited by oneway.
I don't think there is any need for the style system to look for usages of this tag and change behaviour.
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 Felix, please explain in more detail. Why would you add a line with a type that has a direction to be rendered at low resolution when you don't care about the direction at lower resolutions? You say simple list is enough, but then "give all options". Quite confusing ;) I don't want to support different ways to specify a single bit unless there is a very good reason. If there is a good reason we need to define and document priorities and handle them properly. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver@gmail.com> Gesendet: Freitag, 14. Mai 2021 09:42 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Commit 4710 I think it is enough with a simple list. As for why it changed for me is Imho because those lines are mostly created with continue or continue with action and it's really hard to see what happens concerning the other lines related to it. I definitely did not miss any lines in my lines file that should not be reversed. So make it a list, and option for each type other kines created with continue can change direction no, yes, from resolution XX or lower. That would be best. Gives it all options and you can set it how it works best. I still feel I will always use other lines can be reversed to be merged. On Fri, 14 May 2021, 15:32 Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>> wrote: Hi Ticker, I meant I want to remove the evaluation of the special tag mkgmap:has-direction=true and only rely on the new option --line-types-with-direction Do you see a need to have both? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk>> Gesendet: Freitag, 14. Mai 2021 09:22 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Commit 4710 Hi Gerd and others I'll test setting of 0x40 flag for extended and the range of standard types on various devices over the weekend. Is there any real need for the force/allow-reverse-merge options? When you say "remove the code for mkgmap:has-direction", I assume you mean just the style-scan of tags used, rather than inspecting it on a way after style conversion. Styles don't have to use different tags for river/canal once this is all implemented, can choose 1/ don't set the default direction for waterway type, or use mkgmap:has -direction in style and get current behaviour. 2/ default it to direction, clear it with mkgmap:direction=no when used as canal. This approach could be used if the device shows direction markers on rivers that we want to see. 3/ use distinct types and appropriate representation. I think it should be carried through into the overview img. For the dual-carriageway lane merging, I presume it should turn off direction (and one-way). Ticker On Fri, 2021-05-14 at 05:11 +0000, Gerd Petermann wrote:
Hi Ticker and all,
reg. tests of the 0x40 flag: Attached small patch would be my guess for the lines with extended type.
The oneway attribute is stored in NOD and in the direction flag, I think that makes sense. The oneway=yes tag used to set the direction flag since more than 10 years (r738).
I do agree now that an option in the style to list types with direction is the better approach, the tag handling is much more complex. The size effects of r4710 reported by Felix show that his style did not set the tag consistently for the same type and I think this can be really tricky. So, I think I'll remove the code for mkgmap:has-direction=true and add a new option to list the types which should be treated as having a direction, e.g. --line-types-with-direction=0x18,0x1f, 0x10005, 0x10006 . The oneway=yes/oneway=-1 tag will continue to set the direction flag. The default style might need some changes to distinguish waterways with direction from others, e.g. I think canals and rivers should have different types.
I'll change the option --x-force-reverse-merge to --allow-reverse -merge with the default --allow-reverse-merge=no. These two options will effect RoadMerger and LineMerger.
I've not yet made up my mind regarding the reversing of lines (and roads) in LineMerger for the overview map. Felix says there is no need to care about direction in the overvew map.
I'll remove the code which tries to propagate the direction flag to underlying roads for now. Let's see first how often this is really needed.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk>> Gesendet: Donnerstag, 13. Mai 2021 23:36 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Commit 4710
Hi
Various thoughts:
The 0x40 polyLine direction flag probably has no effect on modern Garmin devices. As Gerd says, GPSMapEdit puts an arrow on lines if it is set. In my notes from testing all line types, I found some cases where an eTrex put compass bearings (N/NE/E/...) on some line types where the top byte was 0x5 (ie this flag was set), so modifying the meaning line types 0x10 to 0x1f. I think they looked like 0x01 to 0x0f but with the compass label.
I'll have a go at reproducing this - it was a while ago, I had to hack some mkgmap code, and I can't remember which device it was.
Using the existing direction flag logic is overloading it; there is no reason why another flag couldn't be introduced to inhibits line reversal in attempts to merge. However, as the flag is already there, seems to have correct meaning, doesn't have any known harmful effects and might, possibly, be accessible to the TYP representation, then there are many advantages in using it.
I notice an old posting by Andrzej saying one-way arrows are displayed on some devices by default when no TYP graphics. @Andrzej - do you have more details about this?
An option should allow the default setting of this flag per line Type. It would be expected to be set for the types used for rivers, streams, embankments, coastline.... The style/TYP author is responsible for this. It could be one of the options allowed in style/options.
The oneway tag sets it, and it can also be set/cleared with mkgmap:has -direction=yes/no. Should mkgmap:has-direction=no clear the flag if set by one-way? Yes, as long as reversal is also inhibited by oneway.
I don't think there is any need for the style system to look for usages of this tag and change behaviour.
Ticker
_______________________________________________ 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 _______________________________________________ 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
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 _______________________________________________ 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
Hi all, now I understand why the map got bigger with r4710 in the branch: The oneway tag is also also evaluated for non-routable lines and has the same effect as mkgmap:has-direction=true If a non-routable line has oneway=yes or oneway=-1 and another connected one has no oneway, they where possibly merged before r4710. I think it is correct to not merge them, but maybe we should ignore oneway=* for non-routable lines? Gerd ________________________________________ Von: Gerd Petermann <gpetermann_muenchen@hotmail.com> Gesendet: Freitag, 14. Mai 2021 09:59 An: Development list for mkgmap Betreff: AW: [mkgmap-dev] Commit 4710 Hi Felix, please explain in more detail. Why would you add a line with a type that has a direction to be rendered at low resolution when you don't care about the direction at lower resolutions? You say simple list is enough, but then "give all options". Quite confusing ;) I don't want to support different ways to specify a single bit unless there is a very good reason. If there is a good reason we need to define and document priorities and handle them properly. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver@gmail.com> Gesendet: Freitag, 14. Mai 2021 09:42 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Commit 4710 I think it is enough with a simple list. As for why it changed for me is Imho because those lines are mostly created with continue or continue with action and it's really hard to see what happens concerning the other lines related to it. I definitely did not miss any lines in my lines file that should not be reversed. So make it a list, and option for each type other kines created with continue can change direction no, yes, from resolution XX or lower. That would be best. Gives it all options and you can set it how it works best. I still feel I will always use other lines can be reversed to be merged. On Fri, 14 May 2021, 15:32 Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>> wrote: Hi Ticker, I meant I want to remove the evaluation of the special tag mkgmap:has-direction=true and only rely on the new option --line-types-with-direction Do you see a need to have both? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk>> Gesendet: Freitag, 14. Mai 2021 09:22 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Commit 4710 Hi Gerd and others I'll test setting of 0x40 flag for extended and the range of standard types on various devices over the weekend. Is there any real need for the force/allow-reverse-merge options? When you say "remove the code for mkgmap:has-direction", I assume you mean just the style-scan of tags used, rather than inspecting it on a way after style conversion. Styles don't have to use different tags for river/canal once this is all implemented, can choose 1/ don't set the default direction for waterway type, or use mkgmap:has -direction in style and get current behaviour. 2/ default it to direction, clear it with mkgmap:direction=no when used as canal. This approach could be used if the device shows direction markers on rivers that we want to see. 3/ use distinct types and appropriate representation. I think it should be carried through into the overview img. For the dual-carriageway lane merging, I presume it should turn off direction (and one-way). Ticker On Fri, 2021-05-14 at 05:11 +0000, Gerd Petermann wrote:
Hi Ticker and all,
reg. tests of the 0x40 flag: Attached small patch would be my guess for the lines with extended type.
The oneway attribute is stored in NOD and in the direction flag, I think that makes sense. The oneway=yes tag used to set the direction flag since more than 10 years (r738).
I do agree now that an option in the style to list types with direction is the better approach, the tag handling is much more complex. The size effects of r4710 reported by Felix show that his style did not set the tag consistently for the same type and I think this can be really tricky. So, I think I'll remove the code for mkgmap:has-direction=true and add a new option to list the types which should be treated as having a direction, e.g. --line-types-with-direction=0x18,0x1f, 0x10005, 0x10006 . The oneway=yes/oneway=-1 tag will continue to set the direction flag. The default style might need some changes to distinguish waterways with direction from others, e.g. I think canals and rivers should have different types.
I'll change the option --x-force-reverse-merge to --allow-reverse -merge with the default --allow-reverse-merge=no. These two options will effect RoadMerger and LineMerger.
I've not yet made up my mind regarding the reversing of lines (and roads) in LineMerger for the overview map. Felix says there is no need to care about direction in the overvew map.
I'll remove the code which tries to propagate the direction flag to underlying roads for now. Let's see first how often this is really needed.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk>> Gesendet: Donnerstag, 13. Mai 2021 23:36 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Commit 4710
Hi
Various thoughts:
The 0x40 polyLine direction flag probably has no effect on modern Garmin devices. As Gerd says, GPSMapEdit puts an arrow on lines if it is set. In my notes from testing all line types, I found some cases where an eTrex put compass bearings (N/NE/E/...) on some line types where the top byte was 0x5 (ie this flag was set), so modifying the meaning line types 0x10 to 0x1f. I think they looked like 0x01 to 0x0f but with the compass label.
I'll have a go at reproducing this - it was a while ago, I had to hack some mkgmap code, and I can't remember which device it was.
Using the existing direction flag logic is overloading it; there is no reason why another flag couldn't be introduced to inhibits line reversal in attempts to merge. However, as the flag is already there, seems to have correct meaning, doesn't have any known harmful effects and might, possibly, be accessible to the TYP representation, then there are many advantages in using it.
I notice an old posting by Andrzej saying one-way arrows are displayed on some devices by default when no TYP graphics. @Andrzej - do you have more details about this?
An option should allow the default setting of this flag per line Type. It would be expected to be set for the types used for rivers, streams, embankments, coastline.... The style/TYP author is responsible for this. It could be one of the options allowed in style/options.
The oneway tag sets it, and it can also be set/cleared with mkgmap:has -direction=yes/no. Should mkgmap:has-direction=no clear the flag if set by one-way? Yes, as long as reversal is also inhibited by oneway.
I don't think there is any need for the style system to look for usages of this tag and change behaviour.
Ticker
_______________________________________________ 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 _______________________________________________ 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
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 _______________________________________________ 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
*Hi all,now I understand why the map got bigger with r4710 in the branch: The oneway tag is also also evaluated for non-routable lines and has the same effect as mkgmap:has-direction=trueIf a non-routable line has oneway=yes or oneway=-1 and another connected one has no oneway, they where possibly merged before r4710.I think it is correct to not merge them, but maybe we should ignore oneway=* for non-routable lines?* Yes I think for non routable lines the oneway tag should be ignored. It will be easier and more correct than removing the oneway tag. Especially if there is a combined highway=street, railway=... for a road that is shared between cars and tramway for example (if you decide to show both railway and road in that case). On Fri, 14 May 2021 at 21:59, Gerd Petermann < gpetermann_muenchen@hotmail.com> wrote:
Hi all,
now I understand why the map got bigger with r4710 in the branch: The oneway tag is also also evaluated for non-routable lines and has the same effect as mkgmap:has-direction=true If a non-routable line has oneway=yes or oneway=-1 and another connected one has no oneway, they where possibly merged before r4710.
I think it is correct to not merge them, but maybe we should ignore oneway=* for non-routable lines?
Gerd
________________________________________ Von: Gerd Petermann <gpetermann_muenchen@hotmail.com> Gesendet: Freitag, 14. Mai 2021 09:59 An: Development list for mkgmap Betreff: AW: [mkgmap-dev] Commit 4710
Hi Felix,
please explain in more detail. Why would you add a line with a type that has a direction to be rendered at low resolution when you don't care about the direction at lower resolutions?
You say simple list is enough, but then "give all options". Quite confusing ;) I don't want to support different ways to specify a single bit unless there is a very good reason. If there is a good reason we need to define and document priorities and handle them properly.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver@gmail.com> Gesendet: Freitag, 14. Mai 2021 09:42 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Commit 4710
I think it is enough with a simple list. As for why it changed for me is Imho because those lines are mostly created with continue or continue with action and it's really hard to see what happens concerning the other lines related to it. I definitely did not miss any lines in my lines file that should not be reversed.
So make it a list, and option for each type other kines created with continue can change direction no, yes, from resolution XX or lower.
That would be best. Gives it all options and you can set it how it works best. I still feel I will always use other lines can be reversed to be merged.
On Fri, 14 May 2021, 15:32 Gerd Petermann <gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com>> wrote: Hi Ticker,
I meant I want to remove the evaluation of the special tag mkgmap:has-direction=true and only rely on the new option --line-types-with-direction
Do you see a need to have both?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag von Ticker Berkin < rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk>> Gesendet: Freitag, 14. Mai 2021 09:22 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Commit 4710
Hi Gerd and others
I'll test setting of 0x40 flag for extended and the range of standard types on various devices over the weekend.
Is there any real need for the force/allow-reverse-merge options?
When you say "remove the code for mkgmap:has-direction", I assume you mean just the style-scan of tags used, rather than inspecting it on a way after style conversion.
Styles don't have to use different tags for river/canal once this is all implemented, can choose 1/ don't set the default direction for waterway type, or use mkgmap:has -direction in style and get current behaviour. 2/ default it to direction, clear it with mkgmap:direction=no when used as canal. This approach could be used if the device shows direction markers on rivers that we want to see. 3/ use distinct types and appropriate representation.
I think it should be carried through into the overview img.
For the dual-carriageway lane merging, I presume it should turn off direction (and one-way).
Ticker
On Fri, 2021-05-14 at 05:11 +0000, Gerd Petermann wrote:
Hi Ticker and all,
reg. tests of the 0x40 flag: Attached small patch would be my guess for the lines with extended type.
The oneway attribute is stored in NOD and in the direction flag, I think that makes sense. The oneway=yes tag used to set the direction flag since more than 10 years (r738).
I do agree now that an option in the style to list types with direction is the better approach, the tag handling is much more complex. The size effects of r4710 reported by Felix show that his style did not set the tag consistently for the same type and I think this can be really tricky. So, I think I'll remove the code for mkgmap:has-direction=true and add a new option to list the types which should be treated as having a direction, e.g. --line-types-with-direction=0x18,0x1f, 0x10005, 0x10006 . The oneway=yes/oneway=-1 tag will continue to set the direction flag. The default style might need some changes to distinguish waterways with direction from others, e.g. I think canals and rivers should have different types.
I'll change the option --x-force-reverse-merge to --allow-reverse -merge with the default --allow-reverse-merge=no. These two options will effect RoadMerger and LineMerger.
I've not yet made up my mind regarding the reversing of lines (and roads) in LineMerger for the overview map. Felix says there is no need to care about direction in the overvew map.
I'll remove the code which tries to propagate the direction flag to underlying roads for now. Let's see first how often this is really needed.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk
Gesendet: Donnerstag, 13. Mai 2021 23:36 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Commit 4710
Hi
Various thoughts:
The 0x40 polyLine direction flag probably has no effect on modern Garmin devices. As Gerd says, GPSMapEdit puts an arrow on lines if it is set. In my notes from testing all line types, I found some cases where an eTrex put compass bearings (N/NE/E/...) on some line types where the top byte was 0x5 (ie this flag was set), so modifying the meaning line types 0x10 to 0x1f. I think they looked like 0x01 to 0x0f but with the compass label.
I'll have a go at reproducing this - it was a while ago, I had to hack some mkgmap code, and I can't remember which device it was.
Using the existing direction flag logic is overloading it; there is no reason why another flag couldn't be introduced to inhibits line reversal in attempts to merge. However, as the flag is already there, seems to have correct meaning, doesn't have any known harmful effects and might, possibly, be accessible to the TYP representation, then there are many advantages in using it.
I notice an old posting by Andrzej saying one-way arrows are displayed on some devices by default when no TYP graphics. @Andrzej - do you have more details about this?
An option should allow the default setting of this flag per line Type. It would be expected to be set for the types used for rivers, streams, embankments, coastline.... The style/TYP author is responsible for this. It could be one of the options allowed in style/options.
The oneway tag sets it, and it can also be set/cleared with mkgmap:has -direction=yes/no. Should mkgmap:has-direction=no clear the flag if set by one-way? Yes, as long as reversal is also inhibited by oneway.
I don't think there is any need for the style system to look for usages of this tag and change behaviour.
Ticker
_______________________________________________ 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 _______________________________________________ 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
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 _______________________________________________ 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 _______________________________________________ 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 I think better/more flexible to have both. Mainly for when there are a limited number of well defined garmin types for an element and some have direction and some don't, eg the various waterways, direction -merged motorways... However, if there is no way of distinguishing the difference in the final visible representation on any device then there isn't need. Ticker On Fri, 2021-05-14 at 15:42 +0800, Felix Hartmann wrote:
I think it is enough with a simple list. As for why it changed for me is Imho because those lines are mostly created with continue or continue with action and it's really hard to see what happens concerning the other lines related to it. I definitely did not miss any lines in my lines file that should not be reversed.
So make it a list, and option for each type other kines created with continue can change direction no, yes, from resolution XX or lower.
That would be best. Gives it all options and you can set it how it works best. I still feel I will always use other lines can be reversed to be merged.
On Fri, 14 May 2021, 15:32 Gerd Petermann < gpetermann_muenchen@hotmail.com> wrote:
Hi Ticker,
I meant I want to remove the evaluation of the special tag mkgmap:has-direction=true and only rely on the new option --line -types-with-direction
Do you see a need to have both?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Freitag, 14. Mai 2021 09:22 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Commit 4710
Hi Gerd and others
I'll test setting of 0x40 flag for extended and the range of standard types on various devices over the weekend.
Is there any real need for the force/allow-reverse-merge options?
When you say "remove the code for mkgmap:has-direction", I assume you mean just the style-scan of tags used, rather than inspecting it on a way after style conversion.
Styles don't have to use different tags for river/canal once this is all implemented, can choose 1/ don't set the default direction for waterway type, or use mkgmap:has -direction in style and get current behaviour. 2/ default it to direction, clear it with mkgmap:direction=no when used as canal. This approach could be used if the device shows direction markers on rivers that we want to see. 3/ use distinct types and appropriate representation.
I think it should be carried through into the overview img.
For the dual-carriageway lane merging, I presume it should turn off direction (and one-way).
Ticker
On Fri, 2021-05-14 at 05:11 +0000, Gerd Petermann wrote:
Hi Ticker and all,
reg. tests of the 0x40 flag: Attached small patch would be my guess for the lines with extended type.
The oneway attribute is stored in NOD and in the direction flag, I think that makes sense. The oneway=yes tag used to set the direction flag since more than 10 years (r738).
I do agree now that an option in the style to list types with direction is the better approach, the tag handling is much more complex. The size effects of r4710 reported by Felix show that his style did not set the tag consistently for the same type and I think this can be really tricky. So, I think I'll remove the code for mkgmap:has-direction=true and add a new option to list the types which should be treated as having a direction, e.g. --line-types-with-direction=0x18,0x1f, 0x10005, 0x10006 . The oneway=yes/oneway=-1 tag will continue to set the direction flag. The default style might need some changes to distinguish waterways with direction from others, e.g. I think canals and rivers should have different types.
I'll change the option --x-force-reverse-merge to --allow -reverse -merge with the default --allow-reverse-merge=no. These two options will effect RoadMerger and LineMerger.
I've not yet made up my mind regarding the reversing of lines (and roads) in LineMerger for the overview map. Felix says there is no need to care about direction in the overvew map.
I'll remove the code which tries to propagate the direction flag to underlying roads for now. Let's see first how often this is really needed.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Donnerstag, 13. Mai 2021 23:36 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Commit 4710
Hi
Various thoughts:
The 0x40 polyLine direction flag probably has no effect on modern Garmin devices. As Gerd says, GPSMapEdit puts an arrow on lines if it is set. In my notes from testing all line types, I found some cases where an eTrex put compass bearings (N/NE/E/...) on some line types where the top byte was 0x5 (ie this flag was set), so modifying the meaning line types 0x10 to 0x1f. I think they looked like 0x01 to 0x0f but with the compass label.
I'll have a go at reproducing this - it was a while ago, I had to hack some mkgmap code, and I can't remember which device it was.
Using the existing direction flag logic is overloading it; there is no reason why another flag couldn't be introduced to inhibits line reversal in attempts to merge. However, as the flag is already there, seems to have correct meaning, doesn't have any known harmful effects and might, possibly, be accessible to the TYP representation, then there are many advantages in using it.
I notice an old posting by Andrzej saying one-way arrows are displayed on some devices by default when no TYP graphics. @Andrzej - do you have more details about this?
An option should allow the default setting of this flag per line Type. It would be expected to be set for the types used for rivers, streams, embankments, coastline.... The style/TYP author is responsible for this. It could be one of the options allowed in style/options.
The oneway tag sets it, and it can also be set/cleared with mkgmap:has -direction=yes/no. Should mkgmap:has-direction=no clear the flag if set by one-way? Yes, as long as reversal is also inhibited by oneway.
I don't think there is any need for the style system to look for usages of this tag and change behaviour.
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
please explain in more detail. Why would you add a line with a type that has a direction to be rendered at low resolution when you don't care about the direction at lower resolutions? Hi Gerd, sorry I didn't explain it well enough what I meant. I mean for other lines that are either before or after in the style created by continue. Of course the line itself in that list shall never be reversed in order to be merged. But I still feel if there is cycleway=left no problem to change the underlying street direction so it can be merged. On the other hand If someone wants to prevent that - then add no reverse for resolution up to XX and only reverse the other lines associated with it from resolution XX or lower. The third setting would be never merge the other lines (could also be set by setting resolution to 00 or lower than your lowest resolution. On Fri, 14 May 2021 at 16:01, Ticker Berkin <rwb-mkgmap@jagit.co.uk> wrote:
Hi
I think better/more flexible to have both. Mainly for when there are a limited number of well defined garmin types for an element and some have direction and some don't, eg the various waterways, direction -merged motorways...
However, if there is no way of distinguishing the difference in the final visible representation on any device then there isn't need.
Ticker
On Fri, 2021-05-14 at 15:42 +0800, Felix Hartmann wrote:
I think it is enough with a simple list. As for why it changed for me is Imho because those lines are mostly created with continue or continue with action and it's really hard to see what happens concerning the other lines related to it. I definitely did not miss any lines in my lines file that should not be reversed.
So make it a list, and option for each type other kines created with continue can change direction no, yes, from resolution XX or lower.
That would be best. Gives it all options and you can set it how it works best. I still feel I will always use other lines can be reversed to be merged.
On Fri, 14 May 2021, 15:32 Gerd Petermann < gpetermann_muenchen@hotmail.com> wrote:
Hi Ticker,
I meant I want to remove the evaluation of the special tag mkgmap:has-direction=true and only rely on the new option --line -types-with-direction
Do you see a need to have both?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Freitag, 14. Mai 2021 09:22 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Commit 4710
Hi Gerd and others
I'll test setting of 0x40 flag for extended and the range of standard types on various devices over the weekend.
Is there any real need for the force/allow-reverse-merge options?
When you say "remove the code for mkgmap:has-direction", I assume you mean just the style-scan of tags used, rather than inspecting it on a way after style conversion.
Styles don't have to use different tags for river/canal once this is all implemented, can choose 1/ don't set the default direction for waterway type, or use mkgmap:has -direction in style and get current behaviour. 2/ default it to direction, clear it with mkgmap:direction=no when used as canal. This approach could be used if the device shows direction markers on rivers that we want to see. 3/ use distinct types and appropriate representation.
I think it should be carried through into the overview img.
For the dual-carriageway lane merging, I presume it should turn off direction (and one-way).
Ticker
On Fri, 2021-05-14 at 05:11 +0000, Gerd Petermann wrote:
Hi Ticker and all,
reg. tests of the 0x40 flag: Attached small patch would be my guess for the lines with extended type.
The oneway attribute is stored in NOD and in the direction flag, I think that makes sense. The oneway=yes tag used to set the direction flag since more than 10 years (r738).
I do agree now that an option in the style to list types with direction is the better approach, the tag handling is much more complex. The size effects of r4710 reported by Felix show that his style did not set the tag consistently for the same type and I think this can be really tricky. So, I think I'll remove the code for mkgmap:has-direction=true and add a new option to list the types which should be treated as having a direction, e.g. --line-types-with-direction=0x18,0x1f, 0x10005, 0x10006 . The oneway=yes/oneway=-1 tag will continue to set the direction flag. The default style might need some changes to distinguish waterways with direction from others, e.g. I think canals and rivers should have different types.
I'll change the option --x-force-reverse-merge to --allow -reverse -merge with the default --allow-reverse-merge=no. These two options will effect RoadMerger and LineMerger.
I've not yet made up my mind regarding the reversing of lines (and roads) in LineMerger for the overview map. Felix says there is no need to care about direction in the overvew map.
I'll remove the code which tries to propagate the direction flag to underlying roads for now. Let's see first how often this is really needed.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Donnerstag, 13. Mai 2021 23:36 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Commit 4710
Hi
Various thoughts:
The 0x40 polyLine direction flag probably has no effect on modern Garmin devices. As Gerd says, GPSMapEdit puts an arrow on lines if it is set. In my notes from testing all line types, I found some cases where an eTrex put compass bearings (N/NE/E/...) on some line types where the top byte was 0x5 (ie this flag was set), so modifying the meaning line types 0x10 to 0x1f. I think they looked like 0x01 to 0x0f but with the compass label.
I'll have a go at reproducing this - it was a while ago, I had to hack some mkgmap code, and I can't remember which device it was.
Using the existing direction flag logic is overloading it; there is no reason why another flag couldn't be introduced to inhibits line reversal in attempts to merge. However, as the flag is already there, seems to have correct meaning, doesn't have any known harmful effects and might, possibly, be accessible to the TYP representation, then there are many advantages in using it.
I notice an old posting by Andrzej saying one-way arrows are displayed on some devices by default when no TYP graphics. @Andrzej - do you have more details about this?
An option should allow the default setting of this flag per line Type. It would be expected to be set for the types used for rivers, streams, embankments, coastline.... The style/TYP author is responsible for this. It could be one of the options allowed in style/options.
The oneway tag sets it, and it can also be set/cleared with mkgmap:has -direction=yes/no. Should mkgmap:has-direction=no clear the flag if set by one-way? Yes, as long as reversal is also inhibited by oneway.
I don't think there is any need for the style system to look for usages of this tag and change behaviour.
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
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 problem to change the underlying street direction so it can be merged. There is a possible problem with rendering but I agreed before to postpone this until users complain. So, I want to remove the code which tries to be clever and let only the user decide.
Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver@gmail.com> Gesendet: Freitag, 14. Mai 2021 10:20 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Commit 4710 please explain in more detail. Why would you add a line with a type that has a direction to be rendered at low resolution when you don't care about the direction at lower resolutions? Hi Gerd, sorry I didn't explain it well enough what I meant. I mean for other lines that are either before or after in the style created by continue. Of course the line itself in that list shall never be reversed in order to be merged. But I still feel if there is cycleway=left no problem to change the underlying street direction so it can be merged. On the other hand If someone wants to prevent that - then add no reverse for resolution up to XX and only reverse the other lines associated with it from resolution XX or lower. The third setting would be never merge the other lines (could also be set by setting resolution to 00 or lower than your lowest resolution. On Fri, 14 May 2021 at 16:01, Ticker Berkin <rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk>> wrote: Hi I think better/more flexible to have both. Mainly for when there are a limited number of well defined garmin types for an element and some have direction and some don't, eg the various waterways, direction -merged motorways... However, if there is no way of distinguishing the difference in the final visible representation on any device then there isn't need. Ticker On Fri, 2021-05-14 at 15:42 +0800, Felix Hartmann wrote:
I think it is enough with a simple list. As for why it changed for me is Imho because those lines are mostly created with continue or continue with action and it's really hard to see what happens concerning the other lines related to it. I definitely did not miss any lines in my lines file that should not be reversed.
So make it a list, and option for each type other kines created with continue can change direction no, yes, from resolution XX or lower.
That would be best. Gives it all options and you can set it how it works best. I still feel I will always use other lines can be reversed to be merged.
On Fri, 14 May 2021, 15:32 Gerd Petermann < gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>> wrote:
Hi Ticker,
I meant I want to remove the evaluation of the special tag mkgmap:has-direction=true and only rely on the new option --line -types-with-direction
Do you see a need to have both?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk>> Gesendet: Freitag, 14. Mai 2021 09:22 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Commit 4710
Hi Gerd and others
I'll test setting of 0x40 flag for extended and the range of standard types on various devices over the weekend.
Is there any real need for the force/allow-reverse-merge options?
When you say "remove the code for mkgmap:has-direction", I assume you mean just the style-scan of tags used, rather than inspecting it on a way after style conversion.
Styles don't have to use different tags for river/canal once this is all implemented, can choose 1/ don't set the default direction for waterway type, or use mkgmap:has -direction in style and get current behaviour. 2/ default it to direction, clear it with mkgmap:direction=no when used as canal. This approach could be used if the device shows direction markers on rivers that we want to see. 3/ use distinct types and appropriate representation.
I think it should be carried through into the overview img.
For the dual-carriageway lane merging, I presume it should turn off direction (and one-way).
Ticker
On Fri, 2021-05-14 at 05:11 +0000, Gerd Petermann wrote:
Hi Ticker and all,
reg. tests of the 0x40 flag: Attached small patch would be my guess for the lines with extended type.
The oneway attribute is stored in NOD and in the direction flag, I think that makes sense. The oneway=yes tag used to set the direction flag since more than 10 years (r738).
I do agree now that an option in the style to list types with direction is the better approach, the tag handling is much more complex. The size effects of r4710 reported by Felix show that his style did not set the tag consistently for the same type and I think this can be really tricky. So, I think I'll remove the code for mkgmap:has-direction=true and add a new option to list the types which should be treated as having a direction, e.g. --line-types-with-direction=0x18,0x1f, 0x10005, 0x10006 . The oneway=yes/oneway=-1 tag will continue to set the direction flag. The default style might need some changes to distinguish waterways with direction from others, e.g. I think canals and rivers should have different types.
I'll change the option --x-force-reverse-merge to --allow -reverse -merge with the default --allow-reverse-merge=no. These two options will effect RoadMerger and LineMerger.
I've not yet made up my mind regarding the reversing of lines (and roads) in LineMerger for the overview map. Felix says there is no need to care about direction in the overvew map.
I'll remove the code which tries to propagate the direction flag to underlying roads for now. Let's see first how often this is really needed.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk>> Gesendet: Donnerstag, 13. Mai 2021 23:36 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Commit 4710
Hi
Various thoughts:
The 0x40 polyLine direction flag probably has no effect on modern Garmin devices. As Gerd says, GPSMapEdit puts an arrow on lines if it is set. In my notes from testing all line types, I found some cases where an eTrex put compass bearings (N/NE/E/...) on some line types where the top byte was 0x5 (ie this flag was set), so modifying the meaning line types 0x10 to 0x1f. I think they looked like 0x01 to 0x0f but with the compass label.
I'll have a go at reproducing this - it was a while ago, I had to hack some mkgmap code, and I can't remember which device it was.
Using the existing direction flag logic is overloading it; there is no reason why another flag couldn't be introduced to inhibits line reversal in attempts to merge. However, as the flag is already there, seems to have correct meaning, doesn't have any known harmful effects and might, possibly, be accessible to the TYP representation, then there are many advantages in using it.
I notice an old posting by Andrzej saying one-way arrows are displayed on some devices by default when no TYP graphics. @Andrzej - do you have more details about this?
An option should allow the default setting of this flag per line Type. It would be expected to be set for the types used for rivers, streams, embankments, coastline.... The style/TYP author is responsible for this. It could be one of the options allowed in style/options.
The oneway tag sets it, and it can also be set/cleared with mkgmap:has -direction=yes/no. Should mkgmap:has-direction=no clear the flag if set by one-way? Yes, as long as reversal is also inhibited by oneway.
I don't think there is any need for the style system to look for usages of this tag and change behaviour.
Ticker
_______________________________________________ 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 _______________________________________________ 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
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 _______________________________________________ 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
_______________________________________________ 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
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 I see various aspects to this discussion. Routable one-way roads must have their correct direction preserved and line-merging needs to know and respect this. If, for a given line type, there is a way of visibly distinguishing lines representing features with a direction from the same feature without direction, then this is a feature worth supporting. It saves having to have alternate, user-defined types. Resolution isn't relevant, except for the new idea of taking 2 close parallel lines with the same type but opposite direction/one-way and making 1 line. Now it becomes more important to be able to indicate that this result doesn't have a direction and, unless some other mechanism is added to change the type, this needs to be imposed on the existing type. Ticker On Fri, 2021-05-14 at 16:20 +0800, Felix Hartmann wrote:
please explain in more detail. Why would you add a line with a type that has a direction to be rendered at low resolution when you don't care about the direction at lower resolutions?
Hi Gerd, sorry I didn't explain it well enough what I meant.
I mean for other lines that are either before or after in the style created by continue. Of course the line itself in that list shall never be reversed in order to be merged. But I still feel if there is cycleway=left no problem to change the underlying street direction so it can be merged. On the other hand If someone wants to prevent that - then add no reverse for resolution up to XX and only reverse the other lines associated with it from resolution XX or lower. The third setting would be never merge the other lines (could also be set by setting resolution to 00 or lower than your lowest resolution.
On Fri, 14 May 2021 at 16:01, Ticker Berkin <rwb-mkgmap@jagit.co.uk> wrote:
Hi
I think better/more flexible to have both. Mainly for when there are a limited number of well defined garmin types for an element and some have direction and some don't, eg the various waterways, direction -merged motorways...
However, if there is no way of distinguishing the difference in the final visible representation on any device then there isn't need.
Ticker
On Fri, 2021-05-14 at 15:42 +0800, Felix Hartmann wrote:
I think it is enough with a simple list. As for why it changed for me is Imho because those lines are mostly created with continue or continue with action and it's really hard to see what happens concerning the other lines related to it. I definitely did not miss any lines in my lines file that should not be reversed.
So make it a list, and option for each type other kines created with continue can change direction no, yes, from resolution XX or lower.
That would be best. Gives it all options and you can set it how it works best. I still feel I will always use other lines can be reversed to be merged.
On Fri, 14 May 2021, 15:32 Gerd Petermann < gpetermann_muenchen@hotmail.com> wrote:
Hi Ticker,
I meant I want to remove the evaluation of the special tag mkgmap:has-direction=true and only rely on the new option - -line -types-with-direction
Do you see a need to have both?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Freitag, 14. Mai 2021 09:22 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Commit 4710
Hi Gerd and others
I'll test setting of 0x40 flag for extended and the range of standard types on various devices over the weekend.
Is there any real need for the force/allow-reverse-merge options?
When you say "remove the code for mkgmap:has-direction", I assume you mean just the style-scan of tags used, rather than inspecting it on a way after style conversion.
Styles don't have to use different tags for river/canal once this is all implemented, can choose 1/ don't set the default direction for waterway type, or use mkgmap:has -direction in style and get current behaviour. 2/ default it to direction, clear it with mkgmap:direction=no when used as canal. This approach could be used if the device shows direction markers on rivers that we want to see. 3/ use distinct types and appropriate representation.
I think it should be carried through into the overview img.
For the dual-carriageway lane merging, I presume it should turn off direction (and one-way).
Ticker
On Fri, 2021-05-14 at 05:11 +0000, Gerd Petermann wrote:
Hi Ticker and all,
reg. tests of the 0x40 flag: Attached small patch would be my guess for the lines with extended type.
The oneway attribute is stored in NOD and in the direction flag, I think that makes sense. The oneway=yes tag used to set the direction flag since more than 10 years (r738).
I do agree now that an option in the style to list types with direction is the better approach, the tag handling is much more complex. The size effects of r4710 reported by Felix show that his style did not set the tag consistently for the same type and I think this can be really tricky. So, I think I'll remove the code for mkgmap:has -direction=true and add a new option to list the types which should be treated as having a direction, e.g. --line-types-with-direction=0x18,0x1f, 0x10005, 0x10006 . The oneway=yes/oneway=-1 tag will continue to set the direction flag. The default style might need some changes to distinguish waterways with direction from others, e.g. I think canals and rivers should have different types.
I'll change the option --x-force-reverse-merge to --allow -reverse -merge with the default --allow-reverse-merge=no. These two options will effect RoadMerger and LineMerger.
I've not yet made up my mind regarding the reversing of lines (and roads) in LineMerger for the overview map. Felix says there is no need to care about direction in the overvew map.
I'll remove the code which tries to propagate the direction flag to underlying roads for now. Let's see first how often this is really needed.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Donnerstag, 13. Mai 2021 23:36 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Commit 4710
Hi
Various thoughts:
The 0x40 polyLine direction flag probably has no effect on modern Garmin devices. As Gerd says, GPSMapEdit puts an arrow on lines if it is set. In my notes from testing all line types, I found some cases where an eTrex put compass bearings (N/NE/E/...) on some line types where the top byte was 0x5 (ie this flag was set), so modifying the meaning line types 0x10 to 0x1f. I think they looked like 0x01 to 0x0f but with the compass label.
I'll have a go at reproducing this - it was a while ago, I had to hack some mkgmap code, and I can't remember which device it was.
Using the existing direction flag logic is overloading it; there is no reason why another flag couldn't be introduced to inhibits line reversal in attempts to merge. However, as the flag is already there, seems to have correct meaning, doesn't have any known harmful effects and might, possibly, be accessible to the TYP representation, then there are many advantages in using it.
I notice an old posting by Andrzej saying one-way arrows are displayed on some devices by default when no TYP graphics. @Andrzej - do you have more details about this?
An option should allow the default setting of this flag per line Type. It would be expected to be set for the types used for rivers, streams, embankments, coastline.... The style/TYP author is responsible for this. It could be one of the options allowed in style/options.
The oneway tag sets it, and it can also be set/cleared with mkgmap:has -direction=yes/no. Should mkgmap:has-direction=no clear the flag if set by one-way? Yes, as long as reversal is also inhibited by oneway.
I don't think there is any need for the style system to look for usages of this tag and change behaviour.
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
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
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
*Routable one-way roads must have their correct direction preserved andline-merging needs to know and respect this.* I do not think so. They must have their correct direction for level 0, but not for level 1 (except if you display one way arrows at level 1 - then they need to be added to the do not reverse list - and again only the line that uses oneway arrows if different from the routable line). E.g. nearly all motorways are oneway. Well very unlikely they are ever mapped in opposite direction, but even then I do not see why at level 1 or higher their direction matters. Only level 0 is responsible for routing. There is no discussion that we ever reverse a routable line at level 0. And I suppose that there is no marker in Garmin maps to display arrows for oneway - but then you never know. Many things about Garmin maps were found out that Garmin never used before, especially when it comes to .typ-files. Often such not used features would be removed in newer generations however. E.g. Garmin had never used the possibility to display a route besides a road - or any typfile line out of center. I think I first used this widely, and while Mapsource and devices displayed it correctly, Garmin roadtrip just centered them (or it was some device or other software centering them). A couple of years later Garmin started using off center lines themselves and made all their software show this correctly. There is still the left/right bug that they never fixed because their own maps do not use it. On Fri, 14 May 2021 at 16:46, Ticker Berkin <rwb-mkgmap@jagit.co.uk> wrote:
Hi
I see various aspects to this discussion.
Routable one-way roads must have their correct direction preserved and line-merging needs to know and respect this.
If, for a given line type, there is a way of visibly distinguishing lines representing features with a direction from the same feature without direction, then this is a feature worth supporting. It saves having to have alternate, user-defined types.
Resolution isn't relevant, except for the new idea of taking 2 close parallel lines with the same type but opposite direction/one-way and making 1 line. Now it becomes more important to be able to indicate that this result doesn't have a direction and, unless some other mechanism is added to change the type, this needs to be imposed on the existing type.
Ticker
On Fri, 2021-05-14 at 16:20 +0800, Felix Hartmann wrote:
please explain in more detail. Why would you add a line with a type that has a direction to be rendered at low resolution when you don't care about the direction at lower resolutions?
Hi Gerd, sorry I didn't explain it well enough what I meant.
I mean for other lines that are either before or after in the style created by continue. Of course the line itself in that list shall never be reversed in order to be merged. But I still feel if there is cycleway=left no problem to change the underlying street direction so it can be merged. On the other hand If someone wants to prevent that - then add no reverse for resolution up to XX and only reverse the other lines associated with it from resolution XX or lower. The third setting would be never merge the other lines (could also be set by setting resolution to 00 or lower than your lowest resolution.
On Fri, 14 May 2021 at 16:01, Ticker Berkin <rwb-mkgmap@jagit.co.uk> wrote:
Hi
I think better/more flexible to have both. Mainly for when there are a limited number of well defined garmin types for an element and some have direction and some don't, eg the various waterways, direction -merged motorways...
However, if there is no way of distinguishing the difference in the final visible representation on any device then there isn't need.
Ticker
On Fri, 2021-05-14 at 15:42 +0800, Felix Hartmann wrote:
I think it is enough with a simple list. As for why it changed for me is Imho because those lines are mostly created with continue or continue with action and it's really hard to see what happens concerning the other lines related to it. I definitely did not miss any lines in my lines file that should not be reversed.
So make it a list, and option for each type other kines created with continue can change direction no, yes, from resolution XX or lower.
That would be best. Gives it all options and you can set it how it works best. I still feel I will always use other lines can be reversed to be merged.
On Fri, 14 May 2021, 15:32 Gerd Petermann < gpetermann_muenchen@hotmail.com> wrote:
Hi Ticker,
I meant I want to remove the evaluation of the special tag mkgmap:has-direction=true and only rely on the new option - -line -types-with-direction
Do you see a need to have both?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Freitag, 14. Mai 2021 09:22 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Commit 4710
Hi Gerd and others
I'll test setting of 0x40 flag for extended and the range of standard types on various devices over the weekend.
Is there any real need for the force/allow-reverse-merge options?
When you say "remove the code for mkgmap:has-direction", I assume you mean just the style-scan of tags used, rather than inspecting it on a way after style conversion.
Styles don't have to use different tags for river/canal once this is all implemented, can choose 1/ don't set the default direction for waterway type, or use mkgmap:has -direction in style and get current behaviour. 2/ default it to direction, clear it with mkgmap:direction=no when used as canal. This approach could be used if the device shows direction markers on rivers that we want to see. 3/ use distinct types and appropriate representation.
I think it should be carried through into the overview img.
For the dual-carriageway lane merging, I presume it should turn off direction (and one-way).
Ticker
On Fri, 2021-05-14 at 05:11 +0000, Gerd Petermann wrote:
Hi Ticker and all,
reg. tests of the 0x40 flag: Attached small patch would be my guess for the lines with extended type.
The oneway attribute is stored in NOD and in the direction flag, I think that makes sense. The oneway=yes tag used to set the direction flag since more than 10 years (r738).
I do agree now that an option in the style to list types with direction is the better approach, the tag handling is much more complex. The size effects of r4710 reported by Felix show that his style did not set the tag consistently for the same type and I think this can be really tricky. So, I think I'll remove the code for mkgmap:has -direction=true and add a new option to list the types which should be treated as having a direction, e.g. --line-types-with-direction=0x18,0x1f, 0x10005, 0x10006 . The oneway=yes/oneway=-1 tag will continue to set the direction flag. The default style might need some changes to distinguish waterways with direction from others, e.g. I think canals and rivers should have different types.
I'll change the option --x-force-reverse-merge to --allow -reverse -merge with the default --allow-reverse-merge=no. These two options will effect RoadMerger and LineMerger.
I've not yet made up my mind regarding the reversing of lines (and roads) in LineMerger for the overview map. Felix says there is no need to care about direction in the overvew map.
I'll remove the code which tries to propagate the direction flag to underlying roads for now. Let's see first how often this is really needed.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Donnerstag, 13. Mai 2021 23:36 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Commit 4710
Hi
Various thoughts:
The 0x40 polyLine direction flag probably has no effect on modern Garmin devices. As Gerd says, GPSMapEdit puts an arrow on lines if it is set. In my notes from testing all line types, I found some cases where an eTrex put compass bearings (N/NE/E/...) on some line types where the top byte was 0x5 (ie this flag was set), so modifying the meaning line types 0x10 to 0x1f. I think they looked like 0x01 to 0x0f but with the compass label.
I'll have a go at reproducing this - it was a while ago, I had to hack some mkgmap code, and I can't remember which device it was.
Using the existing direction flag logic is overloading it; there is no reason why another flag couldn't be introduced to inhibits line reversal in attempts to merge. However, as the flag is already there, seems to have correct meaning, doesn't have any known harmful effects and might, possibly, be accessible to the TYP representation, then there are many advantages in using it.
I notice an old posting by Andrzej saying one-way arrows are displayed on some devices by default when no TYP graphics. @Andrzej - do you have more details about this?
An option should allow the default setting of this flag per line Type. It would be expected to be set for the types used for rivers, streams, embankments, coastline.... The style/TYP author is responsible for this. It could be one of the options allowed in style/options.
The oneway tag sets it, and it can also be set/cleared with mkgmap:has -direction=yes/no. Should mkgmap:has-direction=no clear the flag if set by one-way? Yes, as long as reversal is also inhibited by oneway.
I don't think there is any need for the style system to look for usages of this tag and change behaviour.
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
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
_______________________________________________ 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
-- Felix Hartman - Openmtbmap.org & VeloMap.org
Hi Felix,
There is no discussion that we ever reverse a routable line at level 0. Why do you think that? Of course we do (and want to do) that when reversing is allowed.
Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver@gmail.com> Gesendet: Freitag, 14. Mai 2021 11:02 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Commit 4710 Routable one-way roads must have their correct direction preserved and line-merging needs to know and respect this. I do not think so. They must have their correct direction for level 0, but not for level 1 (except if you display one way arrows at level 1 - then they need to be added to the do not reverse list - and again only the line that uses oneway arrows if different from the routable line). E.g. nearly all motorways are oneway. Well very unlikely they are ever mapped in opposite direction, but even then I do not see why at level 1 or higher their direction matters. Only level 0 is responsible for routing. There is no discussion that we ever reverse a routable line at level 0. And I suppose that there is no marker in Garmin maps to display arrows for oneway - but then you never know. Many things about Garmin maps were found out that Garmin never used before, especially when it comes to .typ-files. Often such not used features would be removed in newer generations however. E.g. Garmin had never used the possibility to display a route besides a road - or any typfile line out of center. I think I first used this widely, and while Mapsource and devices displayed it correctly, Garmin roadtrip just centered them (or it was some device or other software centering them). A couple of years later Garmin started using off center lines themselves and made all their software show this correctly. There is still the left/right bug that they never fixed because their own maps do not use it. On Fri, 14 May 2021 at 16:46, Ticker Berkin <rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk>> wrote: Hi I see various aspects to this discussion. Routable one-way roads must have their correct direction preserved and line-merging needs to know and respect this. If, for a given line type, there is a way of visibly distinguishing lines representing features with a direction from the same feature without direction, then this is a feature worth supporting. It saves having to have alternate, user-defined types. Resolution isn't relevant, except for the new idea of taking 2 close parallel lines with the same type but opposite direction/one-way and making 1 line. Now it becomes more important to be able to indicate that this result doesn't have a direction and, unless some other mechanism is added to change the type, this needs to be imposed on the existing type. Ticker On Fri, 2021-05-14 at 16:20 +0800, Felix Hartmann wrote:
please explain in more detail. Why would you add a line with a type that has a direction to be rendered at low resolution when you don't care about the direction at lower resolutions?
Hi Gerd, sorry I didn't explain it well enough what I meant.
I mean for other lines that are either before or after in the style created by continue. Of course the line itself in that list shall never be reversed in order to be merged. But I still feel if there is cycleway=left no problem to change the underlying street direction so it can be merged. On the other hand If someone wants to prevent that - then add no reverse for resolution up to XX and only reverse the other lines associated with it from resolution XX or lower. The third setting would be never merge the other lines (could also be set by setting resolution to 00 or lower than your lowest resolution.
On Fri, 14 May 2021 at 16:01, Ticker Berkin <rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk>> wrote:
Hi
I think better/more flexible to have both. Mainly for when there are a limited number of well defined garmin types for an element and some have direction and some don't, eg the various waterways, direction -merged motorways...
However, if there is no way of distinguishing the difference in the final visible representation on any device then there isn't need.
Ticker
On Fri, 2021-05-14 at 15:42 +0800, Felix Hartmann wrote:
I think it is enough with a simple list. As for why it changed for me is Imho because those lines are mostly created with continue or continue with action and it's really hard to see what happens concerning the other lines related to it. I definitely did not miss any lines in my lines file that should not be reversed.
So make it a list, and option for each type other kines created with continue can change direction no, yes, from resolution XX or lower.
That would be best. Gives it all options and you can set it how it works best. I still feel I will always use other lines can be reversed to be merged.
On Fri, 14 May 2021, 15:32 Gerd Petermann < gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>> wrote:
Hi Ticker,
I meant I want to remove the evaluation of the special tag mkgmap:has-direction=true and only rely on the new option - -line -types-with-direction
Do you see a need to have both?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk>> Gesendet: Freitag, 14. Mai 2021 09:22 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Commit 4710
Hi Gerd and others
I'll test setting of 0x40 flag for extended and the range of standard types on various devices over the weekend.
Is there any real need for the force/allow-reverse-merge options?
When you say "remove the code for mkgmap:has-direction", I assume you mean just the style-scan of tags used, rather than inspecting it on a way after style conversion.
Styles don't have to use different tags for river/canal once this is all implemented, can choose 1/ don't set the default direction for waterway type, or use mkgmap:has -direction in style and get current behaviour. 2/ default it to direction, clear it with mkgmap:direction=no when used as canal. This approach could be used if the device shows direction markers on rivers that we want to see. 3/ use distinct types and appropriate representation.
I think it should be carried through into the overview img.
For the dual-carriageway lane merging, I presume it should turn off direction (and one-way).
Ticker
On Fri, 2021-05-14 at 05:11 +0000, Gerd Petermann wrote:
Hi Ticker and all,
reg. tests of the 0x40 flag: Attached small patch would be my guess for the lines with extended type.
The oneway attribute is stored in NOD and in the direction flag, I think that makes sense. The oneway=yes tag used to set the direction flag since more than 10 years (r738).
I do agree now that an option in the style to list types with direction is the better approach, the tag handling is much more complex. The size effects of r4710 reported by Felix show that his style did not set the tag consistently for the same type and I think this can be really tricky. So, I think I'll remove the code for mkgmap:has -direction=true and add a new option to list the types which should be treated as having a direction, e.g. --line-types-with-direction=0x18,0x1f, 0x10005, 0x10006 . The oneway=yes/oneway=-1 tag will continue to set the direction flag. The default style might need some changes to distinguish waterways with direction from others, e.g. I think canals and rivers should have different types.
I'll change the option --x-force-reverse-merge to --allow -reverse -merge with the default --allow-reverse-merge=no. These two options will effect RoadMerger and LineMerger.
I've not yet made up my mind regarding the reversing of lines (and roads) in LineMerger for the overview map. Felix says there is no need to care about direction in the overvew map.
I'll remove the code which tries to propagate the direction flag to underlying roads for now. Let's see first how often this is really needed.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk>> Gesendet: Donnerstag, 13. Mai 2021 23:36 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Commit 4710
Hi
Various thoughts:
The 0x40 polyLine direction flag probably has no effect on modern Garmin devices. As Gerd says, GPSMapEdit puts an arrow on lines if it is set. In my notes from testing all line types, I found some cases where an eTrex put compass bearings (N/NE/E/...) on some line types where the top byte was 0x5 (ie this flag was set), so modifying the meaning line types 0x10 to 0x1f. I think they looked like 0x01 to 0x0f but with the compass label.
I'll have a go at reproducing this - it was a while ago, I had to hack some mkgmap code, and I can't remember which device it was.
Using the existing direction flag logic is overloading it; there is no reason why another flag couldn't be introduced to inhibits line reversal in attempts to merge. However, as the flag is already there, seems to have correct meaning, doesn't have any known harmful effects and might, possibly, be accessible to the TYP representation, then there are many advantages in using it.
I notice an old posting by Andrzej saying one-way arrows are displayed on some devices by default when no TYP graphics. @Andrzej - do you have more details about this?
An option should allow the default setting of this flag per line Type. It would be expected to be set for the types used for rivers, streams, embankments, coastline.... The style/TYP author is responsible for this. It could be one of the options allowed in style/options.
The oneway tag sets it, and it can also be set/cleared with mkgmap:has -direction=yes/no. Should mkgmap:has-direction=no clear the flag if set by one-way? Yes, as long as reversal is also inhibited by oneway.
I don't think there is any need for the style system to look for usages of this tag and change behaviour.
Ticker
_______________________________________________ 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 _______________________________________________ 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
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 _______________________________________________ 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
_______________________________________________ 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
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<mailto: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<mailto:mkgmap-dev@lists.mkgmap.org.uk> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Felix Hartman - Openmtbmap.org & VeloMap.org
Ah sorry, I meant a routable line with oneway attribute. Except of course oneway=reverse / -1 which has to be reversed. On Fri, 14 May 2021 at 17:11, Gerd Petermann < gpetermann_muenchen@hotmail.com> wrote:
Hi Felix,
There is no discussion that we ever reverse a routable line at level 0. Why do you think that? Of course we do (and want to do) that when reversing is allowed.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver@gmail.com> Gesendet: Freitag, 14. Mai 2021 11:02 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Commit 4710
Routable one-way roads must have their correct direction preserved and line-merging needs to know and respect this.
I do not think so. They must have their correct direction for level 0, but not for level 1 (except if you display one way arrows at level 1 - then they need to be added to the do not reverse list - and again only the line that uses oneway arrows if different from the routable line). E.g. nearly all motorways are oneway. Well very unlikely they are ever mapped in opposite direction, but even then I do not see why at level 1 or higher their direction matters. Only level 0 is responsible for routing. There is no discussion that we ever reverse a routable line at level 0.
And I suppose that there is no marker in Garmin maps to display arrows for oneway - but then you never know. Many things about Garmin maps were found out that Garmin never used before, especially when it comes to .typ-files. Often such not used features would be removed in newer generations however. E.g. Garmin had never used the possibility to display a route besides a road - or any typfile line out of center. I think I first used this widely, and while Mapsource and devices displayed it correctly, Garmin roadtrip just centered them (or it was some device or other software centering them). A couple of years later Garmin started using off center lines themselves and made all their software show this correctly. There is still the left/right bug that they never fixed because their own maps do not use it.
On Fri, 14 May 2021 at 16:46, Ticker Berkin <rwb-mkgmap@jagit.co.uk <mailto:rwb-mkgmap@jagit.co.uk>> wrote: Hi
I see various aspects to this discussion.
Routable one-way roads must have their correct direction preserved and line-merging needs to know and respect this.
If, for a given line type, there is a way of visibly distinguishing lines representing features with a direction from the same feature without direction, then this is a feature worth supporting. It saves having to have alternate, user-defined types.
Resolution isn't relevant, except for the new idea of taking 2 close parallel lines with the same type but opposite direction/one-way and making 1 line. Now it becomes more important to be able to indicate that this result doesn't have a direction and, unless some other mechanism is added to change the type, this needs to be imposed on the existing type.
Ticker
On Fri, 2021-05-14 at 16:20 +0800, Felix Hartmann wrote:
please explain in more detail. Why would you add a line with a type that has a direction to be rendered at low resolution when you don't care about the direction at lower resolutions?
Hi Gerd, sorry I didn't explain it well enough what I meant.
I mean for other lines that are either before or after in the style created by continue. Of course the line itself in that list shall never be reversed in order to be merged. But I still feel if there is cycleway=left no problem to change the underlying street direction so it can be merged. On the other hand If someone wants to prevent that - then add no reverse for resolution up to XX and only reverse the other lines associated with it from resolution XX or lower. The third setting would be never merge the other lines (could also be set by setting resolution to 00 or lower than your lowest resolution.
On Fri, 14 May 2021 at 16:01, Ticker Berkin <rwb-mkgmap@jagit.co.uk
<mailto:rwb-mkgmap@jagit.co.uk>>
wrote:
Hi
I think better/more flexible to have both. Mainly for when there are a limited number of well defined garmin types for an element and some have direction and some don't, eg the various waterways, direction -merged motorways...
However, if there is no way of distinguishing the difference in the final visible representation on any device then there isn't need.
Ticker
On Fri, 2021-05-14 at 15:42 +0800, Felix Hartmann wrote:
I think it is enough with a simple list. As for why it changed for me is Imho because those lines are mostly created with continue or continue with action and it's really hard to see what happens concerning the other lines related to it. I definitely did not miss any lines in my lines file that should not be reversed.
So make it a list, and option for each type other kines created with continue can change direction no, yes, from resolution XX or lower.
That would be best. Gives it all options and you can set it how it works best. I still feel I will always use other lines can be reversed to be merged.
On Fri, 14 May 2021, 15:32 Gerd Petermann < gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com>> wrote:
Hi Ticker,
I meant I want to remove the evaluation of the special tag mkgmap:has-direction=true and only rely on the new option - -line -types-with-direction
Do you see a need to have both?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk>> Gesendet: Freitag, 14. Mai 2021 09:22 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Commit 4710
Hi Gerd and others
I'll test setting of 0x40 flag for extended and the range of standard types on various devices over the weekend.
Is there any real need for the force/allow-reverse-merge options?
When you say "remove the code for mkgmap:has-direction", I assume you mean just the style-scan of tags used, rather than inspecting it on a way after style conversion.
Styles don't have to use different tags for river/canal once this is all implemented, can choose 1/ don't set the default direction for waterway type, or use mkgmap:has -direction in style and get current behaviour. 2/ default it to direction, clear it with mkgmap:direction=no when used as canal. This approach could be used if the device shows direction markers on rivers that we want to see. 3/ use distinct types and appropriate representation.
I think it should be carried through into the overview img.
For the dual-carriageway lane merging, I presume it should turn off direction (and one-way).
Ticker
On Fri, 2021-05-14 at 05:11 +0000, Gerd Petermann wrote:
Hi Ticker and all,
reg. tests of the 0x40 flag: Attached small patch would be my guess for the lines with extended type.
The oneway attribute is stored in NOD and in the direction flag, I think that makes sense. The oneway=yes tag used to set the direction flag since more than 10 years (r738).
I do agree now that an option in the style to list types with direction is the better approach, the tag handling is much more complex. The size effects of r4710 reported by Felix show that his style did not set the tag consistently for the same type and I think this can be really tricky. So, I think I'll remove the code for mkgmap:has -direction=true and add a new option to list the types which should be treated as having a direction, e.g. --line-types-with-direction=0x18,0x1f, 0x10005, 0x10006 . The oneway=yes/oneway=-1 tag will continue to set the direction flag. The default style might need some changes to distinguish waterways with direction from others, e.g. I think canals and rivers should have different types.
I'll change the option --x-force-reverse-merge to --allow -reverse -merge with the default --allow-reverse-merge=no. These two options will effect RoadMerger and LineMerger.
I've not yet made up my mind regarding the reversing of lines (and roads) in LineMerger for the overview map. Felix says there is no need to care about direction in the overvew map.
I'll remove the code which tries to propagate the direction flag to underlying roads for now. Let's see first how often this is really needed.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk>> Gesendet: Donnerstag, 13. Mai 2021 23:36 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Commit 4710
Hi
Various thoughts:
The 0x40 polyLine direction flag probably has no effect on modern Garmin devices. As Gerd says, GPSMapEdit puts an arrow on lines if it is set. In my notes from testing all line types, I found some cases where an eTrex put compass bearings (N/NE/E/...) on some line types where the top byte was 0x5 (ie this flag was set), so modifying the meaning line types 0x10 to 0x1f. I think they looked like 0x01 to 0x0f but with the compass label.
I'll have a go at reproducing this - it was a while ago, I had to hack some mkgmap code, and I can't remember which device it was.
Using the existing direction flag logic is overloading it; there is no reason why another flag couldn't be introduced to inhibits line reversal in attempts to merge. However, as the flag is already there, seems to have correct meaning, doesn't have any known harmful effects and might, possibly, be accessible to the TYP representation, then there are many advantages in using it.
I notice an old posting by Andrzej saying one-way arrows are displayed on some devices by default when no TYP graphics. @Andrzej - do you have more details about this?
An option should allow the default setting of this flag per line Type. It would be expected to be set for the types used for rivers, streams, embankments, coastline.... The style/TYP author is responsible for this. It could be one of the options allowed in style/options.
The oneway tag sets it, and it can also be set/cleared with mkgmap:has -direction=yes/no. Should mkgmap:has-direction=no clear the flag if set by one-way? Yes, as long as reversal is also inhibited by oneway.
I don't think there is any need for the style system to look for usages of this tag and change behaviour.
Ticker
_______________________________________________ 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 _______________________________________________ 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
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 _______________________________________________ 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
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
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<mailto: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<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
Yes I am pretty sure. Because I just recreated the map and it is the same again. https://openmtbmap.org/mtbaustria_4709.exe vs https://openmtbmap.org/mtbaustria_4711.exe. (same FID/PID need to change to another to have both in Basecamp) in windows format soon. Here is one route that is different. Use with bicycle profile without any restrictions / avoidances set and shorter distance. On Thu, 13 May 2021 at 21:14, Gerd Petermann < gpetermann_muenchen@hotmail.com> wrote:
Hi all,
I fear I've totally forgotten the case of extended line types. I think the current code doesn't write the direction flag for them and I don't know if they can have a direction.
Gerd
________________________________________ Von: Gerd Petermann <gpetermann_muenchen@hotmail.com> Gesendet: Donnerstag, 13. Mai 2021 14:33 An: Development list for mkgmap Betreff: AW: [mkgmap-dev] Commit 4710
Hi Felix,
are you sure that you tested the two versions with exactly the same input? (osm data, style, options)? If the changes in r4710 or r4711 really cause differences in routing quality there must be an error, either in my understanding or in the code. Maybe you can post links to two tiles where routing differs?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver@gmail.com> Gesendet: Donnerstag, 13. Mai 2021 14:24 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Commit 4710
Yes, 4711 on branch vs best version 4709 on branch. 4709 was best so far.
On Thu, 13 May 2021, 19:37 Gerd Petermann <gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com>> wrote: Hi Felix,
you totally lost me. There is no version r4713 in the branch. It seems you report the version number that svn shows after an svn update? That's not relevant, you must use svn info to find out the version of your branch. svn update always shows the latest commit, no matter in what branch it was made.
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: Donnerstag, 13. Mai 2021 13:16 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Commit 4710
I just looked it up. It must have been 4709 with best routing for me (unlikely but maybe it could have been 4708), while 4711 is a bit worse (but better than before the first changes that made an impact on routing). Both from low-res-opt branch. I haven't tried trunk for quite a while.
On Thu, 13 May 2021 at 17:42, Gerd Petermann < gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com
<mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com>>> wrote: Hi Felix,
please tell me exactly which versions you tested reg. routing. Note that the branches do not yet contain the latest changes in trunk.
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: Donnerstag, 13. Mai 2021 11:28 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Commit 4710
Well I just got to test routing - and the current version is a degradation vs the intermediate version from yesterday for my maps. The current version routes better than before, but worse than the intermediate version.
As for the list - it is a bit more complicated inside the style but doable. I really do not know what happens to those ways where I first set a direction for an downhill only way with higher priority, then remove the direction for a way that can be used in both directions at lower priority. Maybe sometimes also doing this the other way around. A list with type and max resolution used would be much easier for writing your style. Instead of adding 60-100 lines with the filter it would be done with 10 or so. Canals should not have a direction, they do not flow. Sidewalk=left, right is the same as for the various cylceway,cycletrack options - those are really not reversible. The underlying way could be reversed however - and I guess they are only used for level 0. Oneway arrows for streets are maybe used from resoltuion 24-22 or 24 only. Cliffs are also only high resolution. For me rivers are the only thing which really go into lower resolutions.
On Thu, 13 May 2021 at 16:03, Gerd Petermann < gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com
<mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com><mailto: gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>> wrote: Hi Felix,
FYI: I just found out that the current code to detect if the style sets mkgmap:has-direction=true doesn't work. Seems I didn't test this :( The change in r4710 changed only the LineMerger in the branch. Even with r4711 LineMerger only merges roads in maps without NET, at least that's what's intended.
My understanding is that r4703 changed routing, possibly also r4704. The merge from trunk also changed routing in the branches (r4706 and r4707).
I'm now fixing the detection code, next I'm trying to figure out how to configure the details reg. direction handling.
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>><mailto: 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>><mailto: extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto: extremecarver@gmail.com<mailto:extremecarver@gmail.com>>>> Gesendet: Donnerstag, 13. Mai 2021 09:52 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Commit 4710
I kinda feel by default even oneway=yes should only mean do not change direction for level 0. If someone uses a style to have arrows showing the oneway, then only for that arrow line (defined by tag) the direction cannot be reversed. Yes the problem of DP filter rests - I feel this does not matter for resolution 24 and even 23, but if you display arrows for resolution 22 or higher then a tag should not merge the underlying lines. Besides rivers (then also many styles do not have an arrow for rivers, or you could decide to show the arrows only at resolution 24 and 23) few lines will be objection dependent.
I will try out now if there is any change in routing - but I will only write again if there unexpectedly is. The sharp angles changed routing for the better for my maps by quite a lot. So maybe with now some less lines being merged, there actually will be a little change for the worse back to the old behavior. Not sure..
On Thu, 13 May 2021 at 14:07, Gerd Petermann < gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com
<mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com><mailto: gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com
<mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com>><mailto: gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com>>>>> wrote: Hi Felix,
yes, size increases if your style sets mkgmap:has-direction=true. I just want to make sure that the direction flag is treated correctly first. As already discussed we might introduce a new option or tag to tell mkgmap the min. level at which the direction has to be kept. You suggested to ignore direction at level > 0, I think it might depend on the style and TYP. I'll play with the OFM style to find out more.
The change should not affect routing at all (none of the changes in the low-res-opt branch should).
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>><mailto: 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>>><mailto: 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>><mailto: 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>><mailto: extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto: extremecarver@g mail.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><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com>>>>> Gesendet: Donnerstag, 13. Mai 2021 02:59 An: Development list for mkgmap Betreff: [mkgmap-dev] Commit 4710
fix error in LineMergeFilter reg. lines with direction The line merger should not merge lines if one has the direction flag set and the other has not. Problem exists also in trunk.
Hmm fixing this stopped all the nice size optimization. Map size got much bigger again. I did not find any place where this mattered. Routing was also not affected badly. Maybe I did not look good enough?
I do not see why not to merge them. As long as it`s not the opposite it seems fine... Map size increase/decrease is around 1.5% with my style. So thats quite a big difference. -- 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>><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 <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
_______________________________________________ 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
_______________________________________________ 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
_______________________________________________ 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 _______________________________________________ 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 cannot reproduce your results. For me, both maps seem to give the same routing result in Mapsource: a route that is much longer than yours (146 km instead of 129) . Do you use non-standard driving-speeds? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver@gmail.com> Gesendet: Donnerstag, 13. Mai 2021 17:52 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Commit 4710 Yes I am pretty sure. Because I just recreated the map and it is the same again. https://openmtbmap.org/mtbaustria_4709.exe vs https://openmtbmap.org/mtbaustria_4711.exe. (same FID/PID need to change to another to have both in Basecamp) in windows format soon. Here is one route that is different. Use with bicycle profile without any restrictions / avoidances set and shorter distance. On Thu, 13 May 2021 at 21:14, Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>> wrote: Hi all, I fear I've totally forgotten the case of extended line types. I think the current code doesn't write the direction flag for them and I don't know if they can have a direction. Gerd ________________________________________ Von: Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>> Gesendet: Donnerstag, 13. Mai 2021 14:33 An: Development list for mkgmap Betreff: AW: [mkgmap-dev] Commit 4710 Hi Felix, are you sure that you tested the two versions with exactly the same input? (osm data, style, options)? If the changes in r4710 or r4711 really cause differences in routing quality there must be an error, either in my understanding or in the code. Maybe you can post links to two tiles where routing differs? 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: Donnerstag, 13. Mai 2021 14:24 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Commit 4710 Yes, 4711 on branch vs best version 4709 on branch. 4709 was best so far. On Thu, 13 May 2021, 19:37 Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>> wrote: Hi Felix, you totally lost me. There is no version r4713 in the branch. It seems you report the version number that svn shows after an svn update? That's not relevant, you must use svn info to find out the version of your branch. svn update always shows the latest commit, no matter in what branch it was made. 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: Donnerstag, 13. Mai 2021 13:16 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Commit 4710 I just looked it up. It must have been 4709 with best routing for me (unlikely but maybe it could have been 4708), while 4711 is a bit worse (but better than before the first changes that made an impact on routing). Both from low-res-opt branch. I haven't tried trunk for quite a while. On Thu, 13 May 2021 at 17:42, Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>> wrote: Hi Felix, please tell me exactly which versions you tested reg. routing. Note that the branches do not yet contain the latest changes in trunk. 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>><mailto: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>><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>>> Gesendet: Donnerstag, 13. Mai 2021 11:28 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Commit 4710 Well I just got to test routing - and the current version is a degradation vs the intermediate version from yesterday for my maps. The current version routes better than before, but worse than the intermediate version. As for the list - it is a bit more complicated inside the style but doable. I really do not know what happens to those ways where I first set a direction for an downhill only way with higher priority, then remove the direction for a way that can be used in both directions at lower priority. Maybe sometimes also doing this the other way around. A list with type and max resolution used would be much easier for writing your style. Instead of adding 60-100 lines with the filter it would be done with 10 or so. Canals should not have a direction, they do not flow. Sidewalk=left, right is the same as for the various cylceway,cycletrack options - those are really not reversible. The underlying way could be reversed however - and I guess they are only used for level 0. Oneway arrows for streets are maybe used from resoltuion 24-22 or 24 only. Cliffs are also only high resolution. For me rivers are the only thing which really go into lower resolutions. On Thu, 13 May 2021 at 16:03, Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>>> wrote: Hi Felix, FYI: I just found out that the current code to detect if the style sets mkgmap:has-direction=true doesn't work. Seems I didn't test this :( The change in r4710 changed only the LineMerger in the branch. Even with r4711 LineMerger only merges roads in maps without NET, at least that's what's intended. My understanding is that r4703 changed routing, possibly also r4704. The merge from trunk also changed routing in the branches (r4706 and r4707). I'm now fixing the detection code, next I'm trying to figure out how to configure the details reg. direction handling. 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>><mailto: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>>><mailto: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>><mailto: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>><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<mailto:extremecarver@gmail.com>><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>>>> Gesendet: Donnerstag, 13. Mai 2021 09:52 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Commit 4710 I kinda feel by default even oneway=yes should only mean do not change direction for level 0. If someone uses a style to have arrows showing the oneway, then only for that arrow line (defined by tag) the direction cannot be reversed. Yes the problem of DP filter rests - I feel this does not matter for resolution 24 and even 23, but if you display arrows for resolution 22 or higher then a tag should not merge the underlying lines. Besides rivers (then also many styles do not have an arrow for rivers, or you could decide to show the arrows only at resolution 24 and 23) few lines will be objection dependent. I will try out now if there is any change in routing - but I will only write again if there unexpectedly is. The sharp angles changed routing for the better for my maps by quite a lot. So maybe with now some less lines being merged, there actually will be a little change for the worse back to the old behavior. Not sure.. On Thu, 13 May 2021 at 14:07, Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>>>> wrote: Hi Felix, yes, size increases if your style sets mkgmap:has-direction=true. I just want to make sure that the direction flag is treated correctly first. As already discussed we might introduce a new option or tag to tell mkgmap the min. level at which the direction has to be kept. You suggested to ignore direction at level > 0, I think it might depend on the style and TYP. I'll play with the OFM style to find out more. The change should not affect routing at all (none of the changes in the low-res-opt branch should). 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>><mailto: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>>><mailto: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>><mailto: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>>>><mailto: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>><mailto: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>>><mailto: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>><mailto: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>><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<mailto:extremecarver@gmail.com>><mailto:extremecarver@g<mailto:extremecarver@g> mail.com<http://mail.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<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>><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>>>>> Gesendet: Donnerstag, 13. Mai 2021 02:59 An: Development list for mkgmap Betreff: [mkgmap-dev] Commit 4710 fix error in LineMergeFilter reg. lines with direction The line merger should not merge lines if one has the direction flag set and the other has not. Problem exists also in trunk. Hmm fixing this stopped all the nice size optimization. Map size got much bigger again. I did not find any place where this mattered. Routing was also not affected badly. Maybe I did not look good enough? I do not see why not to merge them. As long as it`s not the opposite it seems fine... Map size increase/decrease is around 1.5% with my style. So thats quite a big difference. -- 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>><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<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><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<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 _______________________________________________ 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>>><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<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<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 _______________________________________________ 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 _______________________________________________ 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
I never tested Mapsource, only Basecamp. Routing in Basecamp is much more similar to modern devices. But I just noticed that by accident I had faster time activated, and not shorter distance. On shorter distance the differences pop up much less often. Here is a route that also routes different with shorter distance. On Fri, 14 May 2021 at 16:31, Gerd Petermann < gpetermann_muenchen@hotmail.com> wrote:
Hi Felix,
I cannot reproduce your results. For me, both maps seem to give the same routing result in Mapsource: a route that is much longer than yours (146 km instead of 129) . Do you use non-standard driving-speeds?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver@gmail.com> Gesendet: Donnerstag, 13. Mai 2021 17:52 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Commit 4710
Yes I am pretty sure. Because I just recreated the map and it is the same again. https://openmtbmap.org/mtbaustria_4709.exe vs https://openmtbmap.org/mtbaustria_4711.exe. (same FID/PID need to change to another to have both in Basecamp) in windows format soon. Here is one route that is different. Use with bicycle profile without any restrictions / avoidances set and shorter distance.
On Thu, 13 May 2021 at 21:14, Gerd Petermann < gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>> wrote: Hi all,
I fear I've totally forgotten the case of extended line types. I think the current code doesn't write the direction flag for them and I don't know if they can have a direction.
Gerd
________________________________________ Von: Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com>> Gesendet: Donnerstag, 13. Mai 2021 14:33 An: Development list for mkgmap Betreff: AW: [mkgmap-dev] Commit 4710
Hi Felix,
are you sure that you tested the two versions with exactly the same input? (osm data, style, options)? If the changes in r4710 or r4711 really cause differences in routing quality there must be an error, either in my understanding or in the code. Maybe you can post links to two tiles where routing differs?
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: Donnerstag, 13. Mai 2021 14:24 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Commit 4710
Yes, 4711 on branch vs best version 4709 on branch. 4709 was best so far.
On Thu, 13 May 2021, 19:37 Gerd Petermann <gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com><mailto: gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>> wrote: Hi Felix,
you totally lost me. There is no version r4713 in the branch. It seems you report the version number that svn shows after an svn update? That's not relevant, you must use svn info to find out the version of your branch. svn update always shows the latest commit, no matter in what branch it was made.
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: Donnerstag, 13. Mai 2021 13:16 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Commit 4710
I just looked it up. It must have been 4709 with best routing for me (unlikely but maybe it could have been 4708), while 4711 is a bit worse (but better than before the first changes that made an impact on routing). Both from low-res-opt branch. I haven't tried trunk for quite a while.
On Thu, 13 May 2021 at 17:42, Gerd Petermann < gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com
<mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com><mailto: gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>> wrote: Hi Felix,
please tell me exactly which versions you tested reg. routing. Note that the branches do not yet contain the latest changes in trunk.
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>><mailto: 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>><mailto: extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto: extremecarver@gmail.com<mailto:extremecarver@gmail.com>>>> Gesendet: Donnerstag, 13. Mai 2021 11:28 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Commit 4710
Well I just got to test routing - and the current version is a degradation vs the intermediate version from yesterday for my maps. The current version routes better than before, but worse than the intermediate version.
As for the list - it is a bit more complicated inside the style but doable. I really do not know what happens to those ways where I first set a direction for an downhill only way with higher priority, then remove the direction for a way that can be used in both directions at lower priority. Maybe sometimes also doing this the other way around. A list with type and max resolution used would be much easier for writing your style. Instead of adding 60-100 lines with the filter it would be done with 10 or so. Canals should not have a direction, they do not flow. Sidewalk=left, right is the same as for the various cylceway,cycletrack options - those are really not reversible. The underlying way could be reversed however - and I guess they are only used for level 0. Oneway arrows for streets are maybe used from resoltuion 24-22 or 24 only. Cliffs are also only high resolution. For me rivers are the only thing which really go into lower resolutions.
On Thu, 13 May 2021 at 16:03, Gerd Petermann < gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com
<mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com><mailto: gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com
<mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com>><mailto: gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com>>>>> wrote: Hi Felix,
FYI: I just found out that the current code to detect if the style sets mkgmap:has-direction=true doesn't work. Seems I didn't test this :( The change in r4710 changed only the LineMerger in the branch. Even with r4711 LineMerger only merges roads in maps without NET, at least that's what's intended.
My understanding is that r4703 changed routing, possibly also r4704. The merge from trunk also changed routing in the branches (r4706 and r4707).
I'm now fixing the detection code, next I'm trying to figure out how to configure the details reg. direction handling.
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>><mailto: 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>>><mailto: 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>><mailto: 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>><mailto: extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto: extremecarver@g mail.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><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com>>>>> Gesendet: Donnerstag, 13. Mai 2021 09:52 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Commit 4710
I kinda feel by default even oneway=yes should only mean do not change direction for level 0. If someone uses a style to have arrows showing the oneway, then only for that arrow line (defined by tag) the direction cannot be reversed. Yes the problem of DP filter rests - I feel this does not matter for resolution 24 and even 23, but if you display arrows for resolution 22 or higher then a tag should not merge the underlying lines. Besides rivers (then also many styles do not have an arrow for rivers, or you could decide to show the arrows only at resolution 24 and 23) few lines will be objection dependent.
I will try out now if there is any change in routing - but I will only write again if there unexpectedly is. The sharp angles changed routing for the better for my maps by quite a lot. So maybe with now some less lines being merged, there actually will be a little change for the worse back to the old behavior. Not sure..
On Thu, 13 May 2021 at 14:07, Gerd Petermann < gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com
<mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com><mailto: gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com
<mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com>><mailto: gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com>>>><mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com><mailto: gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com>>><m ailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com>><mailto: gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com>>>>>> wrote: Hi Felix,
yes, size increases if your style sets mkgmap:has-direction=true. I just want to make sure that the direction flag is treated correctly first. As already discussed we might introduce a new option or tag to tell mkgmap the min. level at which the direction has to be kept. You suggested to ignore direction at level > 0, I think it might depend on the style and TYP. I'll play with the OFM style to find out more.
The change should not affect routing at all (none of the changes in the low-res-opt branch should).
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>><mailto: 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>>><mailto: 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>><mailto: 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>>>><mailto: 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>><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mail to: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<mailto: 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<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>><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<mailto:extremecarver@gmail.com>><mailto: extremecarver@g<mailto:extremecarver@g> mail.com<http://mail.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<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>><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com>>>>>> Gesendet: Donnerstag, 13. Mai 2021 02:59 An: Development list for mkgmap Betreff: [mkgmap-dev] Commit 4710
fix error in LineMergeFilter reg. lines with direction The line merger should not merge lines if one has the direction flag set and the other has not. Problem exists also in trunk.
Hmm fixing this stopped all the nice size optimization. Map size got much bigger again. I did not find any place where this mattered. Routing was also not affected badly. Maybe I did not look good enough?
I do not see why not to merge them. As long as it`s not the opposite it seems fine... Map size increase/decrease is around 1.5% with my style. So thats quite a big difference. -- 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>><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 <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><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<mailto:mkgmap-dev@lists.mkgmap.or g.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
_______________________________________________ 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
<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<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<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
_______________________________________________ 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
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, I also tried with Basecamp (Version 4.7.3) It seems we have very different programs? I did this: 1) Open Basecamp, press Ctrl+G two times to clear caches for map "omtb_austria_13.05.2021" 2) drag&dropped "St. Pölten111 to B32012.gdb" into Basecamp and opened it with a double click. Route shows "Total distance 179 km." 3) Click on recalculate button, new route looks very different and is 274 km . Can't say for sure which version is installed right now (4009 or 4011), but I think the difference should not be that large? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver@gmail.com> Gesendet: Freitag, 14. Mai 2021 10:38 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Commit 4710 I never tested Mapsource, only Basecamp. Routing in Basecamp is much more similar to modern devices. But I just noticed that by accident I had faster time activated, and not shorter distance. On shorter distance the differences pop up much less often. Here is a route that also routes different with shorter distance. On Fri, 14 May 2021 at 16:31, Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>> wrote: Hi Felix, I cannot reproduce your results. For me, both maps seem to give the same routing result in Mapsource: a route that is much longer than yours (146 km instead of 129) . Do you use non-standard driving-speeds? 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: Donnerstag, 13. Mai 2021 17:52 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Commit 4710 Yes I am pretty sure. Because I just recreated the map and it is the same again. https://openmtbmap.org/mtbaustria_4709.exe vs https://openmtbmap.org/mtbaustria_4711.exe. (same FID/PID need to change to another to have both in Basecamp) in windows format soon. Here is one route that is different. Use with bicycle profile without any restrictions / avoidances set and shorter distance. On Thu, 13 May 2021 at 21:14, Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>> wrote: Hi all, I fear I've totally forgotten the case of extended line types. I think the current code doesn't write the direction flag for them and I don't know if they can have a direction. Gerd ________________________________________ Von: Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>> Gesendet: Donnerstag, 13. Mai 2021 14:33 An: Development list for mkgmap Betreff: AW: [mkgmap-dev] Commit 4710 Hi Felix, are you sure that you tested the two versions with exactly the same input? (osm data, style, options)? If the changes in r4710 or r4711 really cause differences in routing quality there must be an error, either in my understanding or in the code. Maybe you can post links to two tiles where routing differs? 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: Donnerstag, 13. Mai 2021 14:24 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Commit 4710 Yes, 4711 on branch vs best version 4709 on branch. 4709 was best so far. On Thu, 13 May 2021, 19:37 Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>> wrote: Hi Felix, you totally lost me. There is no version r4713 in the branch. It seems you report the version number that svn shows after an svn update? That's not relevant, you must use svn info to find out the version of your branch. svn update always shows the latest commit, no matter in what branch it was made. 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>><mailto: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>><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>>> Gesendet: Donnerstag, 13. Mai 2021 13:16 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Commit 4710 I just looked it up. It must have been 4709 with best routing for me (unlikely but maybe it could have been 4708), while 4711 is a bit worse (but better than before the first changes that made an impact on routing). Both from low-res-opt branch. I haven't tried trunk for quite a while. On Thu, 13 May 2021 at 17:42, Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>>> wrote: Hi Felix, please tell me exactly which versions you tested reg. routing. Note that the branches do not yet contain the latest changes in trunk. 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>><mailto: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>>><mailto: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>><mailto: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>><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<mailto:extremecarver@gmail.com>><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>>>> Gesendet: Donnerstag, 13. Mai 2021 11:28 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Commit 4710 Well I just got to test routing - and the current version is a degradation vs the intermediate version from yesterday for my maps. The current version routes better than before, but worse than the intermediate version. As for the list - it is a bit more complicated inside the style but doable. I really do not know what happens to those ways where I first set a direction for an downhill only way with higher priority, then remove the direction for a way that can be used in both directions at lower priority. Maybe sometimes also doing this the other way around. A list with type and max resolution used would be much easier for writing your style. Instead of adding 60-100 lines with the filter it would be done with 10 or so. Canals should not have a direction, they do not flow. Sidewalk=left, right is the same as for the various cylceway,cycletrack options - those are really not reversible. The underlying way could be reversed however - and I guess they are only used for level 0. Oneway arrows for streets are maybe used from resoltuion 24-22 or 24 only. Cliffs are also only high resolution. For me rivers are the only thing which really go into lower resolutions. On Thu, 13 May 2021 at 16:03, Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>>>> wrote: Hi Felix, FYI: I just found out that the current code to detect if the style sets mkgmap:has-direction=true doesn't work. Seems I didn't test this :( The change in r4710 changed only the LineMerger in the branch. Even with r4711 LineMerger only merges roads in maps without NET, at least that's what's intended. My understanding is that r4703 changed routing, possibly also r4704. The merge from trunk also changed routing in the branches (r4706 and r4707). I'm now fixing the detection code, next I'm trying to figure out how to configure the details reg. direction handling. 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>><mailto: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>>><mailto: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>><mailto: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>>>><mailto: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>><mailto: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>>><mailto: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>><mailto: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>><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<mailto:extremecarver@gmail.com>><mailto:extremecarver@g<mailto:extremecarver@g> mail.com<http://mail.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<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>><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>>>>> Gesendet: Donnerstag, 13. Mai 2021 09:52 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Commit 4710 I kinda feel by default even oneway=yes should only mean do not change direction for level 0. If someone uses a style to have arrows showing the oneway, then only for that arrow line (defined by tag) the direction cannot be reversed. Yes the problem of DP filter rests - I feel this does not matter for resolution 24 and even 23, but if you display arrows for resolution 22 or higher then a tag should not merge the underlying lines. Besides rivers (then also many styles do not have an arrow for rivers, or you could decide to show the arrows only at resolution 24 and 23) few lines will be objection dependent. I will try out now if there is any change in routing - but I will only write again if there unexpectedly is. The sharp angles changed routing for the better for my maps by quite a lot. So maybe with now some less lines being merged, there actually will be a little change for the worse back to the old behavior. Not sure.. On Thu, 13 May 2021 at 14:07, Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>><m ailto:gpetermann_muenchen@hotmail.com<mailto:ailto%3Agpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>>>>> wrote: Hi Felix, yes, size increases if your style sets mkgmap:has-direction=true. I just want to make sure that the direction flag is treated correctly first. As already discussed we might introduce a new option or tag to tell mkgmap the min. level at which the direction has to be kept. You suggested to ignore direction at level > 0, I think it might depend on the style and TYP. I'll play with the OFM style to find out more. The change should not affect routing at all (none of the changes in the low-res-opt branch should). 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>><mailto: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>>><mailto: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>><mailto: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>>>><mailto: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>><mailto: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>>><mailto: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>><mailto: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>>>>><mailto: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>><mailto: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>>><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mail to:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:to%3Amkgmap-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<mailto: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<mailto: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<mailto: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<mailto: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<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>><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<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><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@g<mailto:extremecarver@g><mailto:extremecarver@g<mailto:extremecarver@g>> mail.com<http://mail.com><http://mail.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<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><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<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>>><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<mailto:extremecarver@gmail.com>>>>>>> Gesendet: Donnerstag, 13. Mai 2021 02:59 An: Development list for mkgmap Betreff: [mkgmap-dev] Commit 4710 fix error in LineMergeFilter reg. lines with direction The line merger should not merge lines if one has the direction flag set and the other has not. Problem exists also in trunk. Hmm fixing this stopped all the nice size optimization. Map size got much bigger again. I did not find any place where this mattered. Routing was also not affected badly. Maybe I did not look good enough? I do not see why not to merge them. As long as it`s not the opposite it seems fine... Map size increase/decrease is around 1.5% with my style. So thats quite a big difference. -- 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>><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<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><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<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>>>>><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<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><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.or<mailto:mkgmap-dev@lists.mkgmap.or> g.uk<http://g.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<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 _______________________________________________ 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>>><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<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><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<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 _______________________________________________ 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>>><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<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<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 _______________________________________________ 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 _______________________________________________ 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
Maybe the second route is now with shorter distance instead of shorter time. It's bicycle with either shorter time or distance and no avoidances at all. And I use the most up to date Basecamp Version too. Anyway part of the reason was that 4709 routed against oneway direction 2 times I think. Maybe those roads were wrongly turned around or sometimes I enable very low priority routing against oneway and it chose that. Would need to check in mapedit. I just install both at the same time by changing fid and registry family name of one map with mapsettoolkit.in shorter time the difference appears more often on long routes. On Fri, 14 May 2021, 18:07 Gerd Petermann <gpetermann_muenchen@hotmail.com> wrote:
Hi Felix,
I also tried with Basecamp (Version 4.7.3) It seems we have very different programs? I did this: 1) Open Basecamp, press Ctrl+G two times to clear caches for map "omtb_austria_13.05.2021" 2) drag&dropped "St. Pölten111 to B32012.gdb" into Basecamp and opened it with a double click. Route shows "Total distance 179 km." 3) Click on recalculate button, new route looks very different and is 274 km .
Can't say for sure which version is installed right now (4009 or 4011), but I think the difference should not be that large?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver@gmail.com> Gesendet: Freitag, 14. Mai 2021 10:38 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Commit 4710
I never tested Mapsource, only Basecamp. Routing in Basecamp is much more similar to modern devices. But I just noticed that by accident I had faster time activated, and not shorter distance. On shorter distance the differences pop up much less often.
Here is a route that also routes different with shorter distance.
On Fri, 14 May 2021 at 16:31, Gerd Petermann < gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>> wrote: Hi Felix,
I cannot reproduce your results. For me, both maps seem to give the same routing result in Mapsource: a route that is much longer than yours (146 km instead of 129) . Do you use non-standard driving-speeds?
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: Donnerstag, 13. Mai 2021 17:52 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Commit 4710
Yes I am pretty sure. Because I just recreated the map and it is the same again. https://openmtbmap.org/mtbaustria_4709.exe vs https://openmtbmap.org/mtbaustria_4711.exe. (same FID/PID need to change to another to have both in Basecamp) in windows format soon. Here is one route that is different. Use with bicycle profile without any restrictions / avoidances set and shorter distance.
On Thu, 13 May 2021 at 21:14, Gerd Petermann < gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com
<mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com>>> wrote: Hi all,
I fear I've totally forgotten the case of extended line types. I think the current code doesn't write the direction flag for them and I don't know if they can have a direction.
Gerd
________________________________________ Von: Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com>>> Gesendet: Donnerstag, 13. Mai 2021 14:33 An: Development list for mkgmap Betreff: AW: [mkgmap-dev] Commit 4710
Hi Felix,
are you sure that you tested the two versions with exactly the same input? (osm data, style, options)? If the changes in r4710 or r4711 really cause differences in routing quality there must be an error, either in my understanding or in the code. Maybe you can post links to two tiles where routing differs?
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: Donnerstag, 13. Mai 2021 14:24 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Commit 4710
Yes, 4711 on branch vs best version 4709 on branch. 4709 was best so far.
On Thu, 13 May 2021, 19:37 Gerd Petermann <gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com><mailto: gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com
<mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com>>>> wrote: Hi Felix,
you totally lost me. There is no version r4713 in the branch. It seems you report the version number that svn shows after an svn update? That's not relevant, you must use svn info to find out the version of your branch. svn update always shows the latest commit, no matter in what branch it was made.
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>><mailto: 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>><mailto: extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto: extremecarver@gmail.com<mailto:extremecarver@gmail.com>>>> Gesendet: Donnerstag, 13. Mai 2021 13:16 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Commit 4710
I just looked it up. It must have been 4709 with best routing for me (unlikely but maybe it could have been 4708), while 4711 is a bit worse (but better than before the first changes that made an impact on routing). Both from low-res-opt branch. I haven't tried trunk for quite a while.
On Thu, 13 May 2021 at 17:42, Gerd Petermann < gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com
<mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com><mailto: gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com
<mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com>><mailto: gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com>>>>> wrote: Hi Felix,
please tell me exactly which versions you tested reg. routing. Note that the branches do not yet contain the latest changes in trunk.
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>><mailto: 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>>><mailto: 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>><mailto: 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>><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<mailto:extremecarver@gmail.com>><mailto: extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto: extremecarver@gmail.com<mailto:extremecarver@gmail.com>>>>> Gesendet: Donnerstag, 13. Mai 2021 11:28 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Commit 4710
Well I just got to test routing - and the current version is a degradation vs the intermediate version from yesterday for my maps. The current version routes better than before, but worse than the intermediate version.
As for the list - it is a bit more complicated inside the style but doable. I really do not know what happens to those ways where I first set a direction for an downhill only way with higher priority, then remove the direction for a way that can be used in both directions at lower priority. Maybe sometimes also doing this the other way around. A list with type and max resolution used would be much easier for writing your style. Instead of adding 60-100 lines with the filter it would be done with 10 or so. Canals should not have a direction, they do not flow. Sidewalk=left, right is the same as for the various cylceway,cycletrack options - those are really not reversible. The underlying way could be reversed however - and I guess they are only used for level 0. Oneway arrows for streets are maybe used from resoltuion 24-22 or 24 only. Cliffs are also only high resolution. For me rivers are the only thing which really go into lower resolutions.
On Thu, 13 May 2021 at 16:03, Gerd Petermann < gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com
<mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com><mailto: gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com
<mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com>><mailto: gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com>>>><mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com><mailto: gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com>>><mailto: gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com><mailto: gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>>>> wrote: Hi Felix,
FYI: I just found out that the current code to detect if the style sets mkgmap:has-direction=true doesn't work. Seems I didn't test this :( The change in r4710 changed only the LineMerger in the branch. Even with r4711 LineMerger only merges roads in maps without NET, at least that's what's intended.
My understanding is that r4703 changed routing, possibly also r4704. The merge from trunk also changed routing in the branches (r4706 and r4707).
I'm now fixing the detection code, next I'm trying to figure out how to configure the details reg. direction handling.
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>><mailto: 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>>><mailto: 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>><mailto: 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>>>><mailto: 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>><mailto: 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>>><mailto: 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>><mailto: 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>><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<mailto:extremecarver@gmail.com>><mailto: extremecarver@g<mailto:extremecarver@g> mail.com<http://mail.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<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>><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com>>>>>> Gesendet: Donnerstag, 13. Mai 2021 09:52 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Commit 4710
I kinda feel by default even oneway=yes should only mean do not change direction for level 0. If someone uses a style to have arrows showing the oneway, then only for that arrow line (defined by tag) the direction cannot be reversed. Yes the problem of DP filter rests - I feel this does not matter for resolution 24 and even 23, but if you display arrows for resolution 22 or higher then a tag should not merge the underlying lines. Besides rivers (then also many styles do not have an arrow for rivers, or you could decide to show the arrows only at resolution 24 and 23) few lines will be objection dependent.
I will try out now if there is any change in routing - but I will only write again if there unexpectedly is. The sharp angles changed routing for the better for my maps by quite a lot. So maybe with now some less lines being merged, there actually will be a little change for the worse back to the old behavior. Not sure..
On Thu, 13 May 2021 at 14:07, Gerd Petermann < gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com
<mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com><mailto: gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com
<mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com>><mailto: gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com>>>><mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com><mailto: gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com>>><mailto: gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com><mailto: gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com
<mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com>><mailto: gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com>>><mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com><mailto: gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com>>>><m ailto:gpetermann_muenchen@hotmail.com<mailto: ailto%3Agpetermann_muenchen@hotmail.com><mailto: gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com>>><mailto: gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com><mailto: gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>>>>> wrote: Hi Felix,
yes, size increases if your style sets mkgmap:has-direction=true. I just want to make sure that the direction flag is treated correctly first. As already discussed we might introduce a new option or tag to tell mkgmap the min. level at which the direction has to be kept. You suggested to ignore direction at level > 0, I think it might depend on the style and TYP. I'll play with the OFM style to find out more.
The change should not affect routing at all (none of the changes in the low-res-opt branch should).
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>><mailto: 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>>><mailto: 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>><mailto: 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>>>><mailto: 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>><mailto: 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>>><mailto: 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>><mailto: 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>>>>><mailto: 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>><mailto: 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>>><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mail to:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: to%3Amkgmap-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<mailto: 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<mailto: 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<mailto: 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<mailto: 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<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>><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<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><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@g<mailto:extremecarver@g><mailto:extremecarver@g<mailto: extremecarver@g>> mail.com<http://mail.com><http://mail.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<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><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<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>>><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<mailto: extremecarver@gmail.com>>>>>>> Gesendet: Donnerstag, 13. Mai 2021 02:59 An: Development list for mkgmap Betreff: [mkgmap-dev] Commit 4710
fix error in LineMergeFilter reg. lines with direction The line merger should not merge lines if one has the direction flag set and the other has not. Problem exists also in trunk.
Hmm fixing this stopped all the nice size optimization. Map size got much bigger again. I did not find any place where this mattered. Routing was also not affected badly. Maybe I did not look good enough?
I do not see why not to merge them. As long as it`s not the opposite it seems fine... Map size increase/decrease is around 1.5% with my style. So thats quite a big difference. -- 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>><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 <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><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<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
<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<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><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.or<mailto:mkgmap-dev@lists.mkgmap.or> g.uk<http://g.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<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
_______________________________________________ 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
<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<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><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 <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
_______________________________________________ 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
<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<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<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
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
_______________________________________________ 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
Hi Felix, OK, seems recalculate ignores the settings in the gdb file and uses the global settings. I now get the same 179.12 km long route, but I get it with both maps and I don't see any difference. Can you point me to a place where the 4011 version is different? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver@gmail.com> Gesendet: Freitag, 14. Mai 2021 13:33 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Commit 4710 Maybe the second route is now with shorter distance instead of shorter time. It's bicycle with either shorter time or distance and no avoidances at all. And I use the most up to date Basecamp Version too. Anyway part of the reason was that 4709 routed against oneway direction 2 times I think. Maybe those roads were wrongly turned around or sometimes I enable very low priority routing against oneway and it chose that. Would need to check in mapedit. I just install both at the same time by changing fid and registry family name of one map with mapsettoolkit.in<http://mapsettoolkit.in> shorter time the difference appears more often on long routes. On Fri, 14 May 2021, 18:07 Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>> wrote: Hi Felix, I also tried with Basecamp (Version 4.7.3) It seems we have very different programs? I did this: 1) Open Basecamp, press Ctrl+G two times to clear caches for map "omtb_austria_13.05.2021" 2) drag&dropped "St. Pölten111 to B32012.gdb" into Basecamp and opened it with a double click. Route shows "Total distance 179 km." 3) Click on recalculate button, new route looks very different and is 274 km . Can't say for sure which version is installed right now (4009 or 4011), but I think the difference should not be that large? 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: Freitag, 14. Mai 2021 10:38 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Commit 4710 I never tested Mapsource, only Basecamp. Routing in Basecamp is much more similar to modern devices. But I just noticed that by accident I had faster time activated, and not shorter distance. On shorter distance the differences pop up much less often. Here is a route that also routes different with shorter distance. On Fri, 14 May 2021 at 16:31, Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>> wrote: Hi Felix, I cannot reproduce your results. For me, both maps seem to give the same routing result in Mapsource: a route that is much longer than yours (146 km instead of 129) . Do you use non-standard driving-speeds? 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: Donnerstag, 13. Mai 2021 17:52 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Commit 4710 Yes I am pretty sure. Because I just recreated the map and it is the same again. https://openmtbmap.org/mtbaustria_4709.exe vs https://openmtbmap.org/mtbaustria_4711.exe. (same FID/PID need to change to another to have both in Basecamp) in windows format soon. Here is one route that is different. Use with bicycle profile without any restrictions / avoidances set and shorter distance. On Thu, 13 May 2021 at 21:14, Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>> wrote: Hi all, I fear I've totally forgotten the case of extended line types. I think the current code doesn't write the direction flag for them and I don't know if they can have a direction. Gerd ________________________________________ Von: Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>> Gesendet: Donnerstag, 13. Mai 2021 14:33 An: Development list for mkgmap Betreff: AW: [mkgmap-dev] Commit 4710 Hi Felix, are you sure that you tested the two versions with exactly the same input? (osm data, style, options)? If the changes in r4710 or r4711 really cause differences in routing quality there must be an error, either in my understanding or in the code. Maybe you can post links to two tiles where routing differs? 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>><mailto: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>><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>>> Gesendet: Donnerstag, 13. Mai 2021 14:24 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Commit 4710 Yes, 4711 on branch vs best version 4709 on branch. 4709 was best so far. On Thu, 13 May 2021, 19:37 Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>>> wrote: Hi Felix, you totally lost me. There is no version r4713 in the branch. It seems you report the version number that svn shows after an svn update? That's not relevant, you must use svn info to find out the version of your branch. svn update always shows the latest commit, no matter in what branch it was made. 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>><mailto: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>>><mailto: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>><mailto: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>><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<mailto:extremecarver@gmail.com>><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>>>> Gesendet: Donnerstag, 13. Mai 2021 13:16 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Commit 4710 I just looked it up. It must have been 4709 with best routing for me (unlikely but maybe it could have been 4708), while 4711 is a bit worse (but better than before the first changes that made an impact on routing). Both from low-res-opt branch. I haven't tried trunk for quite a while. On Thu, 13 May 2021 at 17:42, Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>>>> wrote: Hi Felix, please tell me exactly which versions you tested reg. routing. Note that the branches do not yet contain the latest changes in trunk. 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>><mailto: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>>><mailto: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>><mailto: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>>>><mailto: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>><mailto: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>>><mailto: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>><mailto: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>><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<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><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<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>>>>>> Gesendet: Donnerstag, 13. Mai 2021 11:28 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Commit 4710 Well I just got to test routing - and the current version is a degradation vs the intermediate version from yesterday for my maps. The current version routes better than before, but worse than the intermediate version. As for the list - it is a bit more complicated inside the style but doable. I really do not know what happens to those ways where I first set a direction for an downhill only way with higher priority, then remove the direction for a way that can be used in both directions at lower priority. Maybe sometimes also doing this the other way around. A list with type and max resolution used would be much easier for writing your style. Instead of adding 60-100 lines with the filter it would be done with 10 or so. Canals should not have a direction, they do not flow. Sidewalk=left, right is the same as for the various cylceway,cycletrack options - those are really not reversible. The underlying way could be reversed however - and I guess they are only used for level 0. Oneway arrows for streets are maybe used from resoltuion 24-22 or 24 only. Cliffs are also only high resolution. For me rivers are the only thing which really go into lower resolutions. On Thu, 13 May 2021 at 16:03, Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>>>>> wrote: Hi Felix, FYI: I just found out that the current code to detect if the style sets mkgmap:has-direction=true doesn't work. Seems I didn't test this :( The change in r4710 changed only the LineMerger in the branch. Even with r4711 LineMerger only merges roads in maps without NET, at least that's what's intended. My understanding is that r4703 changed routing, possibly also r4704. The merge from trunk also changed routing in the branches (r4706 and r4707). I'm now fixing the detection code, next I'm trying to figure out how to configure the details reg. direction handling. 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>><mailto: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>>><mailto: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>><mailto: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>>>><mailto: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>><mailto: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>>><mailto: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>><mailto: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>>>>><mailto: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>><mailto: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>>><mailto: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>><mailto: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>>>><mailto: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>><mailto: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>>><mailto: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>><mailto: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>><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<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><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@g<mailto:extremecarver@g><mailto:extremecarver@g<mailto:extremecarver@g>> mail.com<http://mail.com><http://mail.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<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><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<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>>><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<mailto:extremecarver@gmail.com>>>>>>> Gesendet: Donnerstag, 13. Mai 2021 09:52 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Commit 4710 I kinda feel by default even oneway=yes should only mean do not change direction for level 0. If someone uses a style to have arrows showing the oneway, then only for that arrow line (defined by tag) the direction cannot be reversed. Yes the problem of DP filter rests - I feel this does not matter for resolution 24 and even 23, but if you display arrows for resolution 22 or higher then a tag should not merge the underlying lines. Besides rivers (then also many styles do not have an arrow for rivers, or you could decide to show the arrows only at resolution 24 and 23) few lines will be objection dependent. I will try out now if there is any change in routing - but I will only write again if there unexpectedly is. The sharp angles changed routing for the better for my maps by quite a lot. So maybe with now some less lines being merged, there actually will be a little change for the worse back to the old behavior. Not sure.. On Thu, 13 May 2021 at 14:07, Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>>><m ailto:gpetermann_muenchen@hotmail.com<mailto:ailto%3Agpetermann_muenchen@hotmail.com><mailto:ailto%3Agpetermann_muenchen@hotmail.com<mailto:ailto%253Agpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>>>>>> wrote: Hi Felix, yes, size increases if your style sets mkgmap:has-direction=true. I just want to make sure that the direction flag is treated correctly first. As already discussed we might introduce a new option or tag to tell mkgmap the min. level at which the direction has to be kept. You suggested to ignore direction at level > 0, I think it might depend on the style and TYP. I'll play with the OFM style to find out more. The change should not affect routing at all (none of the changes in the low-res-opt branch should). 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>><mailto: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>>><mailto: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>><mailto: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>>>><mailto: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>><mailto: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>>><mailto: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>><mailto: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>>>>><mailto: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>><mailto: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>>><mailto: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>><mailto: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>>>><mailto: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>><mailto: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>>><mailto: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>><mailto: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>>>>>><mailto: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>><mailto: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>>><mailto: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>><mailto: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>>>><mailto: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>><mail to:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:to%3Amkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:to%3Amkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:to%253Amkgmap-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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<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>><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<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><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<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>>>>><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<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><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>>><mailto:extremecarver@g<mailto:extremecarver@g><mailto:extremecarver@g<mailto:extremecarver@g>><mailto:extremecarver@g<mailto:extremecarver@g><mailto:extremecarver@g<mailto:extremecarver@g>>> mail.com<http://mail.com><http://mail.com><http://mail.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<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><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<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>><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<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><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<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>>>><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<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><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>>>>>>> Gesendet: Donnerstag, 13. Mai 2021 02:59 An: Development list for mkgmap Betreff: [mkgmap-dev] Commit 4710 fix error in LineMergeFilter reg. lines with direction The line merger should not merge lines if one has the direction flag set and the other has not. Problem exists also in trunk. Hmm fixing this stopped all the nice size optimization. Map size got much bigger again. I did not find any place where this mattered. Routing was also not affected badly. Maybe I did not look good enough? I do not see why not to merge them. As long as it`s not the opposite it seems fine... Map size increase/decrease is around 1.5% with my style. So thats quite a big difference. -- 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>><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<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><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<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>>>>><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<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><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<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>><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<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><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<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>>><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<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.or<mailto:mkgmap-dev@lists.mkgmap.or><mailto:mkgmap-dev@lists.mkgmap.or<mailto:mkgmap-dev@lists.mkgmap.or>> g.uk<http://g.uk><http://g.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<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><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<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 _______________________________________________ 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>>><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<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><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<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>><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<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><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<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 _______________________________________________ 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>>><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<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><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<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 _______________________________________________ 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>>><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<mailto: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<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 _______________________________________________ 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 _______________________________________________ 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
Hi Felix, another point: Is it possible that you create the overview map without the --x-force-reverse-merge option? I would expect that 4711 is smaller than 4009 since 4011 also reverses in LineMerger. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver@gmail.com> Gesendet: Freitag, 14. Mai 2021 13:33 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Commit 4710 Maybe the second route is now with shorter distance instead of shorter time. It's bicycle with either shorter time or distance and no avoidances at all. And I use the most up to date Basecamp Version too. Anyway part of the reason was that 4709 routed against oneway direction 2 times I think. Maybe those roads were wrongly turned around or sometimes I enable very low priority routing against oneway and it chose that. Would need to check in mapedit. I just install both at the same time by changing fid and registry family name of one map with mapsettoolkit.in<http://mapsettoolkit.in> shorter time the difference appears more often on long routes. On Fri, 14 May 2021, 18:07 Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>> wrote: Hi Felix, I also tried with Basecamp (Version 4.7.3) It seems we have very different programs? I did this: 1) Open Basecamp, press Ctrl+G two times to clear caches for map "omtb_austria_13.05.2021" 2) drag&dropped "St. Pölten111 to B32012.gdb" into Basecamp and opened it with a double click. Route shows "Total distance 179 km." 3) Click on recalculate button, new route looks very different and is 274 km . Can't say for sure which version is installed right now (4009 or 4011), but I think the difference should not be that large? 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: Freitag, 14. Mai 2021 10:38 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Commit 4710 I never tested Mapsource, only Basecamp. Routing in Basecamp is much more similar to modern devices. But I just noticed that by accident I had faster time activated, and not shorter distance. On shorter distance the differences pop up much less often. Here is a route that also routes different with shorter distance. On Fri, 14 May 2021 at 16:31, Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>> wrote: Hi Felix, I cannot reproduce your results. For me, both maps seem to give the same routing result in Mapsource: a route that is much longer than yours (146 km instead of 129) . Do you use non-standard driving-speeds? 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: Donnerstag, 13. Mai 2021 17:52 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Commit 4710 Yes I am pretty sure. Because I just recreated the map and it is the same again. https://openmtbmap.org/mtbaustria_4709.exe vs https://openmtbmap.org/mtbaustria_4711.exe. (same FID/PID need to change to another to have both in Basecamp) in windows format soon. Here is one route that is different. Use with bicycle profile without any restrictions / avoidances set and shorter distance. On Thu, 13 May 2021 at 21:14, Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>> wrote: Hi all, I fear I've totally forgotten the case of extended line types. I think the current code doesn't write the direction flag for them and I don't know if they can have a direction. Gerd ________________________________________ Von: Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>> Gesendet: Donnerstag, 13. Mai 2021 14:33 An: Development list for mkgmap Betreff: AW: [mkgmap-dev] Commit 4710 Hi Felix, are you sure that you tested the two versions with exactly the same input? (osm data, style, options)? If the changes in r4710 or r4711 really cause differences in routing quality there must be an error, either in my understanding or in the code. Maybe you can post links to two tiles where routing differs? 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>><mailto: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>><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>>> Gesendet: Donnerstag, 13. Mai 2021 14:24 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Commit 4710 Yes, 4711 on branch vs best version 4709 on branch. 4709 was best so far. On Thu, 13 May 2021, 19:37 Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>>> wrote: Hi Felix, you totally lost me. There is no version r4713 in the branch. It seems you report the version number that svn shows after an svn update? That's not relevant, you must use svn info to find out the version of your branch. svn update always shows the latest commit, no matter in what branch it was made. 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>><mailto: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>>><mailto: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>><mailto: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>><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<mailto:extremecarver@gmail.com>><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>>>> Gesendet: Donnerstag, 13. Mai 2021 13:16 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Commit 4710 I just looked it up. It must have been 4709 with best routing for me (unlikely but maybe it could have been 4708), while 4711 is a bit worse (but better than before the first changes that made an impact on routing). Both from low-res-opt branch. I haven't tried trunk for quite a while. On Thu, 13 May 2021 at 17:42, Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>>>> wrote: Hi Felix, please tell me exactly which versions you tested reg. routing. Note that the branches do not yet contain the latest changes in trunk. 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>><mailto: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>>><mailto: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>><mailto: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>>>><mailto: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>><mailto: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>>><mailto: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>><mailto: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>><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<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><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<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>>>>>> Gesendet: Donnerstag, 13. Mai 2021 11:28 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Commit 4710 Well I just got to test routing - and the current version is a degradation vs the intermediate version from yesterday for my maps. The current version routes better than before, but worse than the intermediate version. As for the list - it is a bit more complicated inside the style but doable. I really do not know what happens to those ways where I first set a direction for an downhill only way with higher priority, then remove the direction for a way that can be used in both directions at lower priority. Maybe sometimes also doing this the other way around. A list with type and max resolution used would be much easier for writing your style. Instead of adding 60-100 lines with the filter it would be done with 10 or so. Canals should not have a direction, they do not flow. Sidewalk=left, right is the same as for the various cylceway,cycletrack options - those are really not reversible. The underlying way could be reversed however - and I guess they are only used for level 0. Oneway arrows for streets are maybe used from resoltuion 24-22 or 24 only. Cliffs are also only high resolution. For me rivers are the only thing which really go into lower resolutions. On Thu, 13 May 2021 at 16:03, Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>>>>> wrote: Hi Felix, FYI: I just found out that the current code to detect if the style sets mkgmap:has-direction=true doesn't work. Seems I didn't test this :( The change in r4710 changed only the LineMerger in the branch. Even with r4711 LineMerger only merges roads in maps without NET, at least that's what's intended. My understanding is that r4703 changed routing, possibly also r4704. The merge from trunk also changed routing in the branches (r4706 and r4707). I'm now fixing the detection code, next I'm trying to figure out how to configure the details reg. direction handling. 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>><mailto: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>>><mailto: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>><mailto: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>>>><mailto: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>><mailto: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>>><mailto: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>><mailto: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>>>>><mailto: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>><mailto: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>>><mailto: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>><mailto: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>>>><mailto: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>><mailto: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>>><mailto: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>><mailto: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>><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<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><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@g<mailto:extremecarver@g><mailto:extremecarver@g<mailto:extremecarver@g>> mail.com<http://mail.com><http://mail.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<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><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<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>>><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<mailto:extremecarver@gmail.com>>>>>>> Gesendet: Donnerstag, 13. Mai 2021 09:52 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Commit 4710 I kinda feel by default even oneway=yes should only mean do not change direction for level 0. If someone uses a style to have arrows showing the oneway, then only for that arrow line (defined by tag) the direction cannot be reversed. Yes the problem of DP filter rests - I feel this does not matter for resolution 24 and even 23, but if you display arrows for resolution 22 or higher then a tag should not merge the underlying lines. Besides rivers (then also many styles do not have an arrow for rivers, or you could decide to show the arrows only at resolution 24 and 23) few lines will be objection dependent. I will try out now if there is any change in routing - but I will only write again if there unexpectedly is. The sharp angles changed routing for the better for my maps by quite a lot. So maybe with now some less lines being merged, there actually will be a little change for the worse back to the old behavior. Not sure.. On Thu, 13 May 2021 at 14:07, Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>>><m ailto:gpetermann_muenchen@hotmail.com<mailto:ailto%3Agpetermann_muenchen@hotmail.com><mailto:ailto%3Agpetermann_muenchen@hotmail.com<mailto:ailto%253Agpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>>>>>> wrote: Hi Felix, yes, size increases if your style sets mkgmap:has-direction=true. I just want to make sure that the direction flag is treated correctly first. As already discussed we might introduce a new option or tag to tell mkgmap the min. level at which the direction has to be kept. You suggested to ignore direction at level > 0, I think it might depend on the style and TYP. I'll play with the OFM style to find out more. The change should not affect routing at all (none of the changes in the low-res-opt branch should). 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>><mailto: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>>><mailto: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>><mailto: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>>>><mailto: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>><mailto: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>>><mailto: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>><mailto: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>>>>><mailto: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>><mailto: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>>><mailto: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>><mailto: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>>>><mailto: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>><mailto: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>>><mailto: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>><mailto: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>>>>>><mailto: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>><mailto: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>>><mailto: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>><mailto: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>>>><mailto: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>><mail to:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:to%3Amkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:to%3Amkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:to%253Amkgmap-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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<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>><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<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><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<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>>>>><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<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><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>>><mailto:extremecarver@g<mailto:extremecarver@g><mailto:extremecarver@g<mailto:extremecarver@g>><mailto:extremecarver@g<mailto:extremecarver@g><mailto:extremecarver@g<mailto:extremecarver@g>>> mail.com<http://mail.com><http://mail.com><http://mail.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<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><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<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>><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<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><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<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>>>><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<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><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>>>>>>> Gesendet: Donnerstag, 13. Mai 2021 02:59 An: Development list for mkgmap Betreff: [mkgmap-dev] Commit 4710 fix error in LineMergeFilter reg. lines with direction The line merger should not merge lines if one has the direction flag set and the other has not. Problem exists also in trunk. Hmm fixing this stopped all the nice size optimization. Map size got much bigger again. I did not find any place where this mattered. Routing was also not affected badly. Maybe I did not look good enough? I do not see why not to merge them. As long as it`s not the opposite it seems fine... Map size increase/decrease is around 1.5% with my style. So thats quite a big difference. -- 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>><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<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><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<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>>>>><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<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><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<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>><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<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><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<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>>><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<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.or<mailto:mkgmap-dev@lists.mkgmap.or><mailto:mkgmap-dev@lists.mkgmap.or<mailto:mkgmap-dev@lists.mkgmap.or>> g.uk<http://g.uk><http://g.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<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><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<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 _______________________________________________ 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>>><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<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><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<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>><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<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><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<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 _______________________________________________ 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>>><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<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><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<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 _______________________________________________ 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>>><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<mailto: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<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 _______________________________________________ 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 _______________________________________________ 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
HForget that about overview map. I looked at the wrong files. Overview Map is indeed much smaller with 4011. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com> Gesendet: Freitag, 14. Mai 2021 15:02 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Commit 4710 Hi Felix, another point: Is it possible that you create the overview map without the --x-force-reverse-merge option? I would expect that 4711 is smaller than 4009 since 4011 also reverses in LineMerger. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver@gmail.com> Gesendet: Freitag, 14. Mai 2021 13:33 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Commit 4710 Maybe the second route is now with shorter distance instead of shorter time. It's bicycle with either shorter time or distance and no avoidances at all. And I use the most up to date Basecamp Version too. Anyway part of the reason was that 4709 routed against oneway direction 2 times I think. Maybe those roads were wrongly turned around or sometimes I enable very low priority routing against oneway and it chose that. Would need to check in mapedit. I just install both at the same time by changing fid and registry family name of one map with mapsettoolkit.in<http://mapsettoolkit.in> shorter time the difference appears more often on long routes. On Fri, 14 May 2021, 18:07 Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>> wrote: Hi Felix, I also tried with Basecamp (Version 4.7.3) It seems we have very different programs? I did this: 1) Open Basecamp, press Ctrl+G two times to clear caches for map "omtb_austria_13.05.2021" 2) drag&dropped "St. Pölten111 to B32012.gdb" into Basecamp and opened it with a double click. Route shows "Total distance 179 km." 3) Click on recalculate button, new route looks very different and is 274 km . Can't say for sure which version is installed right now (4009 or 4011), but I think the difference should not be that large? 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: Freitag, 14. Mai 2021 10:38 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Commit 4710 I never tested Mapsource, only Basecamp. Routing in Basecamp is much more similar to modern devices. But I just noticed that by accident I had faster time activated, and not shorter distance. On shorter distance the differences pop up much less often. Here is a route that also routes different with shorter distance. On Fri, 14 May 2021 at 16:31, Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>> wrote: Hi Felix, I cannot reproduce your results. For me, both maps seem to give the same routing result in Mapsource: a route that is much longer than yours (146 km instead of 129) . Do you use non-standard driving-speeds? 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: Donnerstag, 13. Mai 2021 17:52 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Commit 4710 Yes I am pretty sure. Because I just recreated the map and it is the same again. https://openmtbmap.org/mtbaustria_4709.exe vs https://openmtbmap.org/mtbaustria_4711.exe. (same FID/PID need to change to another to have both in Basecamp) in windows format soon. Here is one route that is different. Use with bicycle profile without any restrictions / avoidances set and shorter distance. On Thu, 13 May 2021 at 21:14, Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>> wrote: Hi all, I fear I've totally forgotten the case of extended line types. I think the current code doesn't write the direction flag for them and I don't know if they can have a direction. Gerd ________________________________________ Von: Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>> Gesendet: Donnerstag, 13. Mai 2021 14:33 An: Development list for mkgmap Betreff: AW: [mkgmap-dev] Commit 4710 Hi Felix, are you sure that you tested the two versions with exactly the same input? (osm data, style, options)? If the changes in r4710 or r4711 really cause differences in routing quality there must be an error, either in my understanding or in the code. Maybe you can post links to two tiles where routing differs? 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>><mailto: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>><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>>> Gesendet: Donnerstag, 13. Mai 2021 14:24 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Commit 4710 Yes, 4711 on branch vs best version 4709 on branch. 4709 was best so far. On Thu, 13 May 2021, 19:37 Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>>> wrote: Hi Felix, you totally lost me. There is no version r4713 in the branch. It seems you report the version number that svn shows after an svn update? That's not relevant, you must use svn info to find out the version of your branch. svn update always shows the latest commit, no matter in what branch it was made. 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>><mailto: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>>><mailto: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>><mailto: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>><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<mailto:extremecarver@gmail.com>><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>>>> Gesendet: Donnerstag, 13. Mai 2021 13:16 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Commit 4710 I just looked it up. It must have been 4709 with best routing for me (unlikely but maybe it could have been 4708), while 4711 is a bit worse (but better than before the first changes that made an impact on routing). Both from low-res-opt branch. I haven't tried trunk for quite a while. On Thu, 13 May 2021 at 17:42, Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>>>> wrote: Hi Felix, please tell me exactly which versions you tested reg. routing. Note that the branches do not yet contain the latest changes in trunk. 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>><mailto: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>>><mailto: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>><mailto: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>>>><mailto: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>><mailto: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>>><mailto: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>><mailto: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>><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<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><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<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>>>>>> Gesendet: Donnerstag, 13. Mai 2021 11:28 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Commit 4710 Well I just got to test routing - and the current version is a degradation vs the intermediate version from yesterday for my maps. The current version routes better than before, but worse than the intermediate version. As for the list - it is a bit more complicated inside the style but doable. I really do not know what happens to those ways where I first set a direction for an downhill only way with higher priority, then remove the direction for a way that can be used in both directions at lower priority. Maybe sometimes also doing this the other way around. A list with type and max resolution used would be much easier for writing your style. Instead of adding 60-100 lines with the filter it would be done with 10 or so. Canals should not have a direction, they do not flow. Sidewalk=left, right is the same as for the various cylceway,cycletrack options - those are really not reversible. The underlying way could be reversed however - and I guess they are only used for level 0. Oneway arrows for streets are maybe used from resoltuion 24-22 or 24 only. Cliffs are also only high resolution. For me rivers are the only thing which really go into lower resolutions. On Thu, 13 May 2021 at 16:03, Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>>>>> wrote: Hi Felix, FYI: I just found out that the current code to detect if the style sets mkgmap:has-direction=true doesn't work. Seems I didn't test this :( The change in r4710 changed only the LineMerger in the branch. Even with r4711 LineMerger only merges roads in maps without NET, at least that's what's intended. My understanding is that r4703 changed routing, possibly also r4704. The merge from trunk also changed routing in the branches (r4706 and r4707). I'm now fixing the detection code, next I'm trying to figure out how to configure the details reg. direction handling. 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>><mailto: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>>><mailto: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>><mailto: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>>>><mailto: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>><mailto: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>>><mailto: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>><mailto: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>>>>><mailto: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>><mailto: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>>><mailto: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>><mailto: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>>>><mailto: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>><mailto: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>>><mailto: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>><mailto: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>><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<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><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@g<mailto:extremecarver@g><mailto:extremecarver@g<mailto:extremecarver@g>> mail.com<http://mail.com><http://mail.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<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><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<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>>><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<mailto:extremecarver@gmail.com>>>>>>> Gesendet: Donnerstag, 13. Mai 2021 09:52 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Commit 4710 I kinda feel by default even oneway=yes should only mean do not change direction for level 0. If someone uses a style to have arrows showing the oneway, then only for that arrow line (defined by tag) the direction cannot be reversed. Yes the problem of DP filter rests - I feel this does not matter for resolution 24 and even 23, but if you display arrows for resolution 22 or higher then a tag should not merge the underlying lines. Besides rivers (then also many styles do not have an arrow for rivers, or you could decide to show the arrows only at resolution 24 and 23) few lines will be objection dependent. I will try out now if there is any change in routing - but I will only write again if there unexpectedly is. The sharp angles changed routing for the better for my maps by quite a lot. So maybe with now some less lines being merged, there actually will be a little change for the worse back to the old behavior. Not sure.. On Thu, 13 May 2021 at 14:07, Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>>><m ailto:gpetermann_muenchen@hotmail.com<mailto:ailto%3Agpetermann_muenchen@hotmail.com><mailto:ailto%3Agpetermann_muenchen@hotmail.com<mailto:ailto%253Agpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>>>>>> wrote: Hi Felix, yes, size increases if your style sets mkgmap:has-direction=true. I just want to make sure that the direction flag is treated correctly first. As already discussed we might introduce a new option or tag to tell mkgmap the min. level at which the direction has to be kept. You suggested to ignore direction at level > 0, I think it might depend on the style and TYP. I'll play with the OFM style to find out more. The change should not affect routing at all (none of the changes in the low-res-opt branch should). 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>><mailto: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>>><mailto: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>><mailto: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>>>><mailto: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>><mailto: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>>><mailto: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>><mailto: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>>>>><mailto: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>><mailto: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>>><mailto: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>><mailto: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>>>><mailto: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>><mailto: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>>><mailto: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>><mailto: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>>>>>><mailto: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>><mailto: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>>><mailto: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>><mailto: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>>>><mailto: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>><mail to:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:to%3Amkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:to%3Amkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:to%253Amkgmap-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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<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>><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<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><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<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>>>>><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<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><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>>><mailto:extremecarver@g<mailto:extremecarver@g><mailto:extremecarver@g<mailto:extremecarver@g>><mailto:extremecarver@g<mailto:extremecarver@g><mailto:extremecarver@g<mailto:extremecarver@g>>> mail.com<http://mail.com><http://mail.com><http://mail.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<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><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<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>><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<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><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<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>>>><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<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><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>>>>>>> Gesendet: Donnerstag, 13. Mai 2021 02:59 An: Development list for mkgmap Betreff: [mkgmap-dev] Commit 4710 fix error in LineMergeFilter reg. lines with direction The line merger should not merge lines if one has the direction flag set and the other has not. Problem exists also in trunk. Hmm fixing this stopped all the nice size optimization. Map size got much bigger again. I did not find any place where this mattered. Routing was also not affected badly. Maybe I did not look good enough? I do not see why not to merge them. As long as it`s not the opposite it seems fine... Map size increase/decrease is around 1.5% with my style. So thats quite a big difference. -- 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>><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<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><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<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>>>>><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<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><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<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>><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<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><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<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>>><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<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.or<mailto:mkgmap-dev@lists.mkgmap.or><mailto:mkgmap-dev@lists.mkgmap.or<mailto:mkgmap-dev@lists.mkgmap.or>> g.uk<http://g.uk><http://g.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<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><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<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 _______________________________________________ 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>>><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<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><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<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>><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<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><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<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 _______________________________________________ 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>>><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<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><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<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 _______________________________________________ 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>>><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<mailto: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<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 _______________________________________________ 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 _______________________________________________ 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 _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi all, reading the discussion, I think it would be good to separate 2 cases: - routable roads with one-way attribute, - all lines which have direction. As for routing, I would assume, that all problems are resolved automatically and correctly by mkgmap. Routing is only valid at level 0. On lower resolution one-way attribute can be ignored by default. I don't see any problems here and I hope we could drop this case. Second case is more general an it include roads too. It is about preserving direction of a line to get a correct drawing on a map. This is dependent on a style and TYP. Basically style defines, which objects should preserve direction because graphics defined in TYP is not symmetrical. It seems obvious, that direction should be preserved at all levels. Now, if we get one-way road, we have 2 option. Leave it at default and allow for reverse merging at lower resolution. Or we can add "preserve-direction" attribute, and make it behave like any other line, that has direction. Which means no revers merging at lower resolution. I don't get the idea of a list of types with preserved direction. For me this attribute is defined in style and separate list, or even list as a part of style doesn't make sens. I would prefer to have all attributes directly in style at place, where I define object. It seems tedious to sync list, whenever I do a change to object in style. @Ticker My nuvi 3540 shows direction arrows on roads, when TYP doesn't override graphics. Older nuvis don't and I got no newer one to check. I have looked more carefully and I found that arrows are present on railroads too. This is probably due to mkgmap processing oneway=yes for railroad (actually tramway). I can't see anything on rivers, but river is a thin line and it is difficult to tell if anything is drawn over it. -- Best regards, Andrzej
I just noticed the version I uploaded from 4709 was not identical to the one I once created with I think 4709. However I do not know what I had done for that time. I cannot identify which mkgmap version I used for creating the smaller and better routing version - or what changes I had done (the style was definitely identical except for the addition on the set mkgmap:has-direction=yes tag for some lines). I tried going back a couple of versions but none produced a that much smaller (over 1%) download file (and while compressing differs each time, that is a tiny bit within 0.2% or so). That one routed better but I think it reversed some oneways it was not supposed to reverse. The routing from 4709 to 4715 on the lower resolution branch is absolutely identical. Scratching my head how I produced this version on the 12. May... https://openmtbmap.org/mtbaustria_merge.exe On Fri, 14 May 2021 at 22:51, Andrzej Popowski <popej@poczta.onet.pl> wrote:
Hi all,
reading the discussion, I think it would be good to separate 2 cases: - routable roads with one-way attribute, - all lines which have direction.
As for routing, I would assume, that all problems are resolved automatically and correctly by mkgmap. Routing is only valid at level 0. On lower resolution one-way attribute can be ignored by default. I don't see any problems here and I hope we could drop this case.
Second case is more general an it include roads too. It is about preserving direction of a line to get a correct drawing on a map. This is dependent on a style and TYP. Basically style defines, which objects should preserve direction because graphics defined in TYP is not symmetrical. It seems obvious, that direction should be preserved at all levels.
Now, if we get one-way road, we have 2 option. Leave it at default and allow for reverse merging at lower resolution. Or we can add "preserve-direction" attribute, and make it behave like any other line, that has direction. Which means no revers merging at lower resolution.
I don't get the idea of a list of types with preserved direction. For me this attribute is defined in style and separate list, or even list as a part of style doesn't make sens. I would prefer to have all attributes directly in style at place, where I define object. It seems tedious to sync list, whenever I do a change to object in style.
@Ticker My nuvi 3540 shows direction arrows on roads, when TYP doesn't override graphics. Older nuvis don't and I got no newer one to check. I have looked more carefully and I found that arrows are present on railroads too. This is probably due to mkgmap processing oneway=yes for railroad (actually tramway). I can't see anything on rivers, but river is a thin line and it is difficult to tell if anything is drawn over it.
-- 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
participants (4)
-
Andrzej Popowski -
Felix Hartmann -
Gerd Petermann -
Ticker Berkin