> 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 a
I get this error when trying to build the italy map from cloudmade (map
from Dec 26th). Any idea?
Simon
4 wd: /data/gps/maps/new
cd /data/gps/maps/new/osmData/italy && java -enableassertions -Xmx1500m
-jar /data/gps/maps/mkgmap/dist/mkgmap.jar --adjust-turn-headings
--check-roundabouts -
Ok, sorry. The NET error happens with the UK map. When nevertheless trying
to join all images to one gmapsupp.img:
Exception in thread "main" java.lang.IllegalArgumentException
at java.nio.Buffer.position(Buffer.java:218)
at uk.me.parabola.imgfmt.Utils.bytesToString(Utils.java:75)
Good evening,
I'm using mkgmap r1466 and splitter r103.
With my python script [1] I at first build .img files of various .osm.bz2
files and then put some of them into a gmapsupp.img file.
I do _not_ regenerate the .img files each time I create a gmapsupp.img. For
image files of maps which did
Simon Eugster wrote:
> Good evening,
>
> I'm using mkgmap r1466 and splitter r103.
>
> With my python script [1] I at first build .img files of various .osm.bz2
> files and then put some of them into a gmapsupp.img file.
>
> I do _not_ regenerate the .img files each time I create a gmapsupp.i
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 sugg
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
--family-id="00
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" /data/g
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 :
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 mkgma
I have made some improvements to the multipolygon branch.
Changes:
* Polygons with inner polygons are now divided into several polygons.
It's much faster and the PolygonSplitter cannot destroy them any more.
* Improved tag handling. The tags from original ways are removed. This
has the disadvan
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
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
'reduce-point-densit
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,
19 matches
Mail list logo
