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
On 01/07/2010 06:09 PM, Simon Eugster wrote:
MKGMAP (gmapsupp.img)
--gmapsupp %s
(with all .img files as argument)
You have to tell mkgmap which img is which FID in this stage. The FID is
not stored in the individual tiles, just in the TDB file and in the
gmapsupp.img.
Hi Steve,
I think I have found the problem in Tags.java that was causing the
assertion when I tried to delete multiple tags. I believe the root
cause was the fact that remove() would decrement size so it looked as
if there was space but it didn't actually remove the key (as the
comment there
I fear this did not solve the problem either. Here is what I tried:
java -Xmx1500m -jar /data/gps/maps/mkgmap/dist/mkgmap.jar --gmapsupp
--family-id=00010002 /data/gps/maps/new/osmData/austria/00010002.img
--family-id=00010004 /data/gps/maps/new/osmData/austria/00010004.img
On 01/07/2010 08:46 PM, Simon Eugster wrote:
I fear this did not solve the problem either. Here is what I tried:
java -Xmx1500m -jar /data/gps/maps/mkgmap/dist/mkgmap.jar --gmapsupp
--family-id=00010002 /data/gps/maps/new/osmData/austria/00010002.img
--family-id=00010004
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
Ralf Kleineisel wrote:
On 01/07/2010 08:46 PM, Simon Eugster wrote:
I fear this did not solve the problem either. Here is what I tried:
java -Xmx1500m -jar /data/gps/maps/mkgmap/dist/mkgmap.jar --gmapsupp
--family-id=00010002 /data/gps/maps/new/osmData/austria/00010002.img
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
Maybe the splitting should be done *after* the dp step.
Have just looked into the code.
The splitting with PolygonSplitter *is done* after the dp step. So this
is ok.
But while looking at it I found a severe error in the splitter code.
See attached picture.
If the polygon gets split at 6,
14 matches
Mail list logo
