Hi WanMil,
the branch tries harder to avoid that such a small road is removed,
e.g. in some cases the way is made a bit longer, but
it still might happen that it is removed. I see a similar problem when this
short way e.g. a highway=steps.
Anyhow, the branch has another problem with your
Hi,
GerdP wrote
So, I will first check where the way segement gets lost.
well, this is quite special, and I am not sure where to fix it.
The input file contains no bbox, so mkgmap calculates
it (using 24 bit resolution). Later, the way -47698
is clipped against this bbox using high precision,
I was informed by an user, that the Freizeitkarte maps are by default in
marine mode. Has someone information which bit is set in this case and what
the default set by mkgmap is?
Cheers Klaus
--
View this message in context:
http://gis.19327.n5.nabble.com/mkgmap-and-marine-mode-tp5795133.html
Hi,
GerdP wrote
So, I will first check where the way segement gets lost.
well, this is quite special, and I am not sure where to fix it.
The input file contains no bbox, so mkgmap calculates
it (using 24 bit resolution). Later, the way -47698
is clipped against this bbox using high
Hi WanMil,
in the branch the problem occurs if the way is so short that
the two end points are highPrecEqual(). This is very unlikely,
as we talk about = 4 cm here.
The problem probably only occurs with ways close to the tile
boundary that are clipped. I don't know if we can save a route
Hi
I am thinking how to fix the problem with the very short way and the
relation. Do you think it is possible to detect that the short way
consists of two points with identical Garmin coords. In this case it
might be possible to change the restriction in such a way that the ways
Today I've
Hi Gerd,
Hi WanMil,
in the branch the problem occurs if the way is so short that
the two end points are highPrecEqual(). This is very unlikely,
as we talk about = 4 cm here.
Sounds great!
The problem probably only occurs with ways close to the tile
boundary that are clipped. I don't know
Hi WanMil,
The problem probably only occurs with ways close to the tile
boundary that are clipped. I don't know if we can save a route
restriction when the to-node or from-node lies outside of the boundary.
Would it solve the problem if the boundary nodes are added earlier just
before
Hi Steve,
yes, in the branch I changed the checks so that mkgmap only
complains when an arc starts and ends with the same node
(same node id). Maybe the solution would be to make sure
that all boundary nodes added by the clipper get unique coord instances,
so that they also get different node
Hi WanMil,
I am just guessing. Will have a closer look tomorrow.
Gerd
Date: Mon, 3 Feb 2014 20:19:46 +0100
From: wmgc...@web.de
To: mkgmap-dev@lists.mkgmap.org.uk
Subject: Re: [mkgmap-dev] Problem with turn restriction
Hi WanMil,
The problem probably only occurs with ways close
I want to make a small statistic why restriction relations become
invalid. Maybe the problem is so seldom that it's not worthy...
I have made a short stat with the high-prec branch:
There are around 850 relations that are valid
(RestrictionRelation.isValid() == true) after loading but that are
Hallo Klaus,
marine mode
If you look for charts in marine mode:
http://wiki.openstreetmap.org/wiki/OpenSeaMap_and_Garmin_nautical_chart_plotter
Has someone information which bit is set in this case
and what the default set by mkgmap is?
Jürgen Baumgartl may be can help.
Best regards,
I want to make a small statistic why restriction relations become
invalid. Maybe the problem is so seldom that it's not worthy...
I have made a short stat with the high-prec branch:
There are around 850 relations that are valid
(RestrictionRelation.isValid() == true) after loading but that are
WanMil wrote
I want to make a small statistic why restriction relations become
invalid. Maybe the problem is so seldom that it's not worthy...
I have made a short stat with the high-prec branch:
There are around 850 relations that are valid
(RestrictionRelation.isValid() == true) after
Hi Klaus,
I was informed by an user, that the Freizeitkarte maps are by default
in marine mode.
As far as I know Freizeitkarte maps are standard topo, not marine.
Has someone information which bit is set in this case and what
the default set by mkgmap is?
mkgmap writes in TRE header at
15 matches
Mail list logo