Re: [OSM-dev] Coastline generalization tool and data
On Tuesday 19 February 2013, Michal Migurski wrote: Christoph, this is so cool. Excellent work! Thanks. I've been hammering away at an OSM generalization effort of my own, focused on the global preparation of simplified linework for major roads and route relations: http://www.openstreetmap.us/~migurski/streets-and-routes/ For generalizing roads I think there are four major components: 1. removing smaller roads where there is no room to show them properly 2. summarize dense networks of roads of similar size 3. move roads to be able to distinctly show them without overlap with other features or themselves 4. simplify the individual road segments From your description I have the impression that a major part of your effort is in 2. although I could not clearly identify cases of summarization in your examples. From the samples it seems your technique sometimes produces gaps between roads which are in fact connected. Apart from that it looks quite good - for curved roads the simplification seems a bit strong unless you mean to use some kind of smooth spline rendering. By the way for the coastlines I also looked into the idea of using vector skeletons but I soon realized this would be prohibitively slow on a global scale. From the pure program design point this would still be an interesting idea. I did find one weird part of your data, around Boston where the peninsula appears detached from the mainland. That's another canal tagged as coastline: http://www.openstreetmap.org/browse/way/22721484 -- Christoph Hormann http://www.imagico.de/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Coastline generalization tool and data
On Feb 19, 2013, at 4:04 AM, Christoph Hormann wrote: On Tuesday 19 February 2013, Michal Migurski wrote: I've been hammering away at an OSM generalization effort of my own, focused on the global preparation of simplified linework for major roads and route relations: http://www.openstreetmap.us/~migurski/streets-and-routes/ For generalizing roads I think there are four major components: 1. removing smaller roads where there is no room to show them properly 2. summarize dense networks of roads of similar size 3. move roads to be able to distinctly show them without overlap with other features or themselves 4. simplify the individual road segments From your description I have the impression that a major part of your effort is in 2. although I could not clearly identify cases of summarization in your examples. It's mostly 4, actually. The individual road segments are being simplified and merged. From the samples it seems your technique sometimes produces gaps between roads which are in fact connected. Apart from that it looks quite good - for curved roads the simplification seems a bit strong unless you mean to use some kind of smooth spline rendering. No rendering at all. The intent of this work is to provide labeling hints, so you'd still render the regular roads from OSM and use this dataset to place labels over them. We did this for the US when I worked on the Stamen Terrain map, visible here: http://maps.stamen.com/terrain/#13/37.7786/-122.4408 I did find one weird part of your data, around Boston where the peninsula appears detached from the mainland. That's another canal tagged as coastline: http://www.openstreetmap.org/browse/way/22721484 So a re-tag would fix this? How long does the data take to re-run? -mike. michal migurski- contact info and pgp key: sf/cahttp://mike.teczno.com/contact.html ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Coastline generalization tool and data
On Tuesday 19 February 2013, Michal Migurski wrote: No rendering at all. The intent of this work is to provide labeling hints, so you'd still render the regular roads from OSM and use this dataset to place labels over them. We did this for the US when I worked on the Stamen Terrain map, visible here: http://maps.stamen.com/terrain/#13/37.7786/-122.4408 So rendering of the roads themselves is based on the original OSM data. This explains the gaps - for labeling they do not matter. So a re-tag would fix this? How long does the data take to re-run? I added it to the list: http://wiki.openstreetmap.org/wiki/User:Imagico/coastline_problems_for_generalization The run for the whole earth takes about 6 hours (just the generalization, osmcoastline not included). Greetings, -- Christoph Hormann http://www.imagico.de/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Coastline generalization tool and data
Christoph, this is so cool. Excellent work! I've been hammering away at an OSM generalization effort of my own, focused on the global preparation of simplified linework for major roads and route relations: http://www.openstreetmap.us/~migurski/streets-and-routes/ It's based on work that I started in 2010 and 2011 and released as the Stamen Terrain layer: http://mike.teczno.com/notes/osm-us-terrain-layer.html http://maps.stamen.com/terrain/ I did find one weird part of your data, around Boston where the peninsula appears detached from the mainland. -mike. On Feb 11, 2013, at 4:42 AM, Christoph Hormann wrote: Hello everyone, some time ago i introduced a technique to generalize OSM coastline data for better readable map rendering [1] on talk-de and i now release the tool used for this [2] as well as a set of generalized coastline files for zoom levels 1 to 8 [3]. There is also a demo map [4] - this uses a slightly different coastline than the one for download (in particular Antarctica data is replaced by a different source). Feedback on both the tool and the files is welcome. It would be interesting to see how use of this would look like in the standard mapnik rendering, especially how much mismatch the moving of the coastline during generalization causes and how troublesome this is when viewing the map. You might notice various strange forms in the coastline at some places, most of them are caused by features being tagged as coastline which in fact should probably not be. I put up a wiki page [5] to collect these problems. If you find more or fix them feel free to edit that. [1] http://www.imagico.de/map/coastline_en.php [2] http://www.imagico.de/coastline_gen/index.php [3] http://www.imagico.de/map/coastline_download_en.php [4] http://www.imagico.de/map/map_en.php [5] http://wiki.openstreetmap.org/wiki/User:Imagico/coastline_problems_for_generalization Greetings, -- Christoph Hormann http://www.imagico.de/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev michal migurski- contact info and pgp key: sf/cahttp://mike.teczno.com/contact.html ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Coastline generalization tool and data
Hello, From: Christoph Hormann chris_horm...@gmx.de 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. If you look at the island Usedom in the Baltic Sea (Northeast Germany, near Poland): it is connected to mainland. Usedom is really difficult with small stripes of water between island and mainland. Christoph Hormann http://www.imagico.de/ Stefan Ziegler. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Coastline generalization tool and data
On Thursday 14 February 2013, Stefan Ziegler wrote: If you look at the island Usedom in the Baltic Sea (Northeast Germany, near Poland): it is connected to mainland. Usedom is really difficult with small stripes of water between island and mainland. That's right. Since it is a raster based process only structures large enough to be resolved in the raster will be taken into account. The Peenestrom misses the cutoff by a small distance here. A possible solution would be to distinctly tag such waterways, in this case: http://www.openstreetmap.org/browse/way/102832340 with something like waterway=strait and then consider those in addition to the coastline itself during generalization. Usedom however is currently no real island in OSM anyway since only one side is tagged as coastline: http://www.openstreetmap.org/browse/way/174336199 http://www.openstreetmap.org/browse/way/7724629 -- Christoph Hormann http://www.imagico.de/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Coastline generalization tool and data
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. -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. -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. -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 -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). -For the same data size other models may provide radically richer content, better edge quality and precision. 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. For more details and examples please visit https://docs.google.com/file/d/0B6qGm3k2qWHqTEhfN2k2QldIQWs/edit?usp=shari ng Sandor. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Coastline generalization tool and data
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/0044/0001/art7 -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
