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/ _______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/listinfo/dev
