[OSM-dev] COASTLINE, from another angle

[Sandor Seres]

	The coastline is a perfect arena to demonstrate issues related to some of the basic digital map-making procedures like the data preparation, data generalisation and scale levels, clipping and tiling, transmission and rendering... just to mention some. In turn, these procedures involve many fine algorithms, though theoretically perfectly correct, with radical differences in performance and requirements depending on how they are practically applied. So, the mentioned basic procedures are in a constant evolution and that is the focus in these several lines.
	 In the digital map-making the source data is almost always in parametric/vector format and the RW objects are modelled by nodes, polylines and polygons where the edges are vectors. The same in OSM. The data preparation detects and repairs large (huge) number of anomalies and usually ends up with correct and defragmented models of the RW objects. This phase provides not only high data quality but helps to avoid lots of traps in the processes that follows. From this point the mentioned map-making phases considerable depends and differs depending on the selected strategy like the classical raster colour tiled images based strategy, or the bi-tonal raster layers based strategy or the modern vector based strategy. The latter has two basic versions, the pre-tiled data service and "on-the-fly" tiling based service. When it comes to efficiency the on-the-fly tiling based server-client strategy has no parallel. It is worth noting that the server has no homogeneous tiling assumption. The server performs the RW window-to-viewport transformation for any of the needed data layers and transfers these to the client where the only thing remains is the rendering. So, there is no tile coverage or more precisely the one rectangular tile perfectly fits into the user display window. Using a set of carefully created scale levels per object class and an exceptionally fast clipping algorithm the former procedure happens so fast that the name on-the-fly tiling is really adequate. Besides the exceptional performance, this emerging map-making technology requires really moderate HW and SW resurces. 
	As described earlier, a modern clipping algorithm never creates degenerated polygons and areas. Therefor the corresponding tiling algorithm don't need the usually used correction and area restructuring heavy processes. However, even a perfect tiling algorithm may turn out to be too slow when it comes to real time vector data service. It depends how the algorithms are practically applied. In the linked "COACTLINE, from another angle" article below, besides the commonly known world border issues, the mentioned scale level issues are highlighted. Yet, the major focus is on the vector multi-tiling and on-the-fly vector data service technologies. The demo descriptions and hints may be of certain use for developers/researchers already working with vector tiling and server-client issues. The performance and data size related figures could serve as a kind of orientation to those preferring third party or open source solutions. The article is here:
	https://drive.google.com/file/d/1Q6MSuWPcAtggn6Hx5paBa62IlsLOPadc/view?usp=sharing

	Regards, Sandor