order placement of city/towns names

[cquest]

use population tag to place city/town names of major cities/towns first.

Fixes #1083

[mrwojo]

Null population is sorting ahead of all population values, which doesn't seem right. Either nulls last on pop or concat('0',population) would put them at the end.

Also, should it be more conservative? "100 (Census 2000)" casts to 1002000.

👍 though: This should fix Bellevue blocking Seattle at z 6-9.

[cquest]

The concat is already there: '0' || population = concat('0',population)

"population=100 (Census 2000)" is an error, and if it makes this error visible it has much more chances to be fixed ;)

I've been using this population ordering on the OSM-FR tiles and Seattle is there: http://tile.openstreetmap.fr/?zoom=8&lat=47.61191&lon=-122.19924&layers=B0000000FFFFFF

[tomhughes]

I doubt that concat will work as concatenating anything to null probably gives you null - if you want to map null to another value then use ifnull.

[mrwojo]

|| on null gives null. concat ignores nulls:

gis=# select '0' || null, concat('0', null);
 ?column? | concat
----------+--------
          | 0

The function was added in 9.1.

[cquest]

I didn't know || and concat where different. Concat is now used in place of ||

[gravitystorm]

Does anyone have any comments on this creating a minimum required version for postgresql? Until now I think the stylesheets have worked on 8.4 and 9.0, right?

[tomhughes]

Well we're running 9.1 in production on the OSM servers.

[pnorman]

8.4+1.5 is substantially slower than 9.1+2.0 on the osm2pgsql side. I'm not the typical developer, but I do my testing on 9.3+2.1.

That being said, why not NULLS LAST or COALESCE()?

[ghost]

I implemented this for the german style. Our population-select returns only an integer, if the population value is a real integer:

CASE WHEN tags->'population' ~ '^[0-9]+$' 
 THEN (tags->'population')::integer 
 ELSE 0 END as "population",

https://trac.openstreetmap.org/changeset/30322/subversion

[pnorman]

CASE WHEN tags->'population' ~ '^[0-9]+$' 
 THEN (tags->'population')::integer 
 ELSE 0 END as "population",

I'm working on place=city/town and #103 and just wanted to note that the SQL here doesn't work in the case of a population tag that exceeds the size of an integer. Such a tag would be wrong, but shouldn't break the rendering

[matkoniecz]

Fixes #1083 (added to description).

[daganzdaanda]

Just for future reference:
In another issue, Vincent linked to an intersting talk at "SOTM-EU 2014": Maxim Rylov, Cartographically Plausible Label Placement

[pnorman]

Closing. Would need rewriting against YAML, and the SQL chosen isn't the best method.

[matthijsmelissen]

the SQL chosen isn't the best method.

Could you expand on what is wrong with this method? I would like to fix the SQL, so reopening.

[pnorman]

The SQL done for layernotnull is better. But unless @cquest wants to rebase this we need to close this PR and open a new one.

[kocio-pl]

@cquest:

I've been using this population ordering on the OSM-FR tiles and Seattle is there:

The problem is more complex than the population alone - Seattle is also tagged as a city with importance=national, while Bellevue is just a town. I guess admin_centre can also be a hint for rendering (#1391). So we have 4 factors of visibility - which should we use and in what order? :

1. place
2. population
3. importance
4. admin_level + admin_centre

[mrwojo]

Bellevue was place=city when this was originally written. This is looking at population merely as a tiebreaker when the place tags are equal.

[kocio-pl]

But my question is still valid: what should we render if the capital is less populated than a place with conflicting name label? Do we want to use "importance" tag (long time draft)? There can be many cases involving one or more of these tags, so it would be good to know which tags/features labels we want to show on general map when they are clashing.

[gravitystorm]

Do we want to use "importance" tag (long time draft)?

No, absolutely not. That's a completely subjective tag and a hugely bad proposal for tagging.

[kocio-pl]

So we're left with "only" 3 more or less objective hinting tags. =} I guess I would treat admin_* tags as the most important hint, then I would check place type (this one is less objective than the rest) and population as the last resort. However that's only my intuition that it would work the best.

[imagico]

The usual approach would be to calculate a score based on the various properties that are to be considered. For example you could use the population as score and multiply it with a factor of for example three in case it is a national capital. This would mean a larger city is only rendered with preference if its population is more than three times that of the capital.

[dieterdreist]

2015-03-24 13:32 GMT+01:00 Andy Allan notifications@github.com:

No, absolutely not. That's a completely subjective tag and a hugely bad
proposal for tagging.

while I agree, it should be noted that every ranking of cities will be
subjective / colored / biased, including the natural earth dataset we are
currently using. Even if you try your best to set up very objective
scientific rules how to bring in and compare several properties, it can
always be contested how you balance these properties or which aspects you
look at and which you ignore, etc.

[gravitystorm]

every ranking of cities will be subjective / colored / biased

Of course. But the way it works is that the consumers of the data (e.g. openstreetmap-carto) each have their own subjective ranking, based on whatever objective information we choose to use in OSM and/or elsewhere. But that's where the subjective decisions get made, not by the mappers (otherwise chaos and endless edit wars ensue).

Ranking cities by importance is like choosing what roads show up on which zoom levels - it's a subjective issue, for the cartographers to juggle. Each map will choose differently. Thankfully we don't have a "zoom" tag in OSM (e.g. "highway=motorway;zoom=6") and we shouldn't have an "importance" tag either.