[mkgmap-dev] 4179

Tue May 18 09:00:57 BST 2021

well as I said - I think it is actually good if they are reversed - so the
same route stays a longer time on the road. With the current versions this
works well - it seems all "copies" that can be reversed, are reversed. Even
though something is asysmetrical - it does not mean that they may not be
reversed. Only lines which really have oneway or show direction should
never be reversed.

On Tue, 18 May 2021 at 13:10, Gerd Petermann <
gpetermann_muenchen at hotmail.com> wrote:

> Hi Felix,
>
> reg. right/left mixed up: My understanding is that ALL line types which
> are used with/for overlays and are not symetrical should be marked as "has
> a direction". Unfortunately I don't know how to recognize them looking at
> the TYP file. If someone has an idea I could add code to produce the
> candidates for the --line-types-with-direction list.
>
> Maybe use only level 0 for routable lines (as the default style does with
> roundabouts). This presumes that your routable line types are rendered
> invisible.
> I see many non-routable lines with type 0x10508 which seems to be
> invisible?
>
> ________________________________________
> Von: mkgmap-dev <mkgmap-dev-bounces 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 kno
>  w 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
>
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>

-- 
Felix Hartman - Openmtbmap.org & VeloMap.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20210518/f856ca16/attachment-0001.html>