[OSM-dev] Coastline generalization tool and data

[Christoph Hormann]

On Wednesday 13 February 2013, Sandor Seres wrote:
> There is an explicate invitation to comment the tool and the results
> in the paper so, I take the liberty to do so and post some of the
> many potential comments.

Hello Sandor,

thanks for your comments and for looking at the files in such detail.

> -That some thin, or small, area objects/portions spontaneously
> disappear when zooming out (scaling down) is natural and as a rule a
> quality requirement in digital mapping. If there is a readability
> problem that means that the display/rendering is using a wrong zoom
> level or the zoom levels are not properly created. Whether we draw
> the area borders or not is here irrelevant.

I wonder if you have read the explanatory text on 
http://www.imagico.de/map/coastline_en.php.  I explained there in more 
detail the reasons and the effect of aliasing that is intrinsic to 
raster maps when using detailed source data - even if properly 
rendered.

Drawing of an outline is indeed not a major difference - doing so 
however emphasizes the effects described and therefore maps with such 
an outline are in more pressing need of generalization of the data.

> -Moving objects or parts of objects from their exact/correct
> geo-locations is inacceptable in cartography. Even if this action
> provides "better readability" it lifts out the corresponding map from
> cartography and moves it to the illustrations area. Besides the fact
> that moving border segments inwards (more inside) in some neighboring
> areas provides better visibility of tiny water stripes, on tiny land
> stripes it has a contra effect. The action brakes, or even removes
> these thin land stripes.

First properly dealing with both thin stripes of land and water is 
exactly what my approach tries to do - you can see this quite well at 
the Dardanelles where enlargement of the strait is made primarily to 
the south since the northern shore is a thin strip of land.  In 
contrast to that enlargement of the Bosphorus is symmetrical.

The statement that moving objects from their exact location is 
inacceptable in cartography seems courious to me - displacement is an 
inherent component of most cartographic generalization concepts, see 
for example:
 
http://www.ingentaconnect.com/content/maney/caj/2007/00000044/00000001/art00007

> -The spline approximation of sharp turns/fine details in a
> raster-area contour results in noticeably larger area fractions. This
> fact is known from the times when raster-to-vector (parametric)
> presentation transformation was a topic issue

Actually my tool allows for fine tuning this bias (the -l parameter).  I 
have not used this much yet but it should work.  This is also important 
when you draw an outline since depending on the style of the map the 
outline might primarily be percieved as belonging to the land or water 
and depending on that you might actually want a bias.

> -The data maintenance procedure might be tedious (if possible at all)
> for low scale factor values (or higher zoom levels in the OSM
> semantics, like level 9, 10 . 16 and so on). The planet_land raster
> images for these scale factors, even with some bad/low resolution,
> might be extraordinary large. For example the size of a 1:250 000
> scale 512 dpi raster map of Norway (in a conic projection) is 81 000
> pixels * 101 000 pixels (the corresponding Real World  resolution is
> around 30m).

On the bright side generalization is much less needed for the coastline 
at the higher zoom levels.  My estimate is that 9 and 10 might be good 
to have in addition but from 12 on there is not much point.

And i am doubtful that other generalization methods which are not plain 
line simplification and smoothing methods like Douglas–Peucker scale 
much better on a global level than my approach.  Note although my 
technique is raster based the computational costs are not proportional 
to the number of pixels (it is faster than that).

> -For the same data size other models may provide radically richer
> content, better edge quality and precision.

It seems to me you base your assessment on the number of polygons and 
nodes - this is quite problematic though.  Reducing the data size was 
not a goal for me, therefore the number of nodes is very high (just as 
coming straight from potrace) and could be easily reduced to half with 
nearly no visible impact - i could even use 'potrace -a 0' and probably 
would get quite close to your reference examples in terms of geometric 
detail to number of nodes ratio.  The number of polygons is not 
significant either since this is mostly a matter of small islands and 
for a raster web map having islands significantly smaller than a pixel 
is pointless (it is actually even bad since it introduces aliasing 
artefacts)  The minimum size of islands to keep is a parameter of my 
tool and for the files available for download this is set large enough 
so a thin outline drawn at the zoom level in question is still visible 
as such for most islands - like you can see in the demo map.

> In my opinion, it is hard to believe that this tool/technology may
> compete with other similar technologies for creating zoom-levels in
> digital cartography. Yet, it may be of certain value in the field of
> illustrations among many other options.

About the coastlines you use for comparison your write they are created 
using a 'proprietary vector smoothing and data reduction algorithm' - 
it would be important to know what exactly this does of course.  And as 
said, my technique is not about data reduction so the assessment based 
on data sizes is somewhat missing the point here.  

But of course there is much room for improvements with my technique and 
of course generalization is always a lot about subjective choices so it 
is perfectly fine to prefer a different approach.  If you can point out 
disadvantages of my files when compared to alternative techniques in 
actual appearance in rendering that would be very useful.

-- 
Christoph Hormann
http://www.imagico.de/