place=square label display should not depend on way_area without visual feedback on the geometry

[imagico]

As said in the subject - polygons tagged place=square are rendered depending on way_area - see

openstreetmap-carto/roads.mss

Lines 3307 to 3309 in e7de1cd

	#roads-area-text-name {
	[way_pixels > 3000],
	[zoom >= 17] {

without there being any visual feedback on the geometry.

Introduced in #2673, see also #2673 (comment), #2700 (comment).

Side note: The whole rendering of place=square with nodes in placenames-small and polygons in roads-area-text-name is confusing and difficult to maintain.

[kocio-pl]

The size is reflected now and it one of the important features of the geometry.

[imagico]

Please see the links provided for past discussion. way_area is not a feature of the geometry, it is a quantity derived from the geometry. Completely different geometries can result in the same way_area value. Making rendering decisions based on way_area without providing visual feedback on the polygon geometry incentivizes free form polygon drawing for the purpose of manually tagging way_area as a means of manually drawing labels. This is something we should not support.

[kocio-pl]

it is a quantity derived from the geometry.

So is the center (centroid) of the objects (the rule "completely different geometries can result in the same [centroid]" applies here as well). Unfortunately, this is much more subjective than size - there is exactly one size of object, but there can be many different centroids for exactly one object.

This is something we should not support.

We do this for forests IIRC and I think that makes sense.

[imagico]

I am sorry but i completely fail to see your point beyond whataboutism/deflection.

[kocio-pl]

OK, let me rephrase then - I think that showing more objective property has more justification than more subjective ones.

Also I consider using words "whataboutism", "deflection" and so on is judgemental and conflicts with the code of conduct. If you don't think so, try applying this or similar words to your way of reasoning and check if it would be OK for you. For me it's definitely not.

[imagico]

I still fail to see your point. That you disagree with the principle i outlined is obvious - after all you made the change causing this issue as well as other ones coming with the same problem (most notably the bays and straits). But all of these changes were made without consensus. Now you will need to provide arguments and reasoning to convince others that this is a good idea. And as much as i try to i fail to see convincing arguments.

And i am glad any time to get critical feedback if my comments are perceived to be deflecting/off-topic/non-constructive.

[kocio-pl]

When in doubt, please use the same words you usually use for your own actions - "consistency" comes to my mind (I hope this can help you understand my reasoning here?), but I prefer avoiding any judgmental words.

[jeisenbe]

We do this for forests

That is incorrect. The problem here is that place=square does not have an outline or area fill rendering. The whole area of a landuse=forest or natural=wood polygon is rendered in dark green.

In the past we rendered tourism=attraction features based on way area without showing an outline or fill. This sometimes led to very large labels in bright pink at mid zoom level, but the problem was fixed by PR #3603 "Reducing priority of tourism=attraction and rendering from z17".

We can fix this problem with place=square by rendering it in placenames-small only, like other small places (neighborhoods, isolated dwellings, farms, localities) - this will make more sense and it will make the style easier to adapt.

Of course mappers will continue to be able to tag a multipolygon or closed way with highway=pedestrian + area=yes if it is a pedestrian square, and this will be rendered with a fill color and a label which is based on the size and shape of the area. We also do this for leisure=park (which might be the correct tagging for some squares which are not pedestrian areas), so there isn't a need to provide a separate area-based rendering for a place=square.

[jeisenbe]

I am sorry but i completely fail to see your point beyond whataboutism/deflection.

Please assume goodwill. We should not speculate that another contributor is using "deflection" or "whataboutism" when it is possible that they are simply confused or do not understand the issue.

[jeisenbe]

I think that showing more objective property has more justification than more subjective ones.

I agree.

When we show a text label only for a feature, we should not adjust the size based on the geometry of the database object, because there is not an objective rendering of the objects' shape and size.

This means that if a new mapper accidentally drags one of the nodes 100 meters, or accidentally selects the square and "alt-ctrl" to enlarge it, the label can change size without there being anything rendered to explain why it is that size.

Examples (created locally):
z15 with accidentally enlarged place=square area

z15 correct data

z18 accidentally duplicated/enlarged square

• 2 labels but not indication of the geometry of the second square feature

z18 correct data

Fortunately the #roads-area-text-name layer is only rendered from z15 and the text size does not change, so it's not possible to make arbitrarily huge labels this way, unlike with the old tourism=attraction rendering (which worked until z10), but it's clear that the label at z15 is much too big, yet there is no shape to show what has gone wrong: it looks like a rendering bug, not a data problem.

[jeisenbe]

@imagico are you suggesting removing the rendering of areas with place=square only, or rendering them the same as nodes: at z17 and higher only?

[imagico]

This issue is about removing the way_area based rendering rules. Since #2673 was merged without consensus newly evaluating the use of the tag and overlap with other tags might be in order. Considering rendering it with feedback on the geometry might also be worthwhile.

What should definitely be changed is rendering of nodes and polygons in different layers with very different priorities - that is highly confusing both for mappers and style developers.

Regarding starting zoom level - this needs to be looked at in relation to other features - junction names are currently rendered starting at z15 for example but with a lower priority than place=square nodes. amenity-points with all the POI symbols is in priority between the place=square nodes and the place=square polygons meaning that symbols turning up at z16/17 will displace labels of large place=square polygons starting already at z15 while labels of place=square nodes will displace POI symbols already visible at z16 when they show up at z17.

[kocio-pl]

We can fix this problem with place=square by rendering it in placenames-small only, like other small places (neighborhoods, isolated dwellings, farms, localities) - this will make more sense and it will make the style easier to adapt.

Sure, we can. This is a small scale feature (definitely smaller than neighborhoods for example), so I see no general issue with doing so.

For consistency, I would check how the rendering of pedestrian areas work, since this should be no difference if the square is purely pedestrian area or some more complex object.

This means that if a new mapper accidentally drags one of the nodes 100 meters, or accidentally selects the square and "alt-ctrl" to enlarge it, the label can change size without there being anything rendered to explain why it is that size.

This is exactly what raises suspicion and what leads to checking. And we have really efficient object inspection tool I usually use for checking suspicious things and it works good most of the time (excluding some timeouts, which are too frequent recently). I'm foreign to iD, but JOSM is showing it too (like many other details). In my opinion this style shouldn't be a replacement for all the tools we have in OSM.

[jeisenbe]

OK, I made a PR to fix this, but in testing it I've realized that the tag place=square is not used in any consistent way, probably since the meaning of "square", "plaza", "place", "plaça" and similar terms can vary depending on culture and region.

The PR would have changed the initial zoom level to z17 for areas of any size, as with nodes previously, and changes rendering layer to amenity-points instead of placenames-small for proper priority, with a halo and text like other small placenames (e.g. locality, neighborhood). I made a large number of test images before realizing I couldn't find a good place to test it.

Rarely it is used as described on the wiki page to map a large public market square from pre-modern times, including the streets and sharing nodes with surrounding buildings, or sometimes as a node in the same sort of place. These were hard to find even in old European towns, since highway=pedestrian is much more commonly used for this and the text label looks quite similar (Or identical with the current rendering). Some also have amenity=marketplace (the usually original purpose of a square in Europe).

But often it is added to a highway=pedestrian or leisure=park feature, or duplicates an existing pedestrian or park area with a slightly different geometry.

Often it is used the same as highway=pedestrian areas to specifically mark open pedestrian spaces, though in all cases the pedestrian area tag is more common.

In other countries it is used for small areas between buildings, in schoolyards, in military areas, or inside of parks which are mainly hardscaped. The more common method for this is highway=pedestrian though many are untagged.

Examples from PR tests:

Singapore
"Performing Stage" place=square area; shape not rendered since no other tags
https://www.openstreetmap.org/#map=18/1.43006/103.79700

Brasilia, Brazil

• This is one of the good examples, though the label only shows at z18 and z19
  Plaça Tres Poderes (by supreme court) - missing highway=pedestrian area

Brasilia - Plaça Xandrez

• tiny "plaza" in a park next to a school

Brasilia - Plaça Povo

• small rectangle between streets and buildings in government area

Bremenhaven, Germany

• Marketplace and place=square with different names oddly. The square object is tiny, just a few meters, but this seems a mistake? Not sure if this area should be the same as the amenity=marketplace?

Bremenhaven, Germany

• Flotenkiel place=square + leisure=common, open area between streets (the streets are not included in the area)

[jeisenbe]

Singapore, again:

• Most of the place=square in this English-speaking country are open areas probably used for parading or marching, inside of military bases, for example:

Kaliningrad, Russia:

A place=square rectangle between buildings in a rural area, contains dirt and trees?

Small place=square area in a forest next to a military area. Not sure what this is, but it's not a square:

Kalininplatz square:

• Includes 3 different blocks (mapped with landuse=grass and other things), plus a nearby intersection/junction and some surrounding streets. I don't know how you could verify this geometry as correct or not.

Kaliningrad place=square between a pitch and school buildings in a schoolyard:

There are 3 or 4 examples just like this in Kaliningrad, where there are 1 or 2 leisure=park areas with a name, and then a larger place=square which includes them and streets:

Groningen, Netherlands:

• Just 6 place=square in this province

The big market in the center of the city, also tagged as highway=pedestrian and mapped as a multipolygon:
https://www.openstreetmap.org/#map=18/53.218697/6.5679084

Square in a school yard in Groningen province:
https://www.openstreetmap.org/#map=18/53.1657724/6.7642558

https://www.openstreetmap.org/#map=18/53.385714/6.2606129

• Small square in a village near the sea, with name "markt" (Market?), and appears to have stalls or buildings on it, but it's not surrounded by buildings. Not sure if this is an amenity=marketplace or a disused one?

Clearly, most of the features with place=square can be (or already are) mapped with highway=pedestrian or leisure=park or amenity=marketplace, and the rest are a mix of mistagged features or vaguely drawn areas.

Only a minority fit the traditional definition of a town square, and all of these could be mapped with highway=pedestrian areas or as marketplaces or parks.

[jeisenbe]

I stopped making images, but here is my analysis of the use of place=square in 8 places in North America, South America, Europe and Asia:

Luxembourg:

17 place=square (compare to 210 highway=pedestrian areas, 75 with names)

12 named, 5 unnamed
6 with highway=pedestrian (1 with living_street)
No other combinations.
Unnamed: 3 with highway=pedestrian
1 area in front of church, with a restaurant and parking lot on the sides and primary highway behind,15x20m - way 526759337
1 area between a garden and 2 buildings and near a church, but includes a shed and building - way 762707740
1 Area with 3 trees and statue and a bus platform are, next to 2 secondary roads, a parking lot, and a barn. Does not include roads. way 762707728
Named:
1 node by 2 buildings and a street, across street from parking lots with same name “Place des martyrs” node 5012885481
1 area Vali's Plaz - does not quite share nodes with buildings but is close, includes street, parking lot, benches, trees. way 548139832
1 node “Place victor Hugo” in a bus station + parking lot area. node 6831172797
1 area “Parvis de la Cathédrale” (Domhof - de) beside cathedral and library, with a retaining wall on the other side, above an untagged area with trees, fountain, and statue. way 145357502
1 area “Europaplaz” - randomly shaped quadrateral which includes part of streets but not all, does not touch buildings. way 544984317

Groningen:

6 areas with place=square
1 with name “markt” in small village area - probably should be amenity=market_place? Not a square
1 next to a school, no name - schoolyard
4 combined with highway=pedestrian areas in central Groningen (market squares)

Kaliningrad:

3 squares bisected by roads, which are also mapped as 1 or 2 separate leisure=park areas
1 big “square” which is several blocks in the center of town, but also includes nearby streets and intersections
1 schoolyard between a pitch and school building
1 open area in a forest near a military installation
1 large rectangular area in the middle of rural buildings, with trees growing in it.

Singapore:

1 “Performing stage” (name) in a park between playgrounds
1 “Event area” (name) between 2 apartment buildings
1 named “Open Square” in front of a retail building - way 440617883
1 Square in chinatown in front of a temple, “Kreta Ayer Square” mapped as a node
1 node named “Safari square” in front of Zoo / River Safari
1 highway=pedestrian area
15 without a name, 13 with no other tags

• 1 has surface=paving_stones and is located between to pitches in a schoolyard
• 1 small circle in front of mall, sunken: way 474275568 (level=-1)
• 11 open flat areas between buildings in military bases, e.g. way 733833400, 1.3708328, 103.7164517

Brasilia:

16 with name (always including “plaça”, “plaçinha” or “parque” - plaza, little plaza, or park (2))
(21 unnamed)
4 with leisure=park on same object.
2 with landuse=grass
4 with landuse=recreation ground
1 with footway=island
Unnamed Examples:

• 10 meter diameter circle in the median of a street with surface=concrete (way 158938585), no name
• 10x30 meter oval around a building, near another 10m circular place=square and a larger circular leisure=park (way 629622505)
• 10x20m rectangle between two residential buildings
• 2 small areas (20x20 and 10x20m) between buildings, with benches, in a small university (way 551130214)
• 1 directly adjacent to leisure=park on one side and landuse=grass on the other side (way 640523365)
• One over a trunk road, surrounded by primary and primary link on 3 sides and footways on all sides.
  Named examples:
  Some next to a school, some small paved areas by a building, a large area that crosses several streets and contain library and buildings (Parque Complexo Cultural da República), another which could also be tagged highway=pedestrian, a tiny one in a park, etc. All of these have the word Plaza or Park in their name at least.
• way 552454097 - Irregular shape “Praça da Administração Regional de Brazlândia” between a school, public administrative building, divided street, a courthouse.
• 10x20m oval inside a street, “Praça Central”.
• node 6556035934, Praça do Trabalhador, also mapped as a highway=pedestrian area
• way 685024593 - 10x10 meter area inside of a leisure=park
• way 320262221 - 20x40 meter plaza by a government building and parking lot.

Brussels:

86 squares (compare to 169 highway=pedestrian areas, 113 named)
5 unnamed with no other tags (e.g.: 2 small areas at corners of buildings on university campus, 1 tiny 10m x 5m area along a cycleway, 1 unnamed triangle between 3 residential streets, 1 schoolyard)
14 with highway=pedestrian areas
1 with area:highway=residential
1 with power=substation and building! way 253872698
14 combined with landuse=residential (!)
(1 around a circle containing leisure=garden and a church building, 1 around an oval tagged leisure=park, 1 streetcorner in front of a church)
50 others: a named junction (way 126504782), a square mapped around another place=square + landuse=residential (way 53851356) which is around a leisure=park, several traditional squares which are missing highway=pedestrian mapping.

San Francisco, California:

19 place=square (By comparison, there are 83 highway=pedestrian closed ways in San Francisco, 25 with names.)
8 place=square with highway=pedestrian
1 with leisure=park
1 with barrier=kerb surrounding, named “Bush Plaza”, contains 2 large buildings inside. (Should be multipolygon with highway=pedestrian)
3 with no other tags, no name:

• 1 includes parking areas, pedestrian area, and picnic spot in front of a boathouse / bike rental shop inside of Golden Gate park: way 673500611
• 2 rectangles between the Chevron office building, Uber office building, and First Market Tower office building (market street and stevenson street on the other 2 sides). These are unnamed hardscaped plazas, created when the USA though th.at urban areas needed more “open space” between tall buildings.
  Other named squares:
• node 6823989238 “margaret douglas plaza” in front of Human Services Agency of San Francisco, irregular 20x30m shape not mapped directly, but includes a highway=service and 2 paths and a private playground
• 5th street plaza, between mission creek (a tidal channel), berry Street, and 2 apartment buildings - this is the end of 5th street and is a mainly hardscaped park with trees and benches, and probably should have leisure=park or highway=pedestrian.
• Piazza Angelo, inside of Trinity Apartments - contains mostly landuse=grass but other areas not tagged - way 663700535
• Foundry Square - contains 4 highway=pedestrian areas on each corner, plus the cross-streets between them, in old part of town - not clear how this is different than a named highway=junction - way 616245697
• 560 Mission Street Plaza - area between 2 streets and 2 buildings - has a path through it - way 148288767
• A.P. Giannini Plaza - 10m x 50m area with a highway=footway in the middle which connects to a much large highway=pedestrian area to the west - probably this is a highway=pedestrian actually. way 151183776

Buenos Aires, Argentina:

8 place=square, all areas, no other tags. (In contrast, there are 43 highway=pedestrian closed ways)

• 6 inside of a larger park, around a flagpole: way 718510144, around a monument (way 718524960), middle of a park (way 678948285), around an artwork (way 733662882), hardscaped edge of a park with artworks ( way 718505832),
• 1 large area between a building and a park (the park is named “Plaza Libres del Sud” oddlly!)
• 1 small 10x10m wedge next to landsue=grass way 595823324

So Brussels was the only city where more than half of place=square features were used for a town square, but even there the mapping is inconsistent.

[jeisenbe]

Does anyone want to comment on the analysis above? I'm trying to decide if we should continue to render place=square, even though it is not well defined.

[Adamant36]

In my own experience most of the time place=square is either used alone in places that are not squares be co-tagged with things like leisure=park where the object "might" be a square if your stretching the definition, but it's actually more a park. The few examples you provided from the bay area are ones that comes to do mind. I think the only place where it actually works are traditional squares in European countries, but there aren't many of them and it's not how the tag is being used anyway. So, I'd go with removal of place=square rendering.

[polarbearing]

jeisenbe wrote:

if a new mapper accidentally drags one of the nodes 100 meters, or accidentally selects the square and "alt-ctrl" to enlarge it

It surprises me that we adjust the rendering style to the accidental mistakes a new mapper might make. I have no idea what "alt-ctrl enlarge" action you refer to.

2 labels but not indication of the geometry of the second square feature

one feature - one OSM object would solve the problem. Tagging issue that can be fixed.

old European towns ... highway=pedestrian is much more common ... duplicates an existing pedestrian or park area with a slightly different geometry

The typical square I have in mind is a composition of roads, pedestrian areas and park elements. None of the individual elements is "the square".

In other countries it is used for small areas between buildings, in schoolyards, in military areas

If things are mistagged contrary the definition, the tagging should be corrected, not the style.

Marketplace and place=square with different names oddly

Nothing odd, one is the formal name of the square, the marketplace is named after the weekly event that is held on the square.

Square in a school yard

leisure=schoolyard was proposed for that.

most of the features with place=square can be (or already are) mapped with highway=pedestrian or leisure=park or amenity=marketplace,

No, as said above these might be elements of the square, but often not the square itself.

Adamant36 wrote:

So, I'd go with removal of place=square rendering

Strongly against. Improvements in size-dependent rendering, yes of course.

[imagico]

I would like to keep the discussion on the specific matter of this issue separate from the evaluation of label rendering of place=square in general. This issue would still require fixing even if place=square was used perfectly consistently according to a universally accepted verifiable definition.

I opened a new issue for re-evaluating the label rendering for place=square in general: #4084.

[maro-21]

It would be good if the name of a square won't render on a building.
https://www.openstreetmap.org/way/447598367
Plac św. Krzysztofa here is a place=square around the church.