On 07.01.2010 23:13, Thilo Hannemann wrote:
The Douglas Peucker Algorithm might not be the best way to tackle the problem
of too small polygons. Right now polygons will be dropped if they have a
maximum extension of less than one map unit at the current resolution. The
code is in
The problem with the roads is that the SizeFilter is called for lines as well
as for polygons. But the call to the filter is in two different places in
mkgmap/build/MapBuilder.java. So if you make the MIN_SIZE a parameter and use
different values for lines and polygons you won't have any holes
That patch works pretty nice. I upped the value to 40 and that gave nice
results when zoomed far out.
Here is the settings that I would find optimal
resolution 24 == 4 (I think 4 is anyhow the minimum because if less than
4 pixels than it ain't an area)
resolution 23 == 6 ( resolution 23 is not
Felix Hartmann schrieb:
That patch works pretty nice. I upped the value to 40 and that gave
nice results when zoomed far out.
Here is the settings that I would find optimal
resolution 24 == 4 (I think 4 is anyhow the minimum because if less
than 4 pixels than it ain't an area)
resolution
I've tried the patch as well and it works nicely. Smaller maps, some map
clutter removed and seems to be faster as well.
Regards
Thilo
Am 08.01.2010 um 21:48 schrieb Johann Gail:
Felix Hartmann schrieb:
That patch works pretty nice. I upped the value to 40 and that gave
nice results
That patch works pretty nice. I upped the value to 40 and that gave
nice results when zoomed far out.
Here is the settings that I would find optimal
resolution 24 == 4 (I think 4 is anyhow the minimum because if less
than 4 pixels than it ain't an area)
resolution 23 == 6 ( resolution 23
On 08.01.2010 23:25, Johann Gail wrote:
That patch works pretty nice. I upped the value to 40 and that gave
nice results when zoomed far out.
Here is the settings that I would find optimal
resolution 24 == 4 (I think 4 is anyhow the minimum because if less
than 4 pixels than it ain't an
Essentially the best option for drawing Polygons would be to determine
their resolution based on size. So make large forests appearing at
lower resolutions than small forests (well I think we all know that best
would be if resolution of any element were adapted to map density, but I
On 07.01.2010 16:19, Johann Gail wrote:
Essentially the best option for drawing Polygons would be to
determine their resolution based on size. So make large forests
appearing at lower resolutions than small forests (well I think we
all know that best would be if resolution of any element
The Douglas Peucker Algorithm might not be the best way to tackle the problem
of too small polygons. Right now polygons will be dropped if they have a
maximum extension of less than one map unit at the current resolution. The code
is in mkgmap/filters/SizeFilter.java if you want to try it, just
The proper solution would be to merge polygons if they overlap at the
current resolution. Otherwise we might get holes in forests if they are
mapped in small pieces. But I have no idea how to implement that...
Which would be rather counterproductive to the PolygonSplitter code :-(
The
On 07.01.2010 23:13, Thilo Hannemann wrote:
The Douglas Peucker Algorithm might not be the best way to tackle the problem
of too small polygons. Right now polygons will be dropped if they have a
maximum extension of less than one map unit at the current resolution. The
code is in
Am 07.01.2010 um 23:22 schrieb Johann Gail:
The proper solution would be to merge polygons if they overlap at the
current resolution. Otherwise we might get holes in forests if they are
mapped in small pieces. But I have no idea how to implement that...
Which would be rather
Thilo Hannemann schrieb:
Am 07.01.2010 um 23:22 schrieb Johann Gail:
The proper solution would be to merge polygons if they overlap at the
current resolution. Otherwise we might get holes in forests if they are
mapped in small pieces. But I have no idea how to implement that...
At the moment there is a commandline switch
(-reduce-point-density=xxx) which allows you to set the dp error
distance for each call. It should be doable with nearly no effort to
introduce a second option for polygon settings.
Just added a patch with an additional option
15 matches
Mail list logo
