[OSM-dev] Area DataType

sandor sandors39 at gmail.com
Tue Apr 17 08:36:45 UTC 2018

Original mails from Julien Cochennec on 20.03.18.
As I understand you are looking for descriptions/papers about basic area operations. Also, as I see, you have not get any answers yet. This is natural because OSM is about the data and your interest is in the applications. Besides, the most popular map-making strategy in OSM public maps is based on tiled raster colour images in PNG format and here there is very little (if any) need for area operations. For better understanding we need some short notes where you may find hints, where to search details related to your interest. 
In digital map-making we can recognize three basic strategies based on colour raster images, bi-tonal raster images and parametric images (mostly its vector version).
-The first strategy is the simplest and most popular strategy. It is based on uniform edge-aligned colour images as a rule in PNG format. The rendering is nice, simple and effective. At the same time it is rigid and except panning and zooming/scaling (in steps) it is not too much you can do. If you need to show/render more than 30-40 object classes you will quickly rich the style limits (number of distinguishable colours, fill and line stiles, colour shades... ) the data size will radically increase... just to mention some.
-The bi-tonal raster based strategy is much more flexible and effective. Using the mentioned 30-40 colour layers this strategy will use roughly 3 times less compressed data compared to the corresponding PNG format. In this strategy you can move the layers up and down, switch them on and off, change the style as you like, provide superb colour-to-colour antialiasing on-the-fly, arbitrary scaling, rotation... and so on. You do not need bit-/pix-maps because everything is possible to run directly from the compressed data. Here you can find something often called Image Algebra which contains area/set operation functions. Search for the notion and visit those related to raster images. It is worth noting that this strategy offers solutions for really heavy RW issues with no parallel like collision control in a large set of moving objects (on sea, in air), safety monitoring in large area and large set of moving objects (vessels against safety belts along coastline, platforms) just to mention some.
-The far most efficient and flexible map-making strategy is, of cause, the vector data based map-making. Professional attempts in this strategy, simply, cannot liv without area operations similar to those you have mentioned (though rarely under the Set/Boolean  Algebra Operations name). This is especially trough for OSM multipolygon source data users. For instance, the Wiki documentation suggests limited data size when uploading larger areas, indirectly, area fragmentation. In turn fragmentation, for many reasons, highly limits any data generalisation unavoidable in scale/zoom levels creation. An other example type is overlaps of areas from different classes (between land, sea, rivers, lakes, forests ... along border corridors, full overlaps and so on). Unfortunately the algorithms and programs dedicated to resolve these area issues are complex and as a rule deeply embedded into scripts. Practically difficult to find and read them even if they are public. A serious related problem is whether and how much you may trust these algorithms. If the results look like correct for trivial cases (adding, multiplying, subtracting... triangular areas) they may be wrong in complex cases, besides, even if the algorithms work properly the efficiency, the speed my radically vary. You may find many related papers if you search for Polygon Algebra, Linear Algebra, Topology Geometry, or similar, in applications. I have used area related algorithms in OSM vector data preparation in years and have posted some papers to several lists. Some of the latest you may see here https://goo.gl/ot9ZRy or here https://goo.gl/tuR5Wr (point 4).
Finally, from my point of view, behind the often used (also by you) adage “reinventing the wheel” or “rediscovering the cold water” stands an outdated and dangerous development killing philosophy. Yes, we are interested in new water types, better water quality, nicer water packaging... and we are interested in that all the time no matter what it costs. If we kill that interest we kill the development and others will quickly be in front of us.
Regards, Sandor

Sent from Mail for Windows 10

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20180417/53bf3609/attachment.html>

More information about the dev mailing list