Skip to content
New issue

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

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Render place names on areas the same way as on nodes #103

Closed
joakimfors opened this issue Aug 7, 2013 · 67 comments
Closed

Render place names on areas the same way as on nodes #103

joakimfors opened this issue Aug 7, 2013 · 67 comments
Labels
bug declined new features Requests to render new features placenames

Comments

@joakimfors
Copy link

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
Copy link
Collaborator

pnorman commented Feb 21, 2014

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
Copy link

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

@chrisfleming
Copy link
Contributor

@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
Copy link

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

@matthijsmelissen
Copy link
Collaborator

@pnorman
Copy link
Collaborator

pnorman commented May 15, 2014

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
Copy link
Author

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
Copy link
Collaborator

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

@pnorman
Copy link
Collaborator

pnorman commented May 15, 2014

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
Copy link

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
Copy link
Collaborator

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
Copy link

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
Copy link
Collaborator

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
Copy link

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

pnorman added a commit to pnorman/openstreetmap-carto that referenced this issue May 16, 2014
This is part of gravitystorm#103, but only fixes it for place=city/town

The SQL is moderately complex and difficult to document in the .mml file so it's worth documenting here

```sql
(SELECT way,place,name,capital,population
  FROM
    (SELECT
        way,place,name,NULL AS capital,way_area, -- The polygon table doesn't have the capital information with the default style
        CASE WHEN population~E'^\\d{1,9}$' THEN population::integer ELSE NULL END AS population
          -- We need to filter out population values that might cause exceptions. This is a fairly rigerous filtering as it will remove population=1,000
      FROM planet_osm_polygon
    UNION ALL -- Join the two together
    SELECT
        way,place,name,capital,NULL AS way_area, -- Points don't have an area
        CASE WHEN population~E'^\\d{1,9}$' AND length(population)<10 THEN population::integer ELSE NULL END AS population -- as above
      FROM planet_osm_point) AS p
  WHERE place IN ('city','town') -- This condition is brought inside by the query optimizer
  ORDER BY
    CASE place WHEN 'city' THEN 0 ELSE 10 END, -- We don't actually need this at moment with the current MSS
    CASE capital WHEN 'yes' THEN 0 ELSE 10 END, -- Nor this
    way_area DESC NULLS LAST, -- Put physically larger first
    population DESC NULLS LAST -- For points (no area) put larger population first
) AS placenames_medium
```

The ordering merits further discussion

We're currently not considering area or population for ordering, so anything is an improvement here. It's hard to say if area,population or population,area is better without trying one first.
This was referenced May 16, 2014
@Komzpa
Copy link

Komzpa commented Jan 8, 2019

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

#2939

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

@vbertola
Copy link

vbertola commented Jan 8, 2019

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
Copy link

Komzpa commented Jan 8, 2019

@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
Copy link

dieterdreist commented Jan 8, 2019 via email

@Pikse
Copy link

Pikse commented Jan 8, 2019

@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
Copy link
Collaborator

jeisenbe commented Sep 7, 2019

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
Copy link

Hjart commented Sep 7, 2019

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

@dawansv
Copy link

dawansv commented Jun 11, 2020

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
Copy link

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
Copy link
Collaborator

jeisenbe commented Jun 18, 2020

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: #103 (comment)) _

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
Copy link
Collaborator

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.

Screen Shot 2020-06-18 at 10 43 09

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
Copy link
Collaborator

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:

Screen Shot 2020-06-18 at 10 51 33

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
Copy link

dawansv commented Jun 18, 2020

@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
Copy link
Owner

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.

@nchristensen
Copy link

nchristensen commented Jan 18, 2021

In my locality, we have named subdivisions with legally defined boundaries (decided at the time of annexation). The land uses in these subdivisions is often mixed so a single landuse=residential tag is wrong. At the same time, these areas do not define separate administrative units. This leaves place=neighbourhood as the best tag for the polygon in my view. I was surprised to find this is not rendered.

@vincentvd1
Copy link

I came across the same problem and the solution I used was already mentioned in the beginning. Place a way with place=* and name=* in a relation with a node that has the same place and name tags. You can use this relation technique if the center where the node should be place is not the same as the geometric center of the way. If you specify these two use cases in the wiki for place, it should be fine.

Take a look at the following examples

  1. Here I used a node to place the node of the city center at a different location.
  2. Here, the geometric center is fine for the label so I didn't make a relation, just a way with the propor information. It is a pitty that it does not get rendered but this is correct tagging.
  3. This example clearly shows the implications the choice not to render place names on a way has. I wanted the label to get rendered because it is a well known name. The geometric center is fine but I had to use relations to get it rendered. This should not be needed because it creates unecessary complexity.

Conclusion, there are already perfect solution available to get around this.

@twilight1794
Copy link

In many mexican cities neighbourhoods (colonias and fraccionamientos) have clear limits inside the city, but now we have to define them as nodes instead of areas. It would be better if place names of areas are rendered.

@marioxcc
Copy link

marioxcc commented Aug 8, 2023

Render places mapped as areas. As explained above, there are many cases where the areas are well-defined. Leave it to mappers to determine what those places are.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug declined new features Requests to render new features placenames
Projects
None yet