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

Open
joakimfors opened this issue Aug 7, 2013 · 54 comments

Comments

Projects
None yet
@joakimfors
Copy link

commented Aug 7, 2013

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

This comment has been minimized.

Copy link
Collaborator

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

This comment has been minimized.

Copy link

commented Mar 20, 2014

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

@chrisfleming

This comment has been minimized.

Copy link
Contributor

commented Mar 20, 2014

@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

This comment has been minimized.

Copy link

commented Mar 23, 2014

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

@matthijsmelissen

This comment has been minimized.

Copy link
Collaborator

commented Apr 14, 2014

@pnorman

This comment has been minimized.

Copy link
Collaborator

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

This comment has been minimized.

Copy link
Author

commented May 15, 2014

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

This comment has been minimized.

Copy link
Collaborator

commented May 15, 2014

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

@pnorman

This comment has been minimized.

Copy link
Collaborator

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

This comment has been minimized.

Copy link

commented May 15, 2014

2014-05-15 12:05 GMT+02:00 Paul Norman notifications@github.com:

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 comment has been minimized.

Copy link
Collaborator

commented May 15, 2014

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

This comment has been minimized.

Copy link

commented May 15, 2014

2014-05-15 13:33 GMT+02:00 math1985 notifications@github.com:

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

This comment has been minimized.

Copy link
Collaborator

commented May 15, 2014

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

This comment has been minimized.

Copy link

commented May 15, 2014

2014-05-15 18:33 GMT+02:00 math1985 notifications@github.com:

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

Get city and town names for both place points and place polygons
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

@pnorman

This comment has been minimized.

Copy link
Collaborator

commented May 1, 2017

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

This comment has been minimized.

Copy link

commented Jun 10, 2017

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

This comment has been minimized.

Copy link

commented Jun 12, 2017

@jojo4u

This comment has been minimized.

Copy link

commented Jun 18, 2017

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 comment has been minimized.

Copy link

commented Aug 22, 2017

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

This comment has been minimized.

Copy link

commented Sep 1, 2017

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

This comment has been minimized.

Copy link

commented Sep 1, 2017

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

This comment has been minimized.

Copy link
Contributor

commented Sep 1, 2017

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

This comment has been minimized.

Copy link
Collaborator

commented Sep 1, 2017

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 .

@kocio-pl kocio-pl self-assigned this Sep 1, 2017

@AragonChristopherR17Z

This comment has been minimized.

Copy link

commented Sep 5, 2017

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

This comment has been minimized.

Copy link
Contributor

commented Sep 5, 2017

@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

This comment has been minimized.

Copy link
Contributor

commented Sep 5, 2017

We do really need to get this sorted, I did propose some kind of improvemnt 3 years ago: #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

This comment has been minimized.

Copy link

commented Sep 6, 2017

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

This comment has been minimized.

Copy link
Collaborator

commented Sep 6, 2017

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

This comment has been minimized.

Copy link

commented Sep 9, 2017

See my remark on the pull:

#2816 (comment)

@Komzpa

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link

commented Jan 8, 2019

@Pikse

This comment has been minimized.

Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.