logo separator

[mkgmap-dev] Sensible resolutions - (or patch 5)

From Johann Gail johann.gail at gmx.de on Wed Mar 2 19:43:21 GMT 2011


Am 02.03.2011 14:03, schrieb Felix Hartmann:
>
> On 02.03.2011 13:53, Marko Mäkelä wrote:
>> On Wed, Mar 02, 2011 at 01:45:52PM +0100, Minko wrote:
>>> Negative consequence is that on Mapsource most of the forest disappears
>>> too soon, when zooming out.
>> How hard would it be to merge nearby polygons on wider zoom levels?
> It would not work I think. What would be needed is to generalise
> polygons on lower zoom levels. Meaning merge them together, drop holes,
> straighten them (well the dp-filter already takes care of that), and
> have a seperate style-file where there are definitions on what gets
> merged how.
In general I think this should be solvable. It will be not an easy task 
and maybe resource hungry, but I think, this should be possible. The 
subject was discussed already in January 2010 in a side thread of 
'Suggestion - Make Douglas Peucker Algorithm more Configurable'
>   Ideally a hole or scrub part of a forest would be only
> visible from resolution 24-22 or 24-21 (depending on the size of the
> whole/scrub). It's the same as you only want to see single houses when
> zoomed in close, when further away you want to see residential area, and
> when even further away you want to sea where is urban vs nonurban area.
Yes, this would be nice.
> OSM sucks big in this regard and as long raster maps are the primary
> outcome of OSM data (for lower zooms) then there will be no motivation
> for change (change which means layering OSM data instead of one big
> black hole to sink information into).
>
OSM is not a perfect world for cartogaphs. But we have to take it as it 
is. And it is a database which shows a more or less detailes map at 
*one* zoom level, the nearest one. I wouldn't like it to include the 
same information in several zoom levels which have to be held consistent 
by the users. This will not work. This is a task which *must* be done by 
algorithms.

Regards,
Johann



More information about the mkgmap-dev mailing list