To my great satisfaction and surprise, in the mail from about the start of March we could read in the “dev Digest, Vol 131, Issue 25,” the issue “2. Upcoming change in files on openstreetmapdata.com”. The changes relate to the creation of regular tiles for land and water coastline based large areas instead of splitting up these areas onto irregular rectangular partly overlapping areas. This issue has been discussed (on this forum) in years and I think this is now the right direction Arguments for changes, as well as examples, we could find in the documentation accessible via http://blog.imagico.de/on-slicing-the-world-news-from-openstreetmapdata-com/ link. As stated there, many application developers use these “water/land polygons” and the interest for them and for the tools used is constantly growing. With large respect for that and for the effort invested by the authors, I would just like to add some (constructive) notes that could maybe help faster and more robust accomplishment of the changes. 1. The (coastline) data/input validator you use still has certain holes: - There are areas in/over areas. These are probably missing islands in lakes or rivers. - There are still many replicated consecutive points/nodes on borders. - There are many open land border polygons (especially those crossing the World border) in the coastline. - There are also certain misalignments between the land border polygons and the World border rectangle (especially the east/south/west border segments of the Antarctica). Just to mention some. 2. The planet_sea and its (regular) tiled representation: - There is a doubt in the documentation about the creation of the planet_sea. This doubt is unnecessary as my experience shows. For instance, in the Mercator projection, we can generate a perfect planet_sea by inversion of the planet_land and we can do it in some seconds (on my laptop). - The z9 “simplified” and “slicing” water polygons creation seams OK. However, from the methodology point of view the planet_land scaling-simplifying-inverting is never the same as scaling-simplifying the planet_sea. Especially, the differences are obvious on the World border. Note that the World border/frame issue is complex and almost all mapping systems have problems with it. - The tile overlaps should be obsolete. Correct rendering and tile/frame matching is a basic application responsibility. - Using higher scale levels (z9) for rendering lower scale presentations (like z2, z3…) has many aesthetic, topological and performance related issues. - The tiling of water areas is probably obsolete. I would suggest considering of on-the-fly tiling. 3. The “generalized” zoom z8-z1 map versions. - All small area borders (islands) appear as oval and consequently larger. - There are many unexpected breaks and connections on area objects and consequently many lakes appear on fiords, islands on peninsulas and so on. - The production of the zi data is rather complex and time-consuming. - The re-vectorised (z8-z1) versions of the polynomial approximations contain 4-5 times more vectors than the corresponding versions created by a robust cartographic generalization. Finally, if interested, you may find many arguments, details and examples in the white paper here: https://drive.google.com/file/d/0B6qGm3k2qWHqd1UtcXNVWUVtN3M/view?usp=sharing Regards, Sandor.
Sent from Mail for Windows 10
_______________________________________________ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
