Place layer about openmaptiles HOT 23 CLOSED

I like that very much. Basically introducing settlement as class instead of writing styles explicitely for city, town...

I now always called it class and subclass (Tilezen calls it kind and kind_detail afaik).
So I would call place_detail -> subclass to follow the convention. Always happy for better naming conventions.

capital makes sense for a lot of styles 👍

I'm not certain of rank. As described, it ties an implementation into using Natural Earth data.

True but this doesn't necessarily need to be scalerank.
I would like to keep the rank, it can be NULL for other implementations or an alternative implementation but it is important to have rank to build a text hierarchy imho.

To state the docs.

The rank field for countries and states ranges from 1 to 6 while the rank field for cities ranges from 1 to 10 for the most important cities and continues from 10 serially based on the local importance of the city (derived from population and city class).

from openmaptiles.

Regarding the ranking on places - for http://osmnames.org/ - we have already an importance rank imported from the number of visitors on Wikipedia articles linked to places in OSM. For cartographical use, this absolute rank would need to be combined with a relative rank for a locality (rank similarly the two most important towns in every region / mercator tile, then ten most important, etc.) to be sure the map is not empty for some areas...

The docker for importing wikipedia rank to Posgres with OSM places is in:
https://github.com/OSMNames/OSMNames/tree/master/src/import-wikipedia

@pnorman and @nvkelso do you have any tips regarding this? Or do you know of reusable code for such ranking approach? Is there a better way how to rank places on a global level which should be applied?

from openmaptiles.

Regarding the ranking on places - for http://osmnames.org/ - we have already an importance rank imported from the number of visitors on Wikipedia articles linked to places in OSM. For cartographical use, this absolute rank would need to be combined with a relative rank for a locality (rank similarly the two most important towns in every region / mercator tile, then ten most important, etc.) to be sure the map is not empty for some areas...

I tested it with the rank from OSM Names a few months back but was not really usable for ranking it on a map.

To improve ranking later on (especially for POIs) I suggest merging OSM features with Wikidata claims - and then we have a lot more ranking information (and languages as well).

from openmaptiles.

@lukasmartinelli wrote

I tested it with the rank from OSM Names a few months back but was not really usable for ranking it on a map.

Why was OSMNames not usable - and can this be enhanced in OSMNames? If yes, how?

from openmaptiles.

Why was OSMNames not usable - and can this be enhanced in OSMNames? If yes, how?

Ranks are all in the same buckets - they cannot be used to really distinguish between important and non important features.

Script

%matplotlib inline
import pandas as pd
import numpy as np
df = pd.read_csv("./switzerland.tsv", delimiter="\t")
import matplotlib.pyplot as plt
import seaborn as sns
from scipy import stats, integrate

sns.set_context("notebook", font_scale=1.1)
sns.set_style("ticks")
sns.set(color_codes=True)

# all names
sns.plt.title('All')
sns.distplot(df.place_rank, kde=False, norm_hist=True)

# only places
places = df[df['class'] == 'place']
sns.plt.title('Places')
sns.distplot(places.place_rank, kde=False, norm_hist=True)

from openmaptiles.

Looks like bad numbers. And you think it's the OSMNames algo?
Or isn't it rather the Wikipedia data?
Why would Wikidata have more or better info?

from openmaptiles.

@lukasmartinelli you have tested a wrong column, get the importance data from OSMNames instead of place_rank. This absolute float number (0..1) must be combined with some sort of local rank for cartographical purpose - where you want to be sure you always show some but never too many places...

from openmaptiles.

IMHO the current place ranking works quite well. We can always improve it later first we need to clear the schema.

@pnorman Are we clear about the place layer?

I agree with your proposal (with the rename of place_detail to subclass and having a rank.

• class (String): country, state, settlement, subregion, or other.
• capital (Numeric): For settlements the place is a capital, what admin_level it is capital of. 2 and 4 only.
• subclass (String): For settlement, one of city, town, village, hamlet, isolated_dwelling. For subregion, suburb or neighbourhood. For other, one of locality or farm.
• rank (As discussed with 1-6 for country, state and 1-10 for settlement)

from openmaptiles.

@lukasmartinelli you have tested a wrong column, get the importance data from OSMNames instead of place_rank. This absolute float number (0..1) must be combined with some sort of local rank for cartographical purpose - where you want to be sure you always show some but never too many places...

Perhaps that works. If there is a Natural Earth scalerank I would always prefer NE - but for the ones that are not in NE that might help.

The importance values are better - with some care they could be transformed into a label rank.

from openmaptiles.

My concern with rank isn't about what implementation is best, it's that we're defining to be natural earth rank, and not what rank means. Saying that it is some property from OSMNames doesn't change that for me.

from openmaptiles.

My concern with rank isn't about what implementation is best, it's that we're defining to be natural earth rank, and not what rank means. Saying that it is some property from OSMNames doesn't change that for me.

We need a rank field to allow the client side renderer decide how much he wants to display and which text size to give them.

Can you agree with this definition? Or provide an alternative one.
How you end up with these ranks is decision of the implementation.

• rank (1-6 for country, state and 1-10 for settlement, lower means more important)

from openmaptiles.

We need a rank field to allow the client side renderer decide how much he wants to display and which text size to give them.

That's a useful definition.

@pnorman What do you think? Do you have additional requirements?

I'm willing to update e.g. OSMNames and enhance and/or rename current attribute 'importance' in order to fulfill these needs.

from openmaptiles.

rank (1-6 for country, state and 1-10 for settlement, lower means more important)

That's probably enough to work from for now - given the other schema issues open, I don't want to get bogged down in this.

from openmaptiles.

Actually, enhancing the rank attribute (e.g. in OSMNames) was an offer to enhance this whole project - and also relieve you ;-)

from openmaptiles.

@pnorman Check the newest layer docs incorporating your feedback (Wiki is generated - do not edit)

• place: https://github.com/openmaptiles/openmaptiles/wiki/place

from openmaptiles.

Nice work!

I don't see a reason to add a handful of more detailed values in 'sublass' (instead of 'other' in class). I would just omit sublass and put all values in class. In case you keep 'subclass', I would add some textual justification for the value range class (e.g. why 'other'?).

Then, I think it would be fruitful for this and Nominatim to align the hierarchies. Looking at https://wiki.openstreetmap.org/wiki/Nominatim/Development_overview#Country_to_street_level it seems to me that e.g. "county" is missing in subclass between "state" and "city"?

from openmaptiles.

I don't see a reason to add a handful of more detailed values in 'sublass' (instead of 'other' in class). I would just omit sublass and put all values in class. In case you keep 'subclass', I would add some textual justification for the value range class (e.g. why 'other'?).

I would actually prefer that - like before when I just had a class.

Now in the styles I anyway need to target city, town, village, suburb in different style layers (country, state as well) and then a style layer for all the others. So I don't need to use the class=settlement or class=subregion

@pnorman Do you have strong reasons for grouping them into class=settlement and class=subregion versus just having the plain place value in class ?

For me in practice the settlement and subregion were too broad for styling now.
In OSM clear you use class but there you always combine it with rank.

https://github.com/ClearTables/osm-clear/blob/master/osm-clear.tm2/place.mss#L2

from openmaptiles.

@pnorman Do you have strong reasons for grouping them into class=settlement and class=subregion versus just having the plain place value in class ?

The reason for doing it like that in-DB is that settlements and subregions are different, and it doesn't make sense to compare between them. It lets you do WHERE (class = 'settlement' AND rank >= 'town') OR (class = 'subregion' AND rank >= 'suburb'). This doesn't apply to vector tiles because you can't have enumerated types there

For reference, how I'm dividing it in DB is

local settlements = {
    city=true,
    town=true,
    village=true,
    hamlet=true,
    isolated_dwelling=true
}

local subregions = {
    suburb=true,
    neighbourhood=true
}

local other = {
    locality=true,
    farm=true
}

from openmaptiles.

The reason for doing it like that in-DB is that settlements and subregions are different, and it doesn't make sense to compare between them. It lets you do WHERE (class = 'settlement' AND rank >= 'town') OR (class = 'subregion' AND rank >= 'suburb'). This doesn't apply to vector tiles because you can't have enumerated types there

For the vector tile schema is something against reverting back to have everything in class?

You can still have that in your DB-Schema (where like you explained it is really neat to have enumerated types) and render differently in Mapnik for WMF - but in the vector tile schema of OpenMapTiles there could be just class.

from openmaptiles.

I am now again using the old class (which maps directly to the place=).
There is no need in all our styles for a higher level concept like settlement or subregion because places are styled individually for each place=.
If WMF needs it one can still add it to that superset.

from openmaptiles.

For the vector tile schema is something against reverting back to have everything in class?

I can work with it either way

from openmaptiles.

What needs to be done to resolve this?

from openmaptiles.

The schema in place as described in https://openmaptiles.org/schema/#place works well for us and all the styles in https://openmaptiles.org/styles/.

If you want additional fields in the schema docs (superset) please note otherwise we would like to leave it as it is for OpenMapTiles.

from openmaptiles.