Hi all,
as Eric pointed out (1) in rare cases connected ways are rendered as
unconnected ways. Reason is an error in WrongAngleFixer which treats roads and
lines one after the other. Another problem I found are POIs which created with
the --link-pois-to-ways option (nodes with barrier=* or
-dev@lists.mkgmap.org.uk
Subject: Re: [mkgmap-dev] Distorted lines
I know this has been discussed a lot and it is annoying to see these
distortions but having seen Garmin's City Navigator maps with the same
problem, I fear there isn't much more we can expect of mkgmap...?
--
View
Hi Gerd
Sounds painful ; I like the analogy!
--
View this message in context:
http://gis.19327.n5.nabble.com/Distorted-lines-tp5831842p5831903.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
___
mkgmap-dev mailing list
I know this has been discussed a lot and it is annoying to see these
distortions but having seen Garmin's City Navigator maps with the same
problem, I fear there isn't much more we can expect of mkgmap...?
--
View this message in context:
Hi Enrico,
yes, just use that binary
reg. the changes please read this post:
http://gis.19327.n5.nabble.com/high-prec-branch-ready-for-trunk-tp5798370.html
Gerd
demon.box wrote
So I have only to use this mkgmap.jar (mkgmap-high-prec-coord-r3078)
instead of the official 3072 release?
There
So I have only to use this mkgmap.jar (mkgmap-high-prec-coord-r3078) instead
of the official 3072 release?
There isn't any particular option to set?
What is exactly the benefit?
Thanks very much.
--enrico
--
View this message in context:
the polygon rules
@WanMil:
Please review also the changes in the docu files, I am not sure
about the formatting rules.
Gerd
Date: Wed, 19 Feb 2014 21:57:26 +0100
From: wmgc...@web.de
To: mkgmap-dev@lists.mkgmap.org.uk
Subject: Re: [mkgmap-dev] Distorted lines
Hi Gerd,
at the moment I
% higher
I am working on a patch that adds arcs to major roads (as in Garmin maps),
this will increase size by maybe ~1% again.
Gerd
Date: Wed, 19 Feb 2014 17:54:58 +0100
From: o...@aighes.de
To: mkgmap-dev@lists.mkgmap.org.uk
Subject: Re: [mkgmap-dev] Distorted lines
Am 19.02.2014
Hi Andrzej,
sounds good. Are you also satisfied with the results?
Gerd
Date: Tue, 18 Feb 2014 20:13:47 +0100
From: po...@poczta.onet.pl
To: mkgmap-dev@lists.mkgmap.org.uk
Subject: Re: [mkgmap-dev] Distorted lines
Hi Gerd,
The message non-routable way xyz was removed is now
only
Hi Gerd,
Are you also satisfied with the results?
Sure, thanks. Railways look good.
I'm a bit worried about inconsistency. See this building:
http://www.openstreetmap.org/way/256598227
I have attached screenshot building-mkgmap.png. On my map this building
is drawn as an outline and a
Hi Andrzej,
seems that the garmin data is older.
Reg. polygon optimization:
When I started to implement that, I noticed problems with buildings
that share lines. Sometimes the lines were moved apart
because the algo optimized one poly after the other.
So I started to code that ShapeMergeFilter
Hi Gerd,
The correct solution that I have in mind requires a big
change in data structures, so I'd like to postpone that
because I want to merge the branch to trunk first.
I could guess it. Great you don't give up :)
--
Best regards,
Andrzej
___
Am 19.02.2014 10:26, schrieb Gerd Petermann:
Are you also satisfied with the results?
Absolutly! Looks smoother and maps are smaller, win-win-situation.
Thanks a lot,
Henning
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
Gerd, can you commit your coastline patch in the branch version?
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Minko,
committed with r3064.
Gerd
ligfietser wrote
Gerd, can you commit your coastline patch in the branch version?
___
mkgmap-dev mailing list
mkgmap-dev@.org
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
--
View this message
Hi Gerd,
I think this might cause problems.
In case you want to use polygons tagged with place=island you will lose
all islands that are also tagged as natural=coastline. This tagging is
described on the wiki page
(http://wiki.openstreetmap.org/wiki/Tag:place%3Disland).
I think the patch
Subject: Re: [mkgmap-dev] Distorted lines
Hi Gerd,
I think this might cause problems.
In case you want to use polygons tagged with place=island you will lose
all islands that are also tagged as natural=coastline. This tagging is
described on the wiki page
(http://wiki.openstreetmap.org/wiki
tag?
If yes, what would be a good tag for this?
Gerd
Date: Wed, 19 Feb 2014 21:00:46 +0100
From: wmgc...@web.de
To: mkgmap-dev@lists.mkgmap.org.uk
Subject: Re: [mkgmap-dev] Distorted lines
Hi Gerd,
I think this might cause problems.
In case you want to use polygons tagged
-dev@.org
Subject: Re: [mkgmap-dev] Distorted lines
Hi Gerd,
I think this might cause problems.
In case you want to use polygons tagged with place=island you will
lose
all islands that are also tagged as natural=coastline. This tagging is
described on the wiki page
that
Seagenerator deleted the natural=coastline tag?
If yes, what would be a good tag for this?
Gerd
Date: Wed, 19 Feb 2014 21:00:46 +0100
From:
wmgcnfg@
To:
mkgmap-dev@.org
Subject: Re: [mkgmap-dev] Distorted lines
Hi Gerd,
I think this might cause problems.
In case
@
To:
mkgmap-dev@.org
Subject: Re: [mkgmap-dev] Distorted lines
Hi Gerd,
I think this might cause problems.
In case you want to use polygons tagged with place=island you will
lose
all islands that are also tagged as natural=coastline. This tagging
is
described
...@poczta.onet.pl
To: mkgmap-dev@lists.mkgmap.org.uk
Subject: Re: [mkgmap-dev] Distorted lines
Hi Gerd,
sorry, the 10% smaller size is also not intended, I thought you
compared with trunk.
I have compared with trunk, 3057 is current release.
The way 101876024 is an extremely
Am 17.02.2014 10:12, schrieb Gerd Petermann:
I've added the code to optimize non-routable ways in r3059.
Your example looks much better now.
Hi Gerd,
I assume it's in the high-precision branch, and not in trunc?
Chris
___
mkgmap-dev mailing
Hi Gerd,
The message non-routable way xyz was removed is now
only printed if the original way has different points in map units,
and now it is just a warning.
no more error or warning messages with r3063.
--
Best regards,
Andrzej
___
mkgmap-dev
Hi Andrzej,
I've added the code to optimize non-routable ways in r3059.
Your example looks much better now.
Gerd
Date: Sat, 15 Feb 2014 17:32:23 +0100
From: po...@poczta.onet.pl
To: mkgmap-dev@lists.mkgmap.org.uk
Subject: Re: [mkgmap-dev] Distorted lines
Hi,
since Garmin started to create
Hi Gerd,
I've added the code to optimize non-routable ways in r3059.
Your example looks much better now.
That was fast. Result is much better, thanks!
Can we fine-tune effect using option --reduce-point-density?
Some observation:
Map size seems to be nearly 10% less, compared to latest
Hi Andrzej,
That was fast. Result is much better, thanks!
Can we fine-tune effect using option --reduce-point-density?
no, but maybe I will add parameters for the hard coded threshold values later.
Some observation:
Map size seems to be nearly 10% less, compared to latest release
@lists.mkgmap.org.uk
Date: Mon, 17 Feb 2014 22:07:28 +0100
Subject: Re: [mkgmap-dev] Distorted lines
Hi Andrzej,
That was fast. Result is much better, thanks!
Can we fine-tune effect using option --reduce-point-density?
no, but maybe I will add parameters for the hard coded threshold values later.
Some
Hi Gerd,
sorry, the 10% smaller size is also not intended, I thought you
compared with trunk.
I have compared with trunk, 3057 is current release.
The way 101876024 is an extremely small building, but you seem to map
it as a line?
Yes, I'm trying to create a light map for car navigation.
Hi Andrzej,
sorry, the 10% smaller size is also not intended, I thought you
compared with trunk.
I have compared with trunk, 3057 is current release.
okay, seems I was too tired yesterday ;-)
The way 101876024 is an extremely small building, but you seem to map
it as a line?
Hi Andrzej,
thanks for the hint. This is a good reason for optimizing non-routable
ways as well, which is not yet done.
Gerd
popej wrote
Hi,
since Garmin started to create OSM maps, we can directly compare
different processing of input data. Please look at railways on both
attached
A link to OSM would be useful:
http://www.openstreetmap.org/way/234118154#map=19/52.24497/21.08463
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Am 15.02.2014 17:32, schrieb Andrzej Popowski:
since Garmin started to create OSM maps, we can directly compare
different processing of input data. Please look at railways on both
attached pictures. Mkgmap version (simp-mkg.png) is created with branch
high-prec-coord-r3053.
In order to
Hi Gerd,
Gerd wrote:
Sometimes mkgmap creates short arcs by changing the meaning of
points, eg. with the --link-pois-to-ways option. Some weeks ago I've
posted a patch regarding this, but I got no feedback.
I didn't know about this patch. Now I have tried it but I can't see any
changes at
about the effect on straight lines.
I will need a few days to dig into this again.
Gerd
Date: Sun, 1 Sep 2013 03:48:17 +0200
From: po...@poczta.onet.pl
To: mkgmap-dev@lists.mkgmap.org.uk
Subject: [mkgmap-dev] Distorted lines
Hi,
I observe badly looking lines. I have attached some pictures and xml
To: mkgmap-dev@lists.mkgmap.org.uk
Subject: [mkgmap-dev] Distorted lines
Hi,
I observe badly looking lines. I have attached some pictures and xml
objects that doesn't look good on Garmin map.
My guess is that there is no proper simplifications for resolution
24bit. Points too dense are removed
Hi Felix,
Felix Hartmann-2 wrote
I noticed that remove-short-arcs=5.4 can in some cases even break
routing, remove-short-arcs on default (I think 2.8) is fine though. I
could well believe there are some fundamental flaws in it, especially in
combinaton with reduce-point-density
Hi,
GerdP wrote:
Up to now the reduce-* values are only used for the
simplifications that are used for resoultions 24
That is the first problem I have described. In my opinion,
simplification should be performed on original floating point data too.
This would preserve shape of the curve
Hi Andrzej,
Second problem with deleted short lines is difficult to avoid but maybe
could be optimized for better visual result. Position of the point that
is replacing removed line could vary depending on topology of other
lines. Or sometimes instead of removing line, it could be
39 matches
Mail list logo
