Recommend -G flag for multipolygons

[pnorman]

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?

[ajashton]

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.

[pnorman]

as of https://github.com/openstreetmap/osm2pgsql/commit/34a30092d64e03b44be4d5117badd717c53c0b6b we are suggesting -G for osm2pgsql by default, osm-carto's README.md should reflect this. It should also be suggesting slim mode

[pnorman]

Confirming that -G fixes this.

Without (orm):

With:

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.

[gravitystorm]

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?

[tyrasd]

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?

[pnorman]

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.

[springmeyer]

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.

[pnorman]

Running a performance benchmark on -G now.

[pnorman]

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.

[matthijsmelissen]

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?

[imagico]

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.

[HolgerJeromin]

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

[jojo4u]

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?

[dieterdreist]

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.

[matkoniecz]

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

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

And in many cases, for example for

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

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

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

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

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

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.

[matkoniecz]

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

Example found by @HolgerJeromin in https://github.com/gravitystorm/openstreetmap-carto/issues/59#issuecomment-113189830

[SomeoneElseOSM]

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.

[imagico]

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.

[matkoniecz]

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

-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

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

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

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

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.

[imagico]

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 https://github.com/gravitystorm/openstreetmap-carto/pull/1134#issuecomment-66908771 still applies here - implementing rules like that might be difficult but with flattened multipolygons it is definitely impossible.

[gravitystorm]

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.

[jojo4u]

(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=

[pnorman]

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

No, the option is for all geometry formation.