Openstreetmap-carto: Render place names on areas the same way as on nodes

[joakimfors]

Currently place names are only "correctly" rendered when mapped on nodes. Place names should be rendered in the same way when placed on closed ways and relations.

[pnorman]

It looks like everything is in the database to do this, just needs SQL queries. I'll have a go at it, time permitting

[Grillmannen]

This seems to work now? See http://www.openstreetmap.org/way/47227971 in issue #425.

[chrisfleming]

@Grillmannen Think that example might work because of the landuse=residential

I think I have a solution for this, if bedtime goes well this evening then I should get the pull request in tonight...

[Grillmannen]

Previously name= wouldn't render on place= even if it was also tagged as landuse= though.

[matthijsmelissen]

See also https://trac.openstreetmap.org/ticket/2090

[pnorman]

Fixing this raises a slight issue: There's a lot of duplication out there between place nodes and place areas. I got a 4k duplicates on a preliminary search (identical name, place and with 0.1 degrees)

[joakimfors]

I guess that's because people are tagging for the renderer now, or at least not noticing that it is already tagged as it doesn't show up on the tiles. 4k doesn't sound like a lot and will be fixed quite fast if duplicates show up on the map.

[matthijsmelissen]

Removing the nodes leads to loss of information (the center of the place) though.

[pnorman]

The entire area is the place if it's been tagged on the area.

The issue is that some admin boundaries have been tagged with place when the administrative entity is not the same as the place, which _tends_ to be smaller.

[dieterdreist]

2014-05-15 12:05 GMT+02:00 Paul Norman [email protected]:

The issue is that some admin boundaries have been tagged with place when
the administrative entity is not the same as the place, which _tends_ to
be smaller.

these are hard to spot currently, but if we started to render place areas
in gray (or something like that) to highlight built up areas, this practise
would probably stop fast ;-)

[matthijsmelissen]

This is country-specific. For example, if I'm not mistaken, in Poland, the countryside is seen as part of a place as well. If you see a begin-of-place X sign driving in one direction, you usually see a begin-of-place Y sign in the other direction.

[dieterdreist]

2014-05-15 13:33 GMT+02:00 math1985 [email protected]:

This is country-specific. For example, if I'm not mistaken, in Poland, the
countryside is seen as part of a place as well. If you see a begin-of-place
X sign driving in one direction, you usually see a begin-of-place Y sign in
the other direction.

I dispute that this is something country-specific. If the definition for
some place values is to be a settlement, it can't be something that is not
a settlement. My guess is you are confusing this with administrative
entities. The signs you see are administrative signs.

I'd see places as part of settlement geography, have a look here:
http://en.wikipedia.org/wiki/Settlement_geography
this is something orthogonal to the law or administrative divisions.

[matthijsmelissen]

I think even the notion of a settlement is complicated in rural Poland. For example, which houses here are part of the settlement and which ones are not?

Maybe @mkoniecz can also give his opinion.

[dieterdreist]

2014-05-15 18:33 GMT+02:00 math1985 [email protected]:

I think even the notion of a settlement is complicated in rural Poland.
For example, which houses (http://binged.it/1g8TFxm)[here] are part of
the settlement and which ones are not?

this is of course up to the local mapper to decide. My personal opinion on
the sprawl in the linked map is that it is probably all one low density
settlement (but I don't know the area).

You can find similar situations in all places with few regulation or few
control or high corruption levels ;-)
this doesn't make the meaning of the place tag country specific.

cheers,
Martin

[matkoniecz]

In Poland every house (except some extreme exceptions) belongs to some settlement.

"If you see a begin-of-place X sign driving in one direction, you usually see a begin-of-place Y sign in the other direction. " is true.

"signs are are about administrative boundaries" is also true.

"notion of a settlement is complicated in rural Poland" is 100% true.

Translation is tricky issue. Question whatever fields in rural areas belong to settlement received "I am not sure but rather no", "I am not sure but rather yes" and "I am not sure" in my micro survey.

http://mapy.geoportal.gov.pl/imap/?locale=en&gui=new&sessionID=1303907 - map of Poland, published by government, with settlement labels (note that it is .gov.pl website so it is broken/buggy/laggy half of the time).

[matthijsmelissen]

The entire area is the place if it's been tagged on the area.

Yes, but I think it would be better to render for example 'New York' in Manhattan than in the middle of the polygon.

Same for Lisbon, Barcelona, Napoli, etc.

Making place=city a relation as in the Lisboa case is the best way of tagging, I think.

[dieterdreist]

2014-05-19 22:32 GMT+02:00 Mateusz Konieczny [email protected]:

In Poland every house (except some extreme exceptions) belongs to some
settlement.

sounds as if you were still talking about administrative entities and not
geographic entities. In all countries I am aware of the whole area is
covered by several administrative entities of several levels (e.g. down to
the level "municipality" or even less). This doesn't make the whole country
a settlement, and neither should those entire administrative entities get
the OSM-tag "place"=city/town/village/...

"in Poland, the countryside is seen as part of a place as well. If you see
a begin-of-place X sign driving in one direction, you usually see a
begin-of-place Y sign in the other direction. " is true.

what you see is signs of administrative limits. You can also see those
signs in many other countries. These are (typically) not the limits of a
place but of an administrative entity with the same name.

Translation is tricky issue. Question whatever fields in rural areas
belong to settlement received "I am not sure but rather no", "I am not sure
but rather yes" and "I am not sure" in my micro survey.

if the fields aren't (almost) completely enclosed in the settlement (there
are buildings all around) I think the answer is simple: no, the fields are
not part of the place-entity.

[matthijsmelissen]

if the fields aren't (almost) completely enclosed in the settlement (there are buildings all around) I think the answer is simple: no, the fields are not part of the place-entity.

I know this is how it works in Germany, but this is not how things are seen in Poland, in my experience.

[dieterdreist]

2014-05-21 15:53 GMT+02:00 math1985 [email protected]:

I know this is how it works in Germany, but this is not how things are
seen in Poland, in my experience.

I don't think that the definitions of the keys in OSM should be interpreted
so differently on a country base. This is not about Poland or Germany, but
about what a certain tag states. A huge area of fields is not a "human
settlement", in no country and by no definition I am aware of.

If in Poland the general perception for settlements is that they extend
into the rural countryside you should state extrabold in the polish wiki
that in OSM things are mapped differently ;-)

[matthijsmelissen]

See also https://trac.openstreetmap.org/ticket/4151

[xenos1984]

Is there any progress on this issue?

Just another thought I would like to add, although I don't know whether this would be working: Many place=* areas are mapped as multipolygons with an additional node with role admin_centre. Would it be possible to check for such a member and render the place name for the area only once at this point?

[matthijsmelissen]

Is there any progress on this issue?

No, there is still no agreement on whether this is a good idea or not.

[skylerbunny]

Ran into this, while discovering that for place=(suburb|village|hamlet|neighbourhood|locality|isolated_dwelling|farm), points render and areas do not, so now I'm stuck trying to figure out how to make Mapnik render the following non-administrative census designated place, which has a defined area, as a named place:

http://www.openstreetmap.org/way/389991209

This can also be found in neighborhoods with defined edges. Examples: ways 388843930 and 313909239.

My take on this:

1. This issue is not talking about administrative areas, nor should it be confused for doing so. That is completely covered in https://github.com/gravitystorm/openstreetmap-carto/issues/104 , discussing how and where to place a label involving administrative boundary relations and its members.
2. Numerous cases exist where a non-administrative boundary that is ALSO one of the set of (suburb|village|hamlet|neighbourhood|locality|isolated_dwelling|farm), is a documentable area rather than a point: see above.
3. All of the above show on the Wiki as having acceptable use on areas. If it's 'not a good idea to render areas' with place=(the above), then further pollution needs to be stopped by declaring areas as invalid structures to hold those place types. What guidance do people receive to not use areas, other than that Mapnik won't show their names?

If and until (3) happens, I can't really see the downside in displaying the names of these areas at their geographical center(s) (area or multipolygon). Being able to identify multipolygons with nodes as members for labelling might be nice, but an appropriate first step IMHO would be rendering a name at the center of an area of these place names. Those place names not being in an ideal spot isn't ideal, but at least prevents people double tagging place nodes for the renderer, which I don't want to do either.

Failing that, what advice can be given for what I should do tagging these cases?

[pnorman]

Failing that, what advice can be given for what I should do tagging these cases?

For tagging, you should ask help.openstreetmap.org, the tagging list, or somewhere else. If we change what we render it won't change what the appropriate tagging is.

[skylerbunny]

Understood on that point. If the fallback goes to 'It's not us' (entirely fair), the standing consensus (both prescriptively and 'in the field') already is that the appropriate tagging for these place types is both nodes and areas.

[dieterdreist]

sent from a phone

Am 07.01.2016 um 06:35 schrieb skylerbunny [email protected]:

which has a defined area, as a named place:

http://www.openstreetmap.org/way/389991209

while I advocate place areas, this one looks odd. Why is this strange part of the wetland part of the settlement? IMHO a place area should cover the settlement but not parts that clearly don't belong to it.

[skylerbunny]

Why is this strange part of the wetland part of the settlement?

Aha. Basically, 'because the U.S. census bureau said so'. It's a census designated place. I added the census.gov source PDF (and a boundary=census) tag to the way, have a look.

That being fixed/sourced, of course, I don't want the topic to stray too much into why place areas are what they are, and want to stay zeroed in on the fact that Mapnik doesn't render their names.

[dieterdreist]

2016-01-07 18:31 GMT+01:00 skylerbunny [email protected]:

Aha. Basically, 'because the U.S. census bureau said so'. It's a census
designated place. I added the census.gov source PDF (and a
boundary=census) tag to the way, have a look.

That being fixed/sourced, of course, I don't want the topic to stray too
much into why place areas are what they are, and want to stay zeroed in on
the fact that Mapnik doesn't render their names.

For discussions what place areas are, we should likely move over to the
tagging ML. From my point of view, boundaries from official authorities
which do not describe settlements, but are basically orthogonal
administrative boundaries (e.g. used for statistical purposes) should get a
different tag and not be mapped as place areas. From a socio-geographic
viewpoint, these wetlands and farmlands are not part of the hamlet (or more
general settlement), as they are neither built up, nor encircled or in a
similar way delimited.

[skylerbunny]

For discussions what place areas are, we should likely move over to the tagging ML.

Exactly. The _death_ of this bug report (as it has been in the past, above) has been straying into discussions appropriate for the tagging ML.

The tl;dr of issue 103 has been 'regardless of where I want to tag place names, and even whether correct or not - _all_ of which is tagging ML discussion anyway - their names don't render in the Mapnik scheme'.

[dieterdreist]

2016-01-07 18:53 GMT+01:00 skylerbunny [email protected]:

The tl;dr of issue 103 has been 'regardless of where I want to tag place
names, and even whether correct or not - _all_ of which is tagging ML
discussion anyway - their names don't render in the Mapnik scheme'.

yes, but if you post inappropriately tagged objects as examples it is hard
to discuss appropriate rendering solutions.

[skylerbunny]

I was thinking on this: How about this, as a 'reasonable first pass'?

1. place=(suburb|village|hamlet|neighbourhood|locality|isolated_dwelling|farm) gets a text label in the center of each distinct area it encompasses, at the same text size a node of the same type would already get. For simple areas, this means one label; for multipolygons, it means multiple text labels, one for each area. I refer here, to the same method of name labeling that is used for leisure=nature reserve (see http://www.openstreetmap.org/relation/5012497 ).
2. We do NOT address/change in any way border lines or area coloration _of_ these areas in this issue, and doing (1) means this issue can be marked closed.

My guess, anyway, is that exposing the very existence of these areas to Mapnik users/editors by doing (1) will prompt discussion about just _how_ to display their edges - and if appropriate, generate discussion on the ML about how the areas are being tagged.

[dieterdreist]

2016-01-07 21:00 GMT+01:00 skylerbunny [email protected]:

I was thinking on this: How about this, as a 'reasonable first pass'?

1. place=(suburb|village|hamlet|neighbourhood|locality|isolated_dwelling|farm)
   gets a text label in the center of each distinct area it encompasses, at
   the same text size a node of the same type would already get.

what about town and city? "locality" is a placeholder for more specific
placenames, but not to be used on settlements/inhabited places, so I'd
remove it from this list.

1.

My guess, anyway, is that exposing the very existence of these areas to
Mapnik users/editors by doing (1) will prompt discussion about just _how_
to display their edges - and if appropriate, generate discussion on the ML
about how the areas are being tagged.

rather than the edges I'd use the polygons for rendering built-up areas in
low to low-medium zoom levels instead of (landuses and) the shapefile.

[gravitystorm]

the fact that Mapnik doesn't render their names

Just as an aside, please refer to these stylesheets as "openstreetmap-carto", not "Mapnik" - Mapnik is a rendering library used by many different stylesheets, and mixing names around confuses and likely discourages people from contributing.

[skylerbunny]

Just as an aside, please refer to these stylesheets as "openstreetmap-carto"

No problem, my mistake. Sorry about that.

I took that list above from the source, from https://github.com/gravitystorm/openstreetmap-carto/blob/6ac399d63876cfe03f25f324b4023e7a329d4ee2/project.yaml#L1537

Looking right above that line, I can see that 'city' and 'town' would in fact also be included in this list if their areas don't already have names rendered elsewhere in openstreetmap-carto's source code.

Re locality areas, http://wiki.openstreetmap.org/wiki/Tag:place%3Dlocality indicates that an area is a valid use, and it is used in fairly frequently in Europe, SE and Western United States, and Alaska (7100 cases). http://overpass-turbo.eu/s/dD5 . Having said that, the wiki DOES only talks about localities used on nodes, and I agree in principle with your point. It could be argued that a fix for this is to simply edit the wiki to disallow locality on areas in the infobox to make that page consistent.

EDIT: Alternatively, we can just avoid the locality issue entirely for now, as you said, by both removing it from this list, and not bothering with any changes to the Wiki/tagging/etc.

[pnorman]

Because we've changed how we render place names since this issue was raised, it now depends on the schema change for capital and population for polygons.

[Hjart]

place=* area names are still not rendered (see i.e. (http://www.openstreetmap.org/way/492177524). Personally I much prefer to have them actually be areas rather than just nodes, so I'll really really appreciate finally having them rendered. I don't understand how this can still be an issue.

[dieterdreist]

2017-06-10 19:11 GMT+02:00 Michael Andersen [e-mail]:

place=* area names are still not rendered (see i.e. (
http://www.openstreetmap.org/way/492177524). Personally I much prefer to
have them actually be areas rather than just nodes, so I'll really really
appreciate finally having them rendered. I don't understand how this can
still be an issue.

My guess is some people do not want mappers to map places (only) as areas,
and current usage is not consistent for all values, e.g.

1. could lead to edit wars sometimes
2. mappers might omit the central node (i.e. loss of information)
3. sometimes place tags are added to administrative entities, where the
   place arguably only covers part of the administrative entity
4. difficulty to avoid duplicate names if a node and an area are mapped for
   the same place

FWIW, I'm in favor of rendering names from place polygons, but duplicate
names should be avoided if possible (even if there's a node and an area).

[jojo4u]

I have drafted an article with some scenarios: https://wiki.openstreetmap.org/wiki/Proposed_features/place_areas
My preferred solution would be scenario A: The introduction of boundary=place on closed ways (areas) and of tag boundary=place for type=boundary relations. The place nodes are put in the relation as role place_centre.

[Pikse]

This bug should be about simply making it possible to show place name on centroid when place=* is set in combination with whatever keys deemed appropriate and in regions where appropriate.

Obviously settlements are understood differently in different regions, as shown above. Some countries have settlements as officially designated territorial units (not administrative units), other don't. Some regions are considered to have dispersed settlements, in others separate household are not considered to be part of any settlement. Map should simply reflect that, so this can't be an issue here.

[stevenLAD]

I am having difficulty understanding this issue. There appears to be some consensus that areas should be named as it renders the maps more usable (and meaningful IMHO). I have proposed a solution but that was rejected as closed (2792) - at present, as someone has already said in this thread, the renderer ignores polygons when looking for place names.

The issue appears to be duplicity between areas and nodes, but as long as this is not resolved, that duplicity will only increase as people try to workaround the problem by adding nodes to areas, and by using landuse=residential (which works but is not the OSM approved way).

[drkludge]

In #2792 you mentioned placenames. I recently changed placename tags to name tags. As far as Keepright said, placename is deprecated use name tag. But I am not sure that I have answered your question.

[skylerbunny]

Original bug, 4 years ago:

Currently place names are only "correctly" rendered when mapped on nodes. Place names should be rendered in the same way when placed on closed ways and relations.

Today:

The issue appears to be duplicity between areas and nodes, but as long as this is not resolved, that duplicity will only increase as people try to workaround the problem...

Please consider this...I admit I'm frustrated in advance.

If this bug had been resolved four years ago, by this time, node and area duplication would have been eliminated years ago by way of iterative cleanup. The only reason this bug still is open IMHO is because there is a faction that continues to argue whether areas should be mapped, when the community decided de-facto years ago that they would be. The wiki mentions it as a supported use case. It's so widespread that a special note exists on the place= wiki page referencing this bug to explain why it doesn't render. What exactly is the problem with implementing this?

No amount of principled or wishful thinking will prevent people from using place tags on areas, or address issues with doing so through discussion _here, in this bug_. If the issue is duplication, expose the issue to the mapping community by rendering the areas and nodes both. They're there whether we like it or not.

Users WILL resolve duplication over time, or find better, more specific non place area tags over time. Maybe new tags will even be created to address edge cases. But users need to be made aware they're even there. Thus, rendering.

[kocio-pl]

I feel that it should be rendered, because place is basically a name - so it relates to any geometric entity (for example #2673). See also https://en.wikipedia.org/wiki/Toponymy .

[AragonChristopherR17Z]

What I do is make a multipolygon of, for example, a neighborhood and make a relation to a named neighborhood point as the label. :P
For example: https://www.openstreetmap.org/relation/7543322

[skylerbunny]

@kocio-pl I also replied related to this at https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/place_areas , whose proposal seems to try to solve about three problems at once. I suggest we solve one problem - render the areas, the one in this bug. It will lend visibility to those other problems (like 'do we even want to be using tag X?' or 'but we don't have a way that openstreetmap-carto renders a label for an area', and 'but this will cause name rendering duplication') on its own. Any of those can be solved through, and a solution for them will almost certainly be accelerated by -- rendering the areas.

In the above wiki location, I suggested using the same method of rendering place areas as we do for land_use areas/multipolygons, probably without a special border/fill color. It's easy, it gets the job done, and it will move this forward.

[chrisfleming]

We do really need to get this sorted, I did propose some kind of improvemnt 3 years ago: https://github.com/gravitystorm/openstreetmap-carto/pull/427 - It got pulled into a bigger update that never made it through.

Lots of data users DO render placename based on node and or area and in those cases names are rendered twice. Where I am (Edinburgh) the plan was to 1. add area's across the city, 2. Get rendering working on areas before 3. removing the "center" nodes. We have never got past step 2.

Furthermore it seems to me that the default mapbox themes, cycle.travel, and the cycle map all do render both the area name and the node names.

[lukaszkruk]

Joining the many who cry for this to be fixed.

I'm suggesting the simplest possible solution: name of a place drawn as a closed way should be styled like name of a place drawn as a node. This is the scope of the original bug report.

Are there any practical steps that should be taken to achieve this? Is there a need for a vote or some other procedure?

[pnorman]

Are there any practical steps that should be taken to achieve this? Is there a need for a vote or some other procedure?

No, a pull request is needed.

[mboeringa]

See my remark on the pull:

https://github.com/gravitystorm/openstreetmap-carto/pull/2816#issuecomment-328298417

[Komzpa]

I believe the only way this could be done, compatible with both node-tagging, area-tagging and mixed-tagging, is like this:

https://github.com/gravitystorm/openstreetmap-carto/pull/2939

If anyone wants names on polygons rendered please get this PR un-closed by maintainers and merged.

[vbertola]

I just want to add a couple of points continuing the thread on #2816.

@imagico still fails to understand that there are places which have defined borders and yet are not administrative units or landuses or other existing types, but just... places. I can bring my example once again: the suburbs in Turin (a 1-million-people city) were administrative units until 1985, but they were then grouped into bigger boroughs (that of course we mapped as administrative units). We cannot map the suburbs as administrative units, as they are not that any more. However, the suburbs still have well known borders from that time, and are still in use, much more than the boroughs, as place names. They are still used as the basis for civic committees, working groups and so on, so knowing exactly whether a street is in this or that suburb is useful and makes a difference. How in the hell could I map these places precisely as a node? Again, I'm fine if I am required to add a node as admin_centre as a tagging fiction, even if there is no "admin" and no "centre" in the suburb, but please stop saying that all people that want to map a place as an area are just wrong and their areas are fake and "meaningless". Maybe this is true in your surroundings, but it is not true everywhere.

Also, how reasonable it is to continuously challenge the fact that there is "inconsistency" in places-as-areas because some people draw areas around built-up land while others around the entire territory or around some other geometry, while at the same time there is the same inconsistency in places-as-nodes, with some people putting the node at the centroid of the area while others put it in the main square and others on the town hall and so on, but this is not considered a problem? I really don't understand.

[Komzpa]

@vbertola there are fundamentally three ways to map a region:

1. as area
2. as area + point
3. as point.

There is a narrative "area+point is a duplicate" (it is not, as point brings socioeconomic info that just plain OGC Simple Features Polygon can't store, you have to implement a complex datatype with a point and an area to maintain the eyecandy if you somewhen finally decide to show place= as a fill like many maps do).

There is a narrative "we can't implement logic that will skip rendering label for area if it is rendered for point" (it is false, you can and it's implemented in #2939)

There is a narrative "some other users will have to implement similar logic". (it is false, if they don't care they can skip implementing it, and if they care they may do that if they wish and have a solid example how to do so.)

Right now OSM-Carto supports 2 and 3, as it only supports point mapping. You can map the neighbourhoods as point+area, and it will render a label and database will keep an area for other uses. If you wish to add support for 1, it is in #2939.

[dieterdreist]

Am Di., 8. Jan. 2019 um 10:12 Uhr schrieb Vittorio Bertola <
[email protected]>:

I just want to add a couple of points continuing the thread on #2816
https://github.com/gravitystorm/openstreetmap-carto/pull/2816.

@imagico https://github.com/imagico still fails to understand that
there are places which have defined borders and yet are not administrative
units or landuses or other existing types, but just... places. I can bring
my example once again: the suburbs in Turin (a 1-million-people city) were
administrative units until 1985, but they were then grouped into bigger
boroughs (that of course we mapped as administrative units).

in Rome there are also different layers of named areas, which only
sometimes coincide with administrative subdivisions.

And you can often define neighbourhoods outside the centre core by looking
at the structure: areas developped in the same time, often as one project
(same lead architect/s, same style, etc.). Also in centres you might be
able to identify specific quarters or neighbourhoods with specific
properties, e.g. from medieval professions like tanners or dyers, jewish
ghettoes, etc., or more recently settlement parts for factory workers,
entertainment districts, ...

[Pikse]

@dieterdreist And you can often define neighbourhoods outside the centre core by looking at the structure: areas developped in the same time, often as one project (same lead architect/s, same style, etc.). Also in centres you might be able to identify specific quarters or neighbourhoods with specific properties ...

These arbitrary or unverifiable areas that may be inappropriately tagged as "place" don't really stand a comparison with non-administrative neighbourhoods that have designated or otherwise well-defined borders. Several other types of places that are valid use cases of place as an area have been mentioned previously here and in comments to related pull requests. Yesterday, I tried to provide a brief overview here. Some people seem to think that if there are no places (non-administrative, not landuse equivalent) with well-defined borders in region where they live then there are no such places in rest of the world either. Once we get over this misconception, then we'll probably be much closer to solution.

[jeisenbe]

Since both PR #2816 (render labels on settlement place nodes and areas) and PR #2939 (only render settlement place nodes on areas if there is no node with the same tags inside) were rejected, I'm closing this issue. However, if there is another solution that I've overlooked, please feel free to continue discussion or submit a PR.

[Hjart]

As a mapper and a data user, I have to say that I'm seriously disappointed that this is getting nowhere ..

[dawansv]

As a mapper and a data user, I have to say that I'm seriously disappointed that this is getting nowhere ..

I too am disappointed this was closed with no guidance. My organization has local teams working in villages in Mali, and over the years we have added vilage names as we collect them in the field. It is quite important to us to be able to litterally put these villages on the map by naming them and a great complement to the incredible work done by the mapping community using satelitte imagery. So our contribution is very limited but important I think. What kind of guidance is given to people like us? Now we have a situation were some more experienced mappers are merging node information with areas. The rendering is completely different. But we are certainly in no position to give these more experienced mappers any lesson or guidance.

Look at that area south of Bamako for instance.
https://www.openstreetmap.org/#map=9/12.3024/-7.6382
Villages that have names as nodes appear around zoom level 9. But a lot of villages that have been named are no longer labelled until your reach zoom level 13 because their name nodes have been merged into their areas.

What are we supposed to do with that? Are we supposed to manually undo the work of more experienced mappers and re-add duplicate points to areas that don't have them? That doesn't make any sense since there is no guidance telling mappers NOT to put names into areas.

[lukaszkruk]

As a mapper and a data user, I have to say that I'm seriously disappointed that this is getting nowhere ..

I too am disappointed this was closed with no guidance. My organization has local teams working in villages in Mali, and over the years we have added vilage names as we collect them in the field. It is quite important to us to be able to litterally put these villages on the map by naming them and a great complement to the incredible work done by the mapping community using satelitte imagery. So our contribution is very limited but important I think. What kind of guidance is given to people like us? Now we have a situation were some more experienced mappers are merging node information with areas. The rendering is completely different. But we are certainly in no position to give these more experienced mappers any lesson or guidance.

Look at that area south of Bamako for instance.
https://www.openstreetmap.org/#map=9/12.3024/-7.6382
Villages that have names as nodes appear around zoom level 9. But a lot of villages that have been named are no longer labelled until your reach zoom level 13 because their name nodes have been merged into their areas.

What are we supposed to do with that? Are we supposed to manually undo the work of more experienced mappers and re-add duplicate points to areas that don't have them? That doesn't make any sense since there is no guidance telling mappers NOT to put names into areas.

I used to recommend to switch to another renderer ("Layers" on the right-hand side of the osm.org website), since they used to render area place names, but now it seems they also don't. Does anyone know if their behaviour was changed to be consistent with osm-carto, or am I missing something, or possibly going crazy?

[jeisenbe]

The OpenCycleMap and Transport map styles are proprietary, but I do not think they have changed recently. You could contact https://www.thunderforest.com/contact/ to confirm. _(EDIT: they were changed a few years ago: https://github.com/gravitystorm/openstreetmap-carto/issues/103#issuecomment-646660662) _

The HDM / HOT style ("Humanitarian") is at https://github.com/hotosm/HDM-CartoCSS and there have been no changes in the rendering of place names.

[jeisenbe]

Re: " re-add duplicate points to areas that don't have them"

A place node is not a duplicate of an administrative area. For example, consider https://www.openstreetmap.org/node/6474240715 and https://www.openstreetmap.org/relation/112100 - the first is the node which represents the approximate center of the place called "Long Beach" in California, which is located in the southwest corner of the land are of the municipality which is represented by the relation.

When you want to route to "Long Beach" from Los Angeles, you don't want to end up in the centroid of that municipality polygon: that will be about 5 kilometers northeast of Downtown Long Beach. Both the administrative boundary and the place node are valid representations of different things: one is the legal municipal borders (which exclude the suburb of Signal Hill, for example), while the other is the location of the "centre" of the place.

Almost any town built near a large body of water will have this problem if there is no node to represent the centre. While the problem is less obvious with small features such as villages, it is still advisable to map these with a node at their commercial or cultural centre. Not only does this make it possible to render the name properly and to provide routing to the correct location, it also represents the named place correctly in the database.

[jeisenbe]

Or consider the municipality of New York. Since this is now mapped as an boundary=administrative relation with admin_level=5, it get's a purple label at ST_PointOnSurface (near the "center" of the polygon), as well as a larger black label near the city hall in Lower Manhattan where the place=city node is located:

Clearly the node is needed to represent the actual center of the city, which is not located in Cypress Hills Cemeter in suburban Queens, but in downtown Manahattan.

(This is one of the cases where rendering the name of the admin_level=5 feature is not very helpful, but New York City is the only municipality in the USA which is mapped in this way)

[dawansv]

@jeisenbe Thank you what you are saying makes a lot of sense. The examples are really good and I would encourage you to add them to the wiki where place names are discussed.

Right now, for Mali, I am getting some help from a more experiece mapper that is reintroducing nodes to the villages so that the rendering will be back to normal.

Right now we have the place=village tag on both aera and node. I am wondering if that's OK or if we should only have it on nodes; for the area, the boudary is not administrative (no such thing for villages there), so not sure whether we should use type=boundary or not. I will look in the wiki a bit more and also look for more examples.

[gravitystorm]

since they used to render area place names, but now it seems they also don't. Does anyone know if their behaviour was changed to be consistent with osm-carto, or am I missing something, or possibly going crazy?

The Transport and OpenCycleMap layers both used to render place names from place polygons, but this was dropped a few years ago. The main difficulties were the surprisingly large number of places where the name on the node didn't match the name on the polygon (generally different variations e.g. Saint vs St, but often where place labels were added to admin boundaries which had a different name to the town) but also the much larger number of places where the place categorization didn't match (e.g. place=village on the node, place=city on the polygon). This led to many terrible results, particularly in the USA, where tiny villages were having their names rendered in big fonts on my maps, without any other maps showing that problem.

Unfortunately there's only so long that I could swim against the tide on this topic, so I eventually dropped the polygon place labels and now just use place nodes.