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).
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
Hi Gerd,
here example of lines, that shouldn't be merged:
https://www.openstreetmap.org/way/481106241
https://www.openstreetmap.org/way/481106244
https://www.openstreetmap.org/way/481106242
I have tested with mkgmap-low-res-opt-r4711 and it works correctly.
Lines are not merged with
Hi Andrzej,
yes, sure, the tag mkgmap:has-direction=true was only implemented for that.
Gerd
Von: mkgmap-dev im Auftrag von Andrzej
Popowski
Gesendet: Donnerstag, 13. Mai 2021 19:36
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] Commit
Hi Gerd,
it is clear, but I was thinking about something else, about merging
lines with reversed points. If mkgmap performs that kind of merging,
there should be an option to block reversing for a particular object
type. I got impression, that mkgmap:has-direction is a flag, that can be
Hi Andrzej,
not sure what you mean. There are three ways to tell mkgmap that a line has a
direction:
1) oneway=yes / oneway=-1
2) in polish (*.mp) format there is DirIndicator
3) mkgmap:has-direction=true (since r4703)
The flag is only written for lines with normal type, but maybe extended
Hi Gerd,
I don't know particulars about direction flag, that is written into img.
Maybe it gives some kind of protection against drawing a line in revers
direction? Would be nice to test, if it were possible.
Anyway, for me problem is about reversing a line by mkgmap. I think that
Hi all,
I fear I've totally forgotten the case of extended line types. I think the
current code doesn't write the direction flag for them and I don't know if they
can have a direction.
Gerd
Von: Gerd Petermann
Gesendet: Donnerstag, 13. Mai 2021 14:33
Hi Felix,
are you sure that you tested the two versions with exactly the same input? (osm
data, style, options)?
If the changes in r4710 or r4711 really cause differences in routing quality
there must be an error, either in my understanding or in the code.
Maybe you can post links to two tiles
Yes, 4711 on branch vs best version 4709 on branch. 4709 was best so far.
On Thu, 13 May 2021, 19:37 Gerd Petermann
wrote:
> Hi Felix,
>
> you totally lost me. There is no version r4713 in the branch.
> It seems you report the version number that svn shows after an svn update?
> That's not
Version mkgmap-r4714 was committed by gerd on Thu, 13 May 2021
improve code in containsAction
- don't check finalizeRule in ExpressionRule
- check single actions instead of combining them first (to avoid possible
matches created by combining)
Hi Felix,
you totally lost me. There is no version r4713 in the branch.
It seems you report the version number that svn shows after an svn update?
That's not relevant, you must use svn info to find out the version of your
branch.
svn update always shows the latest commit, no matter in what
I just looked it up. It must have been 4709 with best routing for me
(unlikely but maybe it could have been 4708), while 4711 is a bit worse
(but better than before the first changes that made an impact on routing).
Both from low-res-opt branch.
I haven't tried trunk for quite a while.
On Thu, 13
I tried 4713 current on branch Vs before the updates 12.05 on branch
On Thu, 13 May 2021, 17:42 Gerd Petermann
wrote:
> Hi Felix,
>
> please tell me exactly which versions you tested reg. routing.
> Note that the branches do not yet contain the latest changes in trunk.
>
> Gerd
>
>
Hi Felix,
please tell me exactly which versions you tested reg. routing.
Note that the branches do not yet contain the latest changes in trunk.
Gerd
Von: mkgmap-dev im Auftrag von Felix
Hartmann
Gesendet: Donnerstag, 13. Mai 2021 11:28
An: Development
Hi Andrzej,
the tag was introduced with r4703:
https://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap=4703
Some of the code didn't work until r4713:
https://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap=4713
Are there any situation, where mkgmap adds this tag by itself?
I might be
Well I just got to test routing - and the current version is a degradation
vs the intermediate version from yesterday for my maps. The current version
routes better than before, but worse than the intermediate version.
As for the list - it is a bit more complicated inside the style but doable.
I
Version mkgmap-r4713 was committed by gerd on Thu, 13 May 2021
fix check which detects if lines rules add or set special tag
mkgmap:has-direction=true.
Old code only found the case that the style checked if a line has the tag, as in
mkgmap:has-direction=true {echotags "direction"}
Don't invest
Hi all,
I've tried to modify my version of Minkos OFM Lite style to use new tag
mkgmap:has-direction=true. I should have done this earlier :(
Maybe Felix was right when he suggested to add a new option to specify a list
of types which have a direction:
Hi all,
I didn't know about mkgmap:has-direction. Good to see there is
possibility to protect direction of the line. Please note, there are
lines, which aren't roads but really have directions. Some example:
- waterway=river, stream, maybe canal, ditch too,
- natural=cliff,
-
Version mkgmap-r4712 was committed by gerd on Thu, 13 May 2021
fix error introduced with r4549: logged action rules did not contain target
e.g. instead of "[set mkgmap:country=${mkgmap:admin_level2};]" only "[set ]"
was logged
Probably only visible when logging or debugging, else this would have
Hi Felix,
FYI:
I just found out that the current code to detect if the style sets
mkgmap:has-direction=true doesn't work. Seems I didn't test this :(
The change in r4710 changed only the LineMerger in the branch. Even with r4711
LineMerger only merges roads in maps without NET, at least that's
I kinda feel by default even oneway=yes should only mean do not change
direction for level 0. If someone uses a style to have arrows showing the
oneway, then only for that arrow line (defined by tag) the direction cannot
be reversed. Yes the problem of DP filter rests - I feel this does not
matter
Hi Felix,
yes, size increases if your style sets mkgmap:has-direction=true. I just want
to make sure that the direction flag is treated correctly first.
As already discussed we might introduce a new option or tag to tell mkgmap the
min. level at which the direction has to be kept. You suggested
24 matches
Mail list logo
