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