Re: [OSM-dev] Generalisation

[Tomas Straupis]

SwissTopo maps are some of the best examples of generalisation (as
well as other cartography principles/techniques)
https://map.geo.admin.ch/

___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Generalisation

[Yves]

>
>> You need to keep in mind that both geometric generalization and lossy
>
>> vector data compression operations are largely incompatible with the 
>> current goals of OSM-Carto:
>>
>>
>https://github.com/gravitystorm/openstreetmap-carto/blob/master/CARTOGRAPHY.md
>
>I don't think this is true. For example making borders simpler
>increases
>clarity, while previous state was creating optical illusions.
>
Also, generalizing buildings could for instance give something nice at low zoom 
instead of only landuse=residential. Nothing really contradictory to the 
described goal here. 


Yves

___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Generalisation

[Martin Koppenhoefer]

2018-04-16 18:34 GMT+02:00 Marco Boeringa :

>
> 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 ;-).
>


it really depends on the zoom levels (=detail you want) and building
structure. If there is a closed building block there may be a lot of those
4-node-houses which all together could be generalized to one 4 node block.
If there are scattered houses in a rural setting, you still can omit the
smaller ones or make one bigger structure by combining several smaller
ones. Many buildings also do have more than 4 nodes.

Cheers,
Martin
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Generalisation

[Daniel Koć]

W dniu 16.04.2018 o 11:42, Christoph Hormann pisze:

> There are different definitions of what kind of operations and processes 
> you call "generalization".  

Thanks for showing the examples what can be seen as generalization, this
is quite wide subject:

https://en.wikipedia.org/wiki/Cartographic_generalization

On osm-carto we also use types generalization (like meadow and grassland
shown in the same way), which is very different than the one in the
original message.

> You need to keep in mind that both geometric generalization and lossy 
> vector data compression operations are largely incompatible with the 
> current goals of OSM-Carto:
>
> https://github.com/gravitystorm/openstreetmap-carto/blob/master/CARTOGRAPHY.md

I don't think this is true. For example making borders simpler increases
clarity, while previous state was creating optical illusions.

-- 
"My method is uncertain/ It's a mess but it's working" [F. Apple]



___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Generalisation

[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.

> Besides, buildings are only shown at high zoom,
> while generalization is most needed and beneficial at
> low zoom. Lastly, most vector generalization algorithms are primarily
> designed and effective for rather smooth and node rich data, like a
> stream-digitized feature, neither of which relates to square buildings.
> Hence  i consider generalizing buildings largely senseless.

  I suspect you're talking about st_simplify(preservetopology) use in
vector tile generators. Which as mentioned earlier is only technically
a "generalisation".
  http://www.gitta.info/Generalisati/en/html/unit_GenProcedure.html

-- 
Tomas

___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Generalisation

[Marco Boeringa]

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 ;-). Besides, buildings are only shown at high zoom, 
while generalization is most needed and beneficial at low zoom. Lastly, most 
vector generalization algorithms are primarily designed and effective for 
rather smooth and node rich data, like a stream-digitized feature, neither of 
which relates to square buildings. Hence  i consider generalizing buildings 
largely senseless.




Outlook voor Android downloaden 













Van: Tomas Straupis 


Verstuurd: maandag 16 april 11:48 


Onderwerp: Re: [OSM-dev] Generalisation 


Aan: Openstreetmap Dev list 






2018-04-16 11:34 GMT+03:00 Martin Koppenhoefer wrote: > There are some 
precomputed / extracted data files though, some of which > contain generalized 
(simplified) data. These are all "external" sources: > Ok, so this is natural 
polygon generalisation. Looking at https://github.com/imagico/coastline_gen the 
method used is to rasterise, process and then vectorise back. I wonder if that 
is better/faster than full vector way: st_clusterwithin, st_union, 
st_buffer(positiveN), st_buffer(negativeN+M), st_buffer(positiveM) with a 
seasoning of st_simplifypresevetopology according to taste. > Another aspect is 
filtering: osm-carto removes features when they would be > very small (pixels 
at a given zoom level) and lead to "noise". Filtering (selection) is 
technically also a generalisation. But you need to group and probably 
amalgamate them before deciding that it is "too small". For example if we have 
a lot of small patches of forest close together (say 1000 patches of 10x10m 
with distance between patches of 1m) you would want to amalgamate them to one 
large forest, not to get rid of them all. Ways and especially buildings are the 
most interesting (difficult) part :-) P.S. GRASS claims to be doing 
displacement and way selection 
(https://grasswiki.osgeo.org/wiki/V.generalize_tutorial) -- Tomas 
___ dev mailing list 
dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev 




___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Generalisation

[Christoph Hormann]

On Monday 16 April 2018, Martin Koppenhoefer wrote:
> AFAIK, in the osm-carto style there is no generalization on live data
> for performance reasons (because of continuous data updates via
> minutely diffs). There are some precomputed / extracted data files
> though, some of which contain generalized (simplified) data. These
> are all "external" sources:

I think this requires some clarification.

There are different definitions of what kind of operations and processes 
you call "generalization".  But typically selection is considered a 
generalization operation meaning that most of what is shown at all but 
the highest zoom levels is shown with some level of generalization.  
Most selection is rather primitive - based on fixed zoom level 
thresholds, the dreaded way_area filtering etc.  There are very limited 
attempts at some additional sophistication, like for populated place 
rendering at low to mid zoom levels.

When talking about explicit geometric generalization while specifically 
exclusing lossy vector data compression (which is widely 
mischaracterized as generalization) the Natural Earth boundaries at 
z=1-3 is currently the only case.

Lossy vector data compression in addition is currently/historically used 
in the following places:

* Coastlines at z8-9 - the visual impact of this was rather small but 
visible in some areas (in particular with small islands) if you kept an 
eye on it at the transit from z9 to z10.  This has been the case for a 
long time but is essentially superseded by:
* Coastlines at z0-9 since
https://github.com/gravitystorm/openstreetmap-carto/pull/3065
* The administrative boundaries at z4+ since
https://github.com/gravitystorm/openstreetmap-carto/pull/3103

You need to keep in mind that both geometric generalization and lossy 
vector data compression operations are largely incompatible with the 
current goals of OSM-Carto:

https://github.com/gravitystorm/openstreetmap-carto/blob/master/CARTOGRAPHY.md

-- 
Christoph Hormann
http://www.imagico.de/

___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Generalisation

[Tomas Straupis]

2018-04-16 11:34 GMT+03:00 Martin Koppenhoefer wrote:
> There are some precomputed / extracted data files though, some of which
> contain generalized (simplified) data. These are all "external" sources:
> <...>

  Ok, so this is natural polygon generalisation. Looking at
https://github.com/imagico/coastline_gen the method used is to
rasterise, process and then vectorise back.
  I wonder if that is better/faster than full vector way:
st_clusterwithin, st_union, st_buffer(positiveN),
st_buffer(negativeN+M), st_buffer(positiveM) with a seasoning of
st_simplifypresevetopology according to taste.

> Another aspect is filtering: osm-carto removes features when they would be
> very small (pixels at a given zoom level) and lead to "noise".

  Filtering (selection) is technically also a generalisation.
  But you need to group and probably amalgamate them before deciding
that it is "too small". For example if we have a lot of small patches
of forest close together (say 1000 patches of 10x10m with distance
between patches of 1m) you would want to amalgamate them to one large
forest, not to get rid of them all.

  Ways and especially buildings are the most interesting (difficult) part :-)

P.S. GRASS claims to be doing displacement and way selection
(https://grasswiki.osgeo.org/wiki/V.generalize_tutorial)

-- 
Tomas

___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Generalisation

[Martin Koppenhoefer]

2018-04-16 10:34 GMT+02:00 Martin Koppenhoefer :

> still AFAIK, 1 and 3 are currently still from natural earth data, the rest
> is from OSM, 2 is a simplfied version of 4, both come from
> openstreetmapdata.org (Christoph and Jochen). Of these, 1-3 are
> containing generalized data.
>


according to Paul Norman in the video recording, also 5 and 6 are
generalized.
Another aspect is filtering: osm-carto removes features when they would be
very small (pixels at a given zoom level) and lead to "noise".

Cheers,
Martin
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Generalisation

[Martin Koppenhoefer]

AFAIK, in the osm-carto style there is no generalization on live data for
performance reasons (because of continuous data updates via minutely
diffs). There are some precomputed / extracted data files though, some of
which contain generalized (simplified) data. These are all "external"
sources:




   1. world_bnd_m.shp, places.shp, world_boundaries_m.shp
   

   2. simplified_land_polygons.shp
   

   (updated daily)
   3. ne_110m_admin_0_boundary_lines_land.shp
   

   4. land_polygons.shp
   
   (updated daily)
   5. icesheet_polygons.shp
   
   6. icesheet_outlines.shp
   





still AFAIK, 1 and 3 are currently still from natural earth data, the rest
is from OSM, 2 is a simplfied version of 4, both come from
openstreetmapdata.org (Christoph and Jochen). Of these, 1-3 are containing
generalized data.

Cheers,
Martin
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev