Hi Marko,
found a few special cases:
1) the new dead-end-check is done before merging roads, so sometimes the
reported way ids in the old RouteNode check refer to merged roads.
When you want to compare results you should use --x-no-mergeroads
so that you see the correct way ids.
2) The new check d
Hi Steve,
> Nice simple test case. I can reproduce on a similar version of mapsource
> that you used, but not on an older version.
>
> > I hope you can reproduce the problem and find out what goes wrong...
>
> Interestingly if set to shortest time and avoid u-turns, then it goes
> straight down w
Hi Gerd,
Nice simple test case. I can reproduce on a similar version of mapsource
that you used, but not on an older version.
I hope you can reproduce the problem and find out what goes wrong...
Interestingly if set to shortest time and avoid u-turns, then it goes
straight down w1, w2 and th
Hi Steve,
yes, it is an error. But how do you suggest to change mkgmap?
The default style uses 0xYY in lines and polygons file, as we don't
use extended types, and the range for YY is 00 to 3f for lines
and 00 to 7f for polygons, and sub types are not supported for them.
Should we interpret 0x3f0
On 02/01/14 22:00, GerdP wrote:
got no answer on the question what mkgmap should
do with a type like 0x11f in the lines file.
The current behaviour is that it quietly ignores
the error because it treats 0x11f like 0x1f.
I would say that it is an error.
I break the full type down as follows:
0
Hi all,
got no answer on the question what mkgmap should
do with a type like 0x11f in the lines file.
The current behaviour is that it quietly ignores
the error because it treats 0x11f like 0x1f.
I'd prefer to write an error message and
completely ignore the corresponding line in the style.
Ge
Hi,
>
> thanks for reporting! Without having had a detailed look at your test
> case it sounds like the same problem reported by Gerd:
> http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2013q4/019532.html
I forgot to report that changing the order of nodes did not change the
result in MapSource,
Hi Marko,
okay, thanks for the explanation. I'll look at the differences tomorrow.
Gerd
Marko Mäkelä wrote
> On Thu, Jan 02, 2014 at 11:19:06AM -0800, GerdP wrote:
>>Hi Marko,
>>
>>please check:
>>
>>Marko Mäkelä wrote
>>> * Different coordinates for the 13 old messages (as expected; this is
>>>
On Thu, Jan 02, 2014 at 11:19:06AM -0800, GerdP wrote:
Hi Marko,
please check:
Marko Mäkelä wrote
* Different coordinates for the 13 old messages (as expected; this is
thanks to the higher precision)
I don't yet see a reason for different coordinates. Did you really compare
the output one pr
Hi Marko,
please check:
Marko Mäkelä wrote
> * Different coordinates for the 13 old messages (as expected; this is
> thanks to the higher precision)
I don't yet see a reason for different coordinates. Did you really compare
the output one program execution?
Or did you use a different program
Gerd,
thanks for the review. I will wait a bit before committing to trunk, in
case someone has another opinion.
I think it is ok to ignore the restriction, because we have no other
code to interpret it.
My point is that there could be a style rule to interpret the
type=restriction relation
On Thu, Jan 02, 2014 at 04:27:23PM +0100, Gerd Petermann wrote:
attached is a patch for the high-prec-coord branch to perform the
dead-end-check in StyledConverter.
I did not remove the original code, so both tests are performed now. I
think this helps to find differences.
Thanks! This looks v
Hi Marko,
the patch looks good to me.
Typically there are only a few hundred relations in one tile, so I do not
expect
a big change in performance if we don't create objects for the very few
relations that we don't supprt.
I think it is ok to ignore the restriction, because we have no other cod
Version mkgmap-r2931 was committed by steve on Thu, 02 Jan 2014
Fix syntax typo in one of the headings.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Marko,
okay, let me know if the patch works for you.
Gerd
Marko Mäkelä wrote
> Hi Gerd,
>
>>>I figured out that it would be nice to display all tags of the
>>>dead-end oneway, like we do in MultiPolygonRelation, so that my mkgmap
>>>wrapper script could filter out any oneway warnings for h
There are a few restriction relations for "no through route" mapped in
Finland. These are a bit ambiguous, because it looks like there are
multiple possible routes, all of which are banned. These relations are
tagged with type=restriction, but not with any restriction=*.
For mkgmap, the issue
Hi Gerd,
I figured out that it would be nice to display all tags of the
dead-end oneway, like we do in MultiPolygonRelation, so that my mkgmap
wrapper script could filter out any oneway warnings for highway=service.
I am not sure if I got that right. If you want to suppress the
dead-end-chec
Hi all,
r2930 is now up to date:
r2930: apply modified version of link-pois-to-ways-v2.patch
r2929: slightly modified closed-equal-v2.patch
r2928 merge from trunk r2927
I will try to add a merge routine for shapes (maybe only selected
ones like buildings) and further code to remove wrong
angles c
Hi Marko,
Marko Mäkelä wrote
> I figured out that it would be nice to display all tags of the dead-end
> oneway, like we do in MultiPolygonRelation, so that my mkgmap wrapper
> script could filter out any oneway warnings for highway=service.
I am not sure if I got that right. If you want to
Hi Marko,
attached is a patch for the high-prec-coord branch to perform the
dead-end-check in StyledConverter.
I did not remove the original code, so both tests are performed
now. I think this helps to find differences.
Please note that both checks will not recognize restriction relations
which p
Hi
I tried it with "Mittelfranken" from
http://download.geofabrik.de/europe/germany/bayern.html
OK thanks. I tried with that file with the same result; the city is
on both buildings.
I've uploaded the relevant tile http://files.mkgmap.org.uk/detail/165
for others to try in case it is environ
Hi Gerd,
okay, I'll have a look at it during the next days.
Thanks!
BTW, the diagnostics is not completely useless as it is now; it does
include labels, which (when present) will identify the ways. But, in
addition to normally unnamed highway=service, there could be some ways
that are acci
Version mkgmap-r2927 was committed by gerd on Thu, 02 Jan 2014
Documentation: add more internal tags (prefixed with mkgmap:)
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
23 matches
Mail list logo
