Re: [mkgmap-dev] 4179
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_muenc...@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 im Auftrag von > Felix Hartmann > 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_muenc...@hotmail.com<mailto:gpetermann_muenc...@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-boun...@lists.mkgmap.org.uk>> im Auftrag von Felix Hartmann < > extremecar...@gmail.com<mailto:extremecar...@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 <mailto:extremecar...@gmail.com><mailto:extremecar...@gmail.com extremecar...@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_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com > ><mailto:gpetermann_muenc...@hotmail.com gpetermann_muenc...@hotmail.com>>> wrote: > Hi Felix, > > If a line has a direction (which means it should not be reversed) you have > to mark it as
Re: [mkgmap-dev] 4179
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 im Auftrag von Felix Hartmann 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 mailto:gpetermann_muenc...@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 mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>> im Auftrag von Felix Hartmann mailto:extremecar...@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 mailto:extremecar...@gmail.com><mailto:extremecar...@gmail.com<mailto:extremecar...@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 mailto:gpetermann_muenc...@hotmail.com><mailto:gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@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 mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk><mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk<mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>>> im Auftrag von Felix Hartmann mailto:extremecar...@gmail.com><mailto:extremecar...@gmail.com<mailto:extremecar...@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 reve
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_muenc...@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 im Auftrag von
> Felix Hartmann
> 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 <mailto:extremecar...@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_muenc...@hotmail.com<mailto:gpetermann_muenc...@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-boun...@lists.mkgmap.org.uk>> im Auftrag von Felix Hartmann <
> extremecar...@gmail.com<mailto:extremecar...@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
Re: [mkgmap-dev] 4179
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 im Auftrag von Felix
Hartmann
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
mailto:extremecar...@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
mailto:gpetermann_muenc...@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
mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>>
im Auftrag von Felix Hartmann
mailto:extremecar...@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
mailto:extremecar...@gmail.com><mailto:extremecar...@gmail.com<mailto:extremecar...@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 prett
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
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_muenc...@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 im Auftrag von
>> Felix Hartmann
>> 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 > <mailto:extremecar...@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 onl
Re: [mkgmap-dev] 4179
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_muenc...@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 im Auftrag von
> Felix Hartmann
> 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 <mailto:extremecar...@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 -
Re: [mkgmap-dev] 4179
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 im Auftrag von Felix
Hartmann
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
mailto:extremecar...@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
mailto:po...@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@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
--
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
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
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
> 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@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@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] 4179
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 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@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
Re: [mkgmap-dev] 4179
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@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] 4179
Hi Felix, no idea what you mean with "underlying roads/lines are merged for level 1 and higher". The RoadMerger merges roads which have the same attributes. Min- and max-resolution are also attributes which must match. The LineMerger still doesn't merge roads. Gerd Von: mkgmap-dev im Auftrag von Felix Hartmann Gesendet: Montag, 17. Mai 2021 18:33 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] 4179 I think Gerd said that now those underlying roads/lines are merged for level 1 and higher. He said to merge them until someone complains. Merging as in reversing their direction so longer segments can be merged. All roads that can be merged without changing direction are merged anyhow. Allow-reverse-merge does not reverse lines that have an direction tag set, or are listed in the option to exclude them (which sets direction for them). Without allow reverse merge no roads are reversed at all. With it any road that has no direction tag or oneway tag set will be reversed if it can improve the merge length. On Tue, 18 May 2021 at 00:27, Andrzej Popowski mailto:po...@poczta.onet.pl>> wrote: Hi Felix! > If the main road is merged but the direction dependant road not - then > at lower resolutions the DP filter will create a mess But direction dependent road are merged, aren't they? > And because I have lots of overview - E.g. oneway arrows, oneway > streets are loads, there is quite a difference in map size regarding > oneway roads being merged from resolution 23 onwards or not. As I understand, dropping has-direction attribute will allow to merge roads with reversing (when option allow-reverse-merge is active). This means that you can get arrows in wrong direction. Is this acceptable? -- Best regards, Andrzej ___ 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
Re: [mkgmap-dev] 4179
I think Gerd said that now those underlying roads/lines are merged for level 1 and higher. He said to merge them until someone complains. Merging as in reversing their direction so longer segments can be merged. All roads that can be merged without changing direction are merged anyhow. Allow-reverse-merge does not reverse lines that have an direction tag set, or are listed in the option to exclude them (which sets direction for them). Without allow reverse merge no roads are reversed at all. With it any road that has no direction tag or oneway tag set will be reversed if it can improve the merge length. On Tue, 18 May 2021 at 00:27, Andrzej Popowski wrote: > Hi Felix! > > > If the main road is merged but the direction dependant road not - then > > at lower resolutions the DP filter will create a mess > > But direction dependent road are merged, aren't they? > > > And because I have lots of overview - E.g. oneway arrows, oneway > > streets are loads, there is quite a difference in map size regarding > > oneway roads being merged from resolution 23 onwards or not. > > As I understand, dropping has-direction attribute will allow to merge > roads with reversing (when option allow-reverse-merge is active). This > means that you can get arrows in wrong direction. Is this acceptable? > > -- > 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 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] 4179
Hi Felix! > If the main road is merged but the direction dependant road not - then > at lower resolutions the DP filter will create a mess But direction dependent road are merged, aren't they? > And because I have lots of overview - E.g. oneway arrows, oneway > streets are loads, there is quite a difference in map size regarding > oneway roads being merged from resolution 23 onwards or not. As I understand, dropping has-direction attribute will allow to merge roads with reversing (when option allow-reverse-merge is active). This means that you can get arrows in wrong direction. Is this acceptable? -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] 4179
The case was that many of those roads are created by continue. If the main road is merged but the direction dependant road not - then at lower resolutions the DP filter will create a mess. This is only relevant for 21 or lower I feel. 22-24 it's all right. Most overlays will be right in that resolution. Even though I have loads of those overlays, luckily those that are direction dependent are only in resolution 24 and 23. Some people may have overlays at lower resolution however. All lines created with continue at resolution lower 23 are problematic concerning this matter. And because I have lots of overview - E.g. oneway arrows, oneway streets are loads, there is quite a difference in map size regarding oneway roads being merged from resolution 23 onwards or not. I think it makes up for around 1.5% map size. The 1.5% is not the problem, but that primary roads, highways and so on are usually mapped with two lines, and each one has oneway attached. Then quite a bit of the optimization is lost if those roads are not merged. As for me highways are not routable, I just delete the oneway in style before processing... Could skip that if non routable lines do not care for oneway. Same for railways (and railways as well are displayed to quite a low resolution. Fixed by deleting oneway for railway=* & highway!=* On Mon, 17 May 2021 at 18:39, Andrzej Popowski wrote: > Hi Felix, > > why don't make it simple? > > Routable roads with oneway=-1 have to be reversed. > Non-routable lines with oneway=-1 have to be reversed if has-direction > is present. > If has-direction is present, road is not reversible for merging at all > layers. > > I don't understand your suggestion for non-reversible road limited to > some resolutions. I can't imagine what is the use of it, but maybe you > have some example. Anyway, I see it like that: > - there are rare cases for it if any, > - even if the line remains non-reversible at all levels, there is not > much difference for a whole map, > - if you really need that kind of solution, you can create 2 different > objects for different layers. > > -- > 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 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] 4179
Hi Felix, why don't make it simple? Routable roads with oneway=-1 have to be reversed. Non-routable lines with oneway=-1 have to be reversed if has-direction is present. If has-direction is present, road is not reversible for merging at all layers. I don't understand your suggestion for non-reversible road limited to some resolutions. I can't imagine what is the use of it, but maybe you have some example. Anyway, I see it like that: - there are rare cases for it if any, - even if the line remains non-reversible at all levels, there is not much difference for a whole map, - if you really need that kind of solution, you can create 2 different objects for different layers. -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] 4179
Well I think we already list all lines which cannot be reversed in the line--types-with-direction, in addition to that roads with oneway cannot be reversed at level 0 (but at all other levels - in my opinion). lines that are not routable but have a oneway attribute, and are not listed - do not need to be evaluated for oneway at all IMHO. So also not needed to reverse oneway=-1 for them. But yes it likely does not matter much if afterwards they are reversed anyhow... 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. If no resolution given then assume they can be reversed. That is still the trickiest one. E.g. line--types-with-direction=0x0a(22), 0x10100(24) - 24 meaning any associated way can be reversed from resolution 23 onwards in order to be merged. If no resolution is given assume they can be reversed at any resolution. On Mon, 17 May 2021 at 15:46, Gerd Petermann < gpetermann_muenc...@hotmail.com> wrote: > Hi Felix, > > I don't understand what the problem is. > I think we agreed that the oneway tag should not influence the direction > flag for non-routable lines. Only the mkgmap:has-direction tag or the > --types-with-direction list should be evaluated. > Do we still agree about that? > > Is about the rules for oneway=-1 reg. left/right? Those lines clearly have > a direction, don't they? > > Gerd > > > Von: mkgmap-dev im Auftrag von > Felix Hartmann > Gesendet: Montag, 17. Mai 2021 08:09 > An: Development list for mkgmap > Betreff: Re: [mkgmap-dev] 4179 > > This in referring the the commit message. I think mkgmap in that case > simply should not reverse the lines at all. > I did not know that --allow-reverse-merge will be able to reverse them > again. But yes I think mkgmap could skip reversing such lines. Meaning only > look at oneway status for lines that are on the line--types-with-direction > list or routable. Doing that in style is rather complicated, and likely > using quite a lot of CPU cycles too. > > On Mon, 17 May 2021 at 13:43, Gerd Petermann < > gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com>> > wrote: > Hi Felix, > > "this is only needed ..." what exactly refers "this" to? > > oneway=-1 requires a reversing of roads because the IMG format doesn't > allow to store the information that it is a reversed oneway. > > The current code checks the oneway tag first. It does this since r2944, > see https://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap=2944 > It's probably not needed for lines without a direction and it might safe a > few cpu cycles to avoid that reversing. Anyhow, with --allow-reverse-merge > the order of points in lines without direction might be reversed again. > > Gerd > > > Von: mkgmap-dev mkgmap-dev-boun...@lists.mkgmap.org.uk>> im Auftrag von Felix Hartmann < > extremecar...@gmail.com<mailto:extremecar...@gmail.com>> > Gesendet: Montag, 17. Mai 2021 04:52 > An: Development list for mkgmap > Betreff: [mkgmap-dev] 4179 > > Hi Gerd > > oneway tag no longer influences the direction flag of non-routable lines. > Note that oneway=-1 still means line is reversed and oneway=yes is set. > > I think this is only needed if the linetype is listed under > --line-types-with-direction > If not listed here nor routable oneway=-1 is as irrelevant as oneway=yes > > I do not understand why we would have different handling of onway=yes and > oneway=-1 > Reversing the road should not be needed because it does not matter for the > layout, nor for the routing. > -- > 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 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] 4179
Hi Felix, I don't understand what the problem is. I think we agreed that the oneway tag should not influence the direction flag for non-routable lines. Only the mkgmap:has-direction tag or the --types-with-direction list should be evaluated. Do we still agree about that? Is about the rules for oneway=-1 reg. left/right? Those lines clearly have a direction, don't they? Gerd Von: mkgmap-dev im Auftrag von Felix Hartmann Gesendet: Montag, 17. Mai 2021 08:09 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] 4179 This in referring the the commit message. I think mkgmap in that case simply should not reverse the lines at all. I did not know that --allow-reverse-merge will be able to reverse them again. But yes I think mkgmap could skip reversing such lines. Meaning only look at oneway status for lines that are on the line--types-with-direction list or routable. Doing that in style is rather complicated, and likely using quite a lot of CPU cycles too. On Mon, 17 May 2021 at 13:43, Gerd Petermann mailto:gpetermann_muenc...@hotmail.com>> wrote: Hi Felix, "this is only needed ..." what exactly refers "this" to? oneway=-1 requires a reversing of roads because the IMG format doesn't allow to store the information that it is a reversed oneway. The current code checks the oneway tag first. It does this since r2944, see https://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap=2944 It's probably not needed for lines without a direction and it might safe a few cpu cycles to avoid that reversing. Anyhow, with --allow-reverse-merge the order of points in lines without direction might be reversed again. Gerd Von: mkgmap-dev mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>> im Auftrag von Felix Hartmann mailto:extremecar...@gmail.com>> Gesendet: Montag, 17. Mai 2021 04:52 An: Development list for mkgmap Betreff: [mkgmap-dev] 4179 Hi Gerd oneway tag no longer influences the direction flag of non-routable lines. Note that oneway=-1 still means line is reversed and oneway=yes is set. I think this is only needed if the linetype is listed under --line-types-with-direction If not listed here nor routable oneway=-1 is as irrelevant as oneway=yes I do not understand why we would have different handling of onway=yes and oneway=-1 Reversing the road should not be needed because it does not matter for the layout, nor for the routing. -- 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
Re: [mkgmap-dev] 4179
This in referring the the commit message. I think mkgmap in that case simply should not reverse the lines at all. I did not know that --allow-reverse-merge will be able to reverse them again. But yes I think mkgmap could skip reversing such lines. Meaning only look at oneway status for lines that are on the line--types-with-direction list or routable. Doing that in style is rather complicated, and likely using quite a lot of CPU cycles too. On Mon, 17 May 2021 at 13:43, Gerd Petermann < gpetermann_muenc...@hotmail.com> wrote: > Hi Felix, > > "this is only needed ..." what exactly refers "this" to? > > oneway=-1 requires a reversing of roads because the IMG format doesn't > allow to store the information that it is a reversed oneway. > > The current code checks the oneway tag first. It does this since r2944, > see https://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap=2944 > It's probably not needed for lines without a direction and it might safe a > few cpu cycles to avoid that reversing. Anyhow, with --allow-reverse-merge > the order of points in lines without direction might be reversed again. > > Gerd > > > Von: mkgmap-dev im Auftrag von > Felix Hartmann > Gesendet: Montag, 17. Mai 2021 04:52 > An: Development list for mkgmap > Betreff: [mkgmap-dev] 4179 > > Hi Gerd > > oneway tag no longer influences the direction flag of non-routable lines. > Note that oneway=-1 still means line is reversed and oneway=yes is set. > > I think this is only needed if the linetype is listed under > --line-types-with-direction > If not listed here nor routable oneway=-1 is as irrelevant as oneway=yes > > I do not understand why we would have different handling of onway=yes and > oneway=-1 > Reversing the road should not be needed because it does not matter for the > layout, nor for the routing. > -- > 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 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] 4179
Hi Felix, "this is only needed ..." what exactly refers "this" to? oneway=-1 requires a reversing of roads because the IMG format doesn't allow to store the information that it is a reversed oneway. The current code checks the oneway tag first. It does this since r2944, see https://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap=2944 It's probably not needed for lines without a direction and it might safe a few cpu cycles to avoid that reversing. Anyhow, with --allow-reverse-merge the order of points in lines without direction might be reversed again. Gerd Von: mkgmap-dev im Auftrag von Felix Hartmann Gesendet: Montag, 17. Mai 2021 04:52 An: Development list for mkgmap Betreff: [mkgmap-dev] 4179 Hi Gerd oneway tag no longer influences the direction flag of non-routable lines. Note that oneway=-1 still means line is reversed and oneway=yes is set. I think this is only needed if the linetype is listed under --line-types-with-direction If not listed here nor routable oneway=-1 is as irrelevant as oneway=yes I do not understand why we would have different handling of onway=yes and oneway=-1 Reversing the road should not be needed because it does not matter for the layout, nor for the routing. -- 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
