[mkgmap-dev] 4179

Mon May 17 19:10:32 BST 2021

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>
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> 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> im Auftrag von
>> Felix Hartmann <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>> 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>> 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>
>> 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
>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>>
>
>
> --
> Felix Hartman - Openmtbmap.org & VeloMap.org
>
>

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