Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Recommend -G flag for multipolygons #59

Closed
pnorman opened this Issue Jun 10, 2013 · 23 comments

Comments

Projects
None yet
Collaborator

pnorman commented Jun 10, 2013

Relations with multiple members like http://www.openstreetmap.org/?lat=57.011&lon=-6.428&zoom=10&layers=M are rendered multiple times and are a bit of a cartographic disaster.

One possible fix is to import with osm2pgsql in -G mode to create a MULTIPOLYGON instead of multiple POLYGONs. @springmeyer informs me that mapnik should render the label on just the largest POLYGON within the MULTIPOLYGON by default.

Do we know anyone running with -G?

We use -G for MapBox Streets, however our label positions mostly come from PostGIS's ST_PointOnSurface rather than giving the whole (multi)polygon to Mapnik. The results should be similar, anyway. http://a.tiles.mapbox.com/v3/aj.map-of429vi7/page.html#11.00/56.9768/-6.3261

Our setup varies quite a lot from the standard osm2pgsql/mapnik setup, but I did some testing of -G with the standard setup to verify some things and I didn't encounter any problems.

@ghost ghost assigned pnorman Jun 24, 2013

Collaborator

pnorman commented Jun 27, 2013

as of openstreetmap/osm2pgsql@34a3009 we are suggesting -G for osm2pgsql by default, osm-carto's README.md should reflect this. It should also be suggesting slim mode

Collaborator

pnorman commented Sep 29, 2013

Confirming that -G fixes this.

Without (orm):
isles-duplicate

With:
isles-fixed

We may want to tweak labelling beyond this, but we need -G for that regardless.

Performance-wise it shouldn't matter on render. Yes, it might take longer to render from the MULTIPOLYGON rather than multiple POLYGONs, but given how horribly wrong it is with multiple POLYGONs, basically, oh well.

Import/update could be different, but I doubt its significant, and again, -G is absolutely necessary to fix this problem without hideously complicated SQL.

Owner

gravitystorm commented Sep 30, 2013

A few thoughts:

  • Yes, -G seems like a good idea. Why is it not the default on osm2pgsql? Why does osm2pgsql default to one state, when even the osm2pgsql docs recommend another? (and also why is --slim recommended but still not the default?)
  • For this example, how do we indicate clearly that Canna, Eigg (and all the other islands) are part of the same national park?
  • How do we deal with multipolygon labelling when we zoom in so that not-the-biggest-polygon is in view?
Contributor

tyrasd commented Sep 30, 2013

Your last point could be generalized to:

  • How do we deal with polygon labelling when we zoom in so that not-the-centroid is in view?
Collaborator

pnorman commented Sep 30, 2013

Why does osm2pgsql default to one state, when even the osm2pgsql docs recommend another? (and also why is --slim recommended but still not the default?)

Realizing -G is important is relatively recent. As for --slim not being default, I'm not sure anyone has actually brought up the suggestion of changing the default, but you can also blame the hysterical raisins and a desire to not break people relying on the current behaviour.

How do we deal with multipolygon labelling when we zoom in so that not-the-biggest-polygon is in view?

I think @springmeyer said at the SOTM-US hack day that there was a desire to add options in Mapnik for better labeling on MULTIPOLYGONs. I can see a few potential hacks in SQL involving breaking up the multipolygon to component polygons and doing stuff with those, but the right place to fix the labelling is in Mapnik, not the SQL.

Contributor

springmeyer commented Sep 30, 2013

Probably what I was thinking of was this task which, when done, will add a text-multi-policy option so that you can request that all parts of a multipolygon will have labels. Right now the default is that only the largest (by bbox) multipolygon will be labeled, at its centroid. If text-clip:true then you'll get the centroid of the largest polygon part after clipping. Currently there is a hidden boolean called largest-bbox_only that allows toggling this behavior but this will be removed when this task is done so please DO NOT use it.

Collaborator

pnorman commented Mar 3, 2014

Running a performance benchmark on -G now.

Collaborator

pnorman commented Mar 9, 2014

Thought for labels: ST_Dump(way) to get the individual polygons, then only label those where ST_Area(way)/way_area>0.1 or some other cutoff. Not ideal (e.g. small islands far away from the other parts) but might be a good first pass.

@math1985 math1985 added the general label Apr 14, 2014

@math1985 math1985 added this to the 3.x - Needs upgrade to mapnik or openstreetmap-carto.style milestone Apr 19, 2014

Collaborator

math1985 commented Jun 6, 2015

With the upcoming database import, I think we should decide what we want to do with this issue.

I'm not sure if the G option always has a good effect. If a company is spread over multiple buildings some distance apart, is it really an improvement to only label one of them? Or is this not a good use of multipolygons?

Also, would -G have the effect that Denmark is no longer rendered as Denmark, since Greenland will receive the Denmark label as biggest area?

Collaborator

imagico commented Jun 6, 2015

Cartographically you should split this into two questions:

  1. should features with multiple components receive multiple labels
  2. if not should the label be placed on the largest element or somewhere around the center of weight of the whole feature.

The answer to both depends on the geometric configuration (i.e. size and position of the individual components compared to the whole). When you place multiple labels you will usually want to change those of the smaller elements in content, i.e. not label 'Denmark' but 'to Denmark' - this is tricky with the multitude of languages of course. But more importantly these should have lower priority than the main label.

Denmark/Greenland is not a problem though - in OSM Greenland is fully independent. In general there are very few admin units where the largest component is not the primary one.

Contributor

HolgerJeromin commented Jun 18, 2015

The rendering of this mosque looks like a tagging error...

math1985 added a commit to math1985/openstreetmap-carto that referenced this issue May 16, 2016

**This is a pull-request against the lua branch**
This PR proposes a database-reload. It changes the documentation on the use of
osm2pgsql, and adds a .lua file for preprocessing.

This database import aims to be backwards compatible with older versions of
the style.

This resolves (at least part of) #1504.

Adding the hstore option to osm2pgsql allows the database to use all keys.

This PR proposes using hstore for new keys, and using traditional columns for
old keys. This allows us to stay compatible with old versions of the style.

According to [@pnorman's benchmarks](http://www.paulnorman.ca/blog/2014/03/osm2pgsql-and-hstore/),
using hstore without dropping columns would lead to a 9% size increase and a
0.38% speed decrease. Given the benefits of having all columns available, I
would consider this acceptable.

This is based on the following unmerged PR to osm2pgsql:
openstreetmap/osm2pgsql#346

It makes the polygon/linestring decision based on the tag value, in addition to
the tag key. In particular, highway=services and junction=yes are now treated as
polygon, while leisure=track, man_made=embankment, man_made=breakwater,
man_made=groyne, natural=cliff, natural=tree_row, historic=citywalls,
waterway=derelict_canal, waterway=ditch, waterway=drain, waterway=river,
waterway=stream, waterway=wadi, waterway=weir, power=line, and power=minor_line
are now treated as linestring.

This resolves #1362, resolves #137, resolves #268, and resolves #892.

The new .lua file creates a osmcarto_z_order value in the database, which stores
the rendering order we use. This will allow us to simplify the road queries.

This resolves #59.

This resolves #101.

The .lua file drops some more meta-information from imports that is of no
need for rendering.

This is based on the following unmerged PR to osm2pgsql:
* openstreetmap/osm2pgsql#532

math1985 added a commit to math1985/openstreetmap-carto that referenced this issue May 16, 2016

**This is a pull-request against the lua branch**
This PR proposes a database-reload. It changes the documentation on the use of
osm2pgsql, and adds a .lua file for preprocessing.

This database import aims to be backwards compatible with older versions of
the style.

This resolves (at least part of) #1504.

 #Hstore
Adding the hstore option to osm2pgsql allows the database to use all keys.

This PR proposes using hstore for new keys, and using traditional columns for
old keys. This allows us to stay compatible with old versions of the style.

According to [@pnorman's benchmarks](http://www.paulnorman.ca/blog/2014/03/osm2pgsql-and-hstore/),
using hstore without dropping columns would lead to a 9% size increase and a
0.38% speed decrease. Given the benefits of having all columns available, I
would consider this acceptable.

 # Make polygon/linestring decision based on value
This is based on the following unmerged PR to osm2pgsql:
openstreetmap/osm2pgsql#346

It makes the polygon/linestring decision based on the tag value, in addition to
the tag key. In particular, highway=services and junction=yes are now treated as
polygon, while leisure=track, man_made=embankment, man_made=breakwater,
man_made=groyne, natural=cliff, natural=tree_row, historic=citywalls,
waterway=derelict_canal, waterway=ditch, waterway=drain, waterway=river,
waterway=stream, waterway=wadi, waterway=weir, power=line, and power=minor_line
are now treated as linestring.

This resolves #1362, resolves #137, resolves #268, and resolves #892.

 # Rendering order
The new .lua file creates a osmcarto_z_order value in the database, which stores
the rendering order we use. This will allow us to simplify the road queries.

 # Recommend -G flag for multipolygons
This resolves #59.

 # Import ele on buildings
This resolves #101.

 # Delete more meta-tags from imports
The .lua file drops some more meta-information from imports that is of no
need for rendering.

This is based on the following unmerged PR to osm2pgsql:
* openstreetmap/osm2pgsql#532

jojo4u commented May 17, 2016

One more example to consider: University with many sites scattered throughout a city: https://www.openstreetmap.org/relation/5294212
This was changed recently by @matkoniecz from type=site to type=multipolygon. If only one label gets rendered we need another tagging style for this "collection style" of multipolygons, perhaps site get's a comeback?

sent from a phone

Il giorno 17 mag 2016, alle ore 20:21, jojo4u notifications@github.com ha scritto:

One more example to consider: University with many sites scattered throughout a city: https://www.openstreetmap.org/relation/5294212
This was changed recently by @matkoniecz from type=site to type=multipolygon. If only one label gets rendered we need another tagging style for this "collection style" of multipolygons, perhaps site get's a comeback?

the situation is a little broken on a semantic level, nothing this style sheet can fix.
We are missing a standardized way to say what kind of university facility/entity it is, and to which university it belongs. Is every room that is used by an university "a university" by itself? Likely not.

Collaborator

matkoniecz commented Jun 9, 2016 edited

I am unsure whatever it is a good idea. For start, original example that used to be

isles-duplicate

is now rendered as (with label disappearing, as big area on this zoom level is too large, it is visible one zoom earlier)

selection_003

And in many cases, for example for

selection_004

I think that -G would make here situation worse. Zooming to islets like http://www.openstreetmap.org/#map=18/57.05311/-6.36605 gives more questionable results like

selection_005

Other examples where -G would make situation worse - http://www.openstreetmap.org/#map=16/50.0676/19.9190 (Akademia Górniczo-Hutnicza, university label)

selection_006

http://www.openstreetmap.org/#map=15/50.0710/19.9933 (Park Lotników Polskich, park label)

selection_007

http://www.openstreetmap.org/#map=16/50.0454/19.8382 (vineyard Winnica Srebrna Góra)

selection_008

http://www.openstreetmap.org/#map=17/50.07908/19.89490 - allotments Złoty Róg

selection_009

I would argue that -G will result in more harm than benefits, though I admit that I did no testing with this places and some may be tagged as separate closed ways rather than as a single multipolygon - but "informs me that mapnik should render the label on just the largest POLYGON within the MULTIPOLYGON by default" is quite clear.

All places are from my city as this way I was able to quickly find places split by roads, but I would not expect Kraków to be outlier for how often such situation happens in proportion to islet example from original report.

And I am unaware about any cases where -G would significantly improve situation and many that would make it worse.

Collaborator

matkoniecz commented Jun 9, 2016 edited

Note that it may depend on cultural factors - situations like http://www.openstreetmap.org/relation/3006134#map=19/51.16621/6.91938 may be common in places where towers are typically not connected to main structure (minaret entry on enwiki has "usually either free-standing or taller than associated support structure").

selection_010

Example found by @HolgerJeromin in #59 (comment)

Re whether -G would on balance improve things or not - I've used it with an osm-carto based stylesheet for a couple of years, and I think that on balance things work better. If you can think of somewhere within http://tools.geofabrik.de/calc/#type=geofabrik_standard&bbox=-5.380469,51.533914,2.155273,54.603809 you'd be interested in seeing the effect from, I can post an image if it helps.

Collaborator

imagico commented Jun 9, 2016

And I am unaware about any cases where -G would significantly improve situation

The most important one is probably the brainless admin unit labeling happening right now:

http://www.openstreetmap.org/#map=7/-58.066/-26.724
http://www.openstreetmap.org/#map=5/59.911/-173.914
http://www.openstreetmap.org/#map=8/28.739/-16.867

In some cases like place=archipelago but possibly also for other multipart multipolygon cases selecting the labeling points from SQL either based on convex hull or using several points for subpolygons could be an alternative. Of course ultimately mapnik should offer better labeling options on its own.

Collaborator

matkoniecz commented Jun 9, 2016 edited

Especially for http://www.openstreetmap.org/#map=8/28.739/-16.867

selection_011

-G in my opinion would make situation worse. Currently it is at least possible to know which island belongs to each country. The same applies in my opinion to USA/Russia

selection_012

Some better labelling would be better but for me in this cases for -G/without -G choice I would prefer too many duplicated labels over missing data.

And

selection_013

is hilariously horrible in way that makes clear that it was labelled by a simple computer program.

But http://www.openstreetmap.org/#map=7/6.948/147.393 tops that with

selection_002

and further east http://www.openstreetmap.org/#map=7/8.440/163.597 there is

selection_003

you'd be interested in seeing the effect from, I can post an image if it helps.

If it would not be too much trouble examples are welcomed.

Collaborator

imagico commented Jun 9, 2016

I disagree - showing duplicate labels here is nonsense. It might appear to be a way to show which admin units certain islands belong to but quite clearly one of the worst and most wasteful ways to do this. You will probably hardly find any other map that does this.

Not showing these duplicate labels will free room for showing labels for the islands which makes much more sense.

In any case keep in mind that with non-flattened multipolygons in the database you have more freedom since you can at least in principle generate separate labels for the different components. If you have them flattened however you cannot do it the other way round. So it seems it is the more flexible approach.

What i wrote in #1134 (comment) still applies here - implementing rules like that might be difficult but with flattened multipolygons it is definitely impossible.

Owner

gravitystorm commented Jun 10, 2016

In any case keep in mind that with non-flattened multipolygons in the database you have more freedom since you can at least in principle generate separate labels for the different components. If you have them flattened however you cannot do it the other way round. So it seems it is the more flexible approach.

Exactly. If there's a situation where duplicate labels makes sense, we can write an easy SQL query to label each polygon within the multipolygon. But without -G we're stuck in the current situation and have no good options.

I'm sure the -G thing in osm2pgsql is just for historical reasons - i.e. it should really be on by default, and not even provide an option to switch it off, but hey-ho.

@Komzpa Komzpa referenced this issue in openstreetmap/osm2pgsql Dec 22, 2016

Closed

Make -G / --multi-geometry option default #660

jojo4u commented Apr 17, 2017 edited

(Nearly) all country borders and the "Small Isles National Scenic Area" are tagged as type=boundary. Perhaps a type=boundary and type=multipolygon can be treated differently?

Edit: some more statistics from taginfo: 14 815 type=multipolygons with boundary=* and 464 136 type=boundary with boundary=*

Collaborator

pnorman commented Apr 17, 2017

Perhaps a type=boundary and type=multipolygon can be treated differently?

No, the option is for all geometry formation.

@pnorman pnorman closed this in d48106e May 10, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment