logo separator

[mkgmap-dev] 4179

From Gerd Petermann gpetermann_muenchen at hotmail.com on Tue May 18 06:10:23 BST 2021

Hi Felix,

reg. right/left mixed up: My understanding is that ALL line types which are used with/for overlays and are not symetrical should be marked as "has a direction". Unfortunately I don't know how to recognize them looking at the TYP file. If someone has an idea I could add code to produce the candidates for the --line-types-with-direction list.

Maybe use only level 0 for routable lines (as the default style does with roundabouts). This presumes that your routable line types are rendered invisible.
I see many non-routable lines with type 0x10508 which seems to be invisible?

________________________________________
Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver at gmail.com>
Gesendet: Montag, 17. Mai 2021 21:49
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] 4179

yes, but I am not sure which version got the the left right mixed up. I think that was the one that ended up being much smaller and better routing however not respecting the oneways correctly too. I do notice that from one compile to another mkgmap sometimes decide to reverse to opposite directions, but since 4709 it seems it always correctly handled the reversible roads to be changed consistently. 4709, 4711, 4715, and 4719 all seem to be correct - but how the DP filter works on roads is changing each version (or each compile). On the other hand lines seem to be very consistently handled. Kinda only visible by selecting lowest detail level in Basecamp. With lowest or lower and zooming out far the maps do look ugly. But I guess this cannot be avoided. Its fine as its much better as too detailled and slow - and usually a map should only be used in normal detail, or differ 1 step. Else the map is really badly designed. If on low resolution the map still looks good - that is fine (I know I could decrease DP filter to make it nicer looking).

On Tue, 18 May 2021 at 02:21, Gerd Petermann <gpetermann_muenchen at hotmail.com<mailto:gpetermann_muenchen at hotmail.com>> wrote:
Hi Felix,

the subject of this thread is 4179 (I guess you meant r4719). So, we are talking about this version, not any older or newer, right?

Gerd


________________________________________
Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces at lists.mkgmap.org.uk>> im Auftrag von Felix Hartmann <extremecarver at gmail.com<mailto:extremecarver at gmail.com>>
Gesendet: Montag, 17. Mai 2021 20:10
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] 4179

Some versions of mkgmap seemed to have created maps where this became a bit random. So sometimes (but rarely) the reversible mtb and hiking routes ended up on the same side of the road....

On Tue, 18 May 2021 at 02:08, Felix Hartmann <extremecarver at gmail.com<mailto:extremecarver at gmail.com><mailto:extremecarver at gmail.com<mailto:extremecarver at gmail.com>>> wrote:
Yes I know - I list lines which actually have direction in the list or assign direction.
My worries - and that changed from version to version a bit are the routes which do not matter which side they are on - but it has to be consistent and not random.

Meaning if the direction of a road/line is reversed - then either reverse all other copies of that object if you can reverse them (no direction tag) or do not reverse any. However not reverse the ones that appear after the line that is reversed, but do not reverse the ones that are before in the style. Now of course I could take routes into the non reverse list. However as I display them to low resolution, this would mean a lot of lines that would have better performance and nicer looking if reverse merged, but are not reverse merged because the underlying line maybe had a oneway set and unset, or is oneway and the position of other duplicate lines of that object are in a different position in my style file.

On Tue, 18 May 2021 at 01:43, Gerd Petermann <gpetermann_muenchen at hotmail.com<mailto:gpetermann_muenchen at hotmail.com><mailto:gpetermann_muenchen at hotmail.com<mailto:gpetermann_muenchen at hotmail.com>>> wrote:
Hi Felix,

If a line has a direction (which means it should not be reversed) you have to mark it as such.
There is no longer any automatism which tries to guess what you want.

Gerd

________________________________________
Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces at lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces at lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces at lists.mkgmap.org.uk>>> im Auftrag von Felix Hartmann <extremecarver at gmail.com<mailto:extremecarver at gmail.com><mailto:extremecarver at gmail.com<mailto:extremecarver at gmail.com>>>
Gesendet: Montag, 17. Mai 2021 19:38
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] 4179

Oh yeah - what may not happen is the following hypothetical example

1. route=mtb (set line) (can be merged and reversed)
2. highway=x (set road - is not reversed merged - maybe because of oneway tag)
3. route=hiking (set line - however because the 2. highway was not reversed, while the 1 route was reversed - this is now using a different direction than 1).

1. and 3. while being possible to be reversed - have to be reversed identical. (because in my style mtb routes are on the right side, hiking routes on the left side). 2. can be reversed because it is in the center. I do not are if 1. and 3 are exchanged. Meaning it is fine if they are left or right, but they are not allowed to be both left or both right. So they can be reversed, but if 1. is reversed, 3 had to be reversed to. I have quite a few such cases in my style and as long as the reversing is consistent, and not dependent on the order in the style, this is fine.


e.g this could create a problem?

1. route=mtb (can be reversed)
2. highway=oneway (downhill only at high priority) [set oneway=1} continue (sometimes with, sometimes without actions) - cannot be reversed because of oneway.
3. {delette oneway if for 2. continue with actions was used I use intermediary keys to restore an actual oneway should there have been one.}
3. route=hiking (can be reversed - but if it is reversed also route=mtb has to be reversed).

On Tue, 18 May 2021 at 01:28, Felix Hartmann <extremecarver at gmail.com<mailto:extremecarver at gmail.com><mailto:extremecarver at gmail.com<mailto:extremecarver at gmail.com>><mailto:extremecarver at gmail.com<mailto:extremecarver at gmail.com><mailto:extremecarver at gmail.com<mailto:extremecarver at gmail.com>>>> wrote:
I meant if there is a line created with continue - and that line is on the --line-types-with-direction
list, the other copies of that line Or roads should be merged too. And I think roads should be reversed and merged as much as possible to - also at resolution 24 if not oneway-1 or on the --line-types-with-direction with list. However some people may feel that is a single copy of that line is on the --line-types-with-direction list, then none of those copies should be merged at level 0, but maybe on other levels or none at no levels at all.
And I also use different linetypes for roads - so highways get thinner when zooming out. I think this makes a lot of sense for secondary to highway. Not soo much for others. That is anyhow why I feel roads only exist at level 0, from level 1 onwards there are only lines, not roads.

Now for one object in OSM I sometimes create up to 10 copies - 5 due to different level, 4 for additional features and 1 invisible line that is actually responsible for routing. Having the road invisible overcomes the problem that there are few routable line types - so only solution is to make many roads invisible and only map the very common ones to a visible line type. So there is a pretty big implication on the total size if due to one of those 10 copies having the direction set or oneway set, all other 9 cannot be reversed to be merged, or not be merged at all. Also the name is not identical. E.g. I will create one line for a mtb route, another line for a hiking route. Maybe even several lines so you can see all route names. Also several copies (up to 4, previously even more but in new generation devices that lead to crashes) are routable. Also helps in merging - if you have one road for a relation that always has the same name, only at intersections with other roads this cannot
 be merged. While if there are maybe changes in the name tag, or other subtleties less can be merged.

I really feel merge as much as possible and consider everything a line from level 1 onwards.

On Tue, 18 May 2021 at 01:02, Andrzej Popowski <popej at poczta.onet.pl<mailto:popej at poczta.onet.pl><mailto:popej at poczta.onet.pl<mailto:popej at poczta.onet.pl>><mailto:popej at poczta.onet.pl<mailto:popej at poczta.onet.pl><mailto:popej at poczta.onet.pl<mailto:popej at poczta.onet.pl>>>> wrote:
Hi Felix,

then what about proposed:

 > For  line--types-with-direction it would be best to give a resolution
 > limit for each type, so if resolution is lower than associated lines
 > can be reversed.

Does it means, that you accept wrong direction at lower resolution?

--
Best regards,
Andrzej
_______________________________________________
mkgmap-dev mailing list
mkgmap-dev at lists.mkgmap.org.uk<mailto:mkgmap-dev at lists.mkgmap.org.uk><mailto:mkgmap-dev at lists.mkgmap.org.uk<mailto:mkgmap-dev at lists.mkgmap.org.uk>><mailto:mkgmap-dev at lists.mkgmap.org.uk<mailto:mkgmap-dev at lists.mkgmap.org.uk><mailto:mkgmap-dev at lists.mkgmap.org.uk<mailto:mkgmap-dev at lists.mkgmap.org.uk>>>
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


--
Felix Hartman - Openmtbmap.org & VeloMap.org



--
Felix Hartman - Openmtbmap.org & VeloMap.org

_______________________________________________
mkgmap-dev mailing list
mkgmap-dev at lists.mkgmap.org.uk<mailto:mkgmap-dev at lists.mkgmap.org.uk><mailto:mkgmap-dev at lists.mkgmap.org.uk<mailto:mkgmap-dev at lists.mkgmap.org.uk>>
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


--
Felix Hartman - Openmtbmap.org & VeloMap.org



--
Felix Hartman - Openmtbmap.org & VeloMap.org

_______________________________________________
mkgmap-dev mailing list
mkgmap-dev at lists.mkgmap.org.uk<mailto:mkgmap-dev at lists.mkgmap.org.uk>
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


--
Felix Hartman - Openmtbmap.org & VeloMap.org



More information about the mkgmap-dev mailing list