[OSM-dev] Generalisation

[Marco Boeringa]

Hi Tomas,

The generalization I wrote about was just a crude basic generalization 
of vector (building) data of OSM using a default tool of ESRI's ArcGIS. 
The specific tool used (Simplify Polygon), has more advanced settings 
than standard Douglas Peucker, but by itself does nothing really special 
other than weeding out vertices / nodes. I just attempted to use it with 
different tolerances to see what the results would be, and concluded the 
resulting defects in building topology, were not worth the reduction in 
file size.

Of course, if your city's buildings are far more detailed than the 
average building in OSM, e.g. an import of official government data as 
measured up to centimeter level using land surveying techniques, with 
rather large vertex counts on average, I can imagine that even simple 
techniques to generalize, may reduce vertex counts more than I achieved. 
And also depends a lot on how much you personally tolerate artefacts... 
(mine is low for buildings).

However, as to interesting stuff to read: our national Kadaster of the 
Netherlands, is actually the very first and only national mapping 
organization world wide, that has successfully managed to implement a 
fully automated generalization work flow for generating 1:50k maps from 
1:10k maps, including landuses, waterways, highways, but also 
generalizing build-up areas and buildings. They used a range of 
cartographic generalization tools from ArcGIS (that I didn't use...).

The results achieved by the Dutch Kadaster, closely mimic what Imagico 
states as a more holistic approach to generalization, and are largely 
truth to how cartographers traditionally manually generalized maps. In 
fact, one of the key aspects of the workflow developed by the Dutch 
Kadaster, was to mimic as closely as possible the inherent "rules" their 
cartographers used and developed over decades or more than a century, to 
"generalize" maps to smaller scales.

However, if you read the level of effort needed to achieve this (years 
of development by a small team of employees / researchers, and a huge 
tool chain build up), and the sheer processing power needed to do such a 
sophisticated generalization, it is utterly clear you cannot do this in 
real time. It is only worth the effort in organizations like the 
national mapping agencies, where the ultimate gain of automatization to 
fully replace manual conversion of topographic maps from one scale to 
another, or to keep different workflows for different scale map series 
(1:10k,1:25k,1:50k,1:100k,1:250k etc.) alive, far outweighs the effort 
to develop such a generalization tool chain and workflow in the long run.

They now call this workflow "AUTOgen"

The Dutch Kadaster was actually awarded a prize by ESRI for this work. 
See also this ArcNews bulletin (pages 19-21): 
https://www.esri.com/~/media/Files/Pdfs/news/arcnews/winter1314/winter-2013-2014.pdf

Some links to this work by the Dutch Kadaster:
- 
https://repository.tudelft.nl/islandora/object/uuid:12f0c152-958a-4688-a56d-5e30f7540a68/datastream/OBJ
- 
https://www.kadaster.com/documents/33433/36597/An+overview+of+the+Dutch+approach+to+automatic+generalisation/6af54a07-3188-41db-81d2-fdc2e1d4094b
- 
https://www.kadaster.com/documents/33433/36597/Feasibility+study+on+an+automated+generalisation/dbf664a7-160f-456d-9559-32263ef6793f
- 
https://www.researchgate.net/publication/299455974_Automated_generalisation_in_production_at_Kadaster_NL

Links to English pages of Dutch Kadaster;
https://www.kadaster.com/international-consultancy
https://www.kadaster.com/automatic-generalisation

Other interesting information regarding buildings (LODs) from research 
involving one the person also involved in the Kadaster work:
https://www.int-arch-photogramm-remote-sens-spatial-inf-sci.net/XXXVIII-4-C26/7/2012/isprsarchives-XXXVIII-4-C26-7-2012.pdf

(Note: I wasn't involved in any of this by the way, just know of this work)

Marco

Op 16-4-2018 om 19:23 schreef Tomas Straupis:
> 2018-04-16 19:34 GMT+03:00 Marco Boeringa wrote:
>> No, buildings are not the most interesting. I once generalized all buildings
>> in Denmark. It only reduced the storage by maybe 5%, at the high cost of
>> heavily distorting a large number of them. Most buildings in OSM are in fact
>> already in their most generalized state: just 4 nodes. Unless you think
>> triangles is a suitable representation ;-)
>    Interesting, what algorithm did you use?
>
>    I'm playing around in Vilnius which has urban houses, big block
> houses, industrial zones and old town with lots of connected buildings
> of very irregular shapes.
>    In Vilnius there are 54267 buildings tagged with 366979 vertexes.
>    Clustering them with distance of 5m gets 45810 objects (of course
> with the same number of vertexes).
>    Removing buildings with area < 100 and having neighbours in < 500
> meters I'm left with 28974 buildings with 299224 vertexes.
>    Simplification (amalgamating buildings in the cluster and trying to
> remove edges < 20m) reduces the number of vertexes to 117108.
>    So this is much more than 5%.
>    There are still a lot of problems (no triangles:), but I do not
> expect number of vertexes to rise considerably.
>
>    Even "dumb" generalisation (st_buffer+- with join=mitter) reduces
> vertex count by ~25%.
>
>    Reducing storage/tile size is not the only/main purpose of generalisation.
>