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 are
>>> 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
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 resu
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)
> resol
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
Just created a patch for it.
Thilo Hannemann schrieb:
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
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 i
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
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
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
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
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
> 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 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
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
> 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
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
think tha
17 matches
Mail list logo