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

Add rendering for place=quarter #798

Closed
matthijsmelissen opened this issue Aug 1, 2014 · 26 comments
Closed

Add rendering for place=quarter #798

matthijsmelissen opened this issue Aug 1, 2014 · 26 comments

Comments

@matthijsmelissen
Copy link
Collaborator

A quarter is an area of a city smaller than place=suburb, but larger than place=neighbourhood. A quarter may have an administrative boundary, or only a node marking its nominal centre.

The proposal for this tag was approved in 2012-01.

It would be nice if this tag could be rendered.

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

@matkoniecz
Copy link
Contributor

It is used only 585 times - see http://taginfo.openstreetmap.org/tags/place=quarter

@matthijsmelissen matthijsmelissen added this to the New features milestone Aug 18, 2014
matthijsmelissen added a commit to matthijsmelissen/openstreetmap-carto that referenced this issue Jan 21, 2015
* Don't render place=town on z16 and higher, and place=suburb and place=village
  on z17 and higher.
* Render place=hamlet, place=locality, place=neighbourhood, place=quarter,
  place=isolated_dwelling, and place=farm from z15 rather than from z14
  (resolves gravitystorm#948).
* Render place=town black rather than gray.
* Make font sizes more consistent by increasing font size for place=town on z12
  and z13, for place=suburb on z16, and for place=village on z14 and z16
  (resolves gravitystorm#734, resolves gravitystorm#1204).
* Add rendering for place=block and place=city_block (resolves gravitystorm#107).
* Add rendering for place=quarter (like place=neighbourhood) and place=borough
  (like place=suburb, resolves gravitystorm#798).
* Treat capital=4 like capital=yes (resolves gravitystorm#522).
* Make text-wrap consistent.
@matthijsmelissen
Copy link
Collaborator Author

Rejected per #1247 (comment).

@michaelzed
Copy link

Was place=quarter rejected for the same reasons as place=borough, i.e. that the concept represents an administrative boundary and not a kind of geographic place? Does this constitute a veto over the wiki’s acceptance of place=quarter? Is it now advisable to use place=suburb and place=neighbourhood, and avoid using place=quarter?

Not arguing, just trying to understand what rejection means for this tag, and how OpenStreetMap editors should proceed.

@michaelzed
Copy link

By the way, place=quarter is now used 1,048 times. Its occurrence has increased 80% in six months.

@dieterdreist
Copy link

dieterdreist commented Feb 5, 2015 via email

@gravitystorm
Copy link
Owner

Was place=quarter rejected for the same reasons as place=borough

They have both been rejected since I don't want to see more place values rendered at this time.

Personally, I believe there is more value in using a fixed list of values, rather than adding more granularity to an already impossible-to-tell-apart list.

Consider this: should we add 5 more tracktypes? Or how about 2 more smoothness values? Why are there a mere 19 values of the highway tag, when there are surely more than 40 different types of road in the whole world?

Does this constitute a veto over the wiki’s acceptance of place=quarter?

We can choose in this project what we want to render, and are certainly not forced to render all tags documented on the wiki. So the acceptance of a tag on the wiki is not a requirement to render.

Secondly, it's false to think that by choosing not to render something we have any kind of "veto". That presupposes that we are somehow involved in a voting system for tags, which is definitely not true.

Is it now advisable to use place=suburb and place=neighbourhood, and avoid using place=quarter?

I would always advise using existing tags, especially in continuous-scale situations where nobody benefits from more values. But whether we render it or not I'd still give the same advice, so nothing has changed there.

@dieterdreist
Copy link

2015-02-06 15:35 GMT+01:00 Andy Allan notifications@github.com:

Personally, I believe there is more value in using a fixed list of values,
rather than adding more granularity to an already impossible-to-tell-apart
list.

I don't share you're impression that place values for settlements and parts
of them are "already impossible to tell apart", IMHO they are rather clear
and well distinguishable:

city, town, village, hamlet, isolated_dwelling. that's all for settlements
suburb, neighbourhood. that's all for parts of settlements

These are neither many nor is there overlap, typically.

@michaelzed
Copy link

Place=quarter is an existing tag, Gravitystorm, for two years now. You seem to be advising OSM mappers to ignore it, because they made a mistake in adopting it, and tag for the renderer instead. Of course you’re entitled, but it doesn’t seem like a productive way to build the renderer for OSM.

@dieterdreist
Copy link

2015-02-06 15:35 GMT+01:00 Andy Allan notifications@github.com:

Secondly, it's false to think that by choosing not to render something we
have any kind of "veto". That presupposes that we are somehow involved in a
voting system for tags, which is definitely not true.

osm-carto is the main map. It is very important what it does display and
it is highly influencing people's choice which tags to use. If you use a
highway tag that is not displayed on osm-carto, the road will be missing
and hence this is not an option.

The same goes for settlements and parts of them, if you want to have
something as important as a settlement or a part of it displayed on the
map, you'll have no other option than choose a tag that is rendered (and if
you don't do it, someone else will do it).

@kocio-pl
Copy link
Collaborator

@gravitystorm: I second what @dieterdreist said - osm-carto is the main map and you are the leading person here, so it is "kind of veto" (not the direct one, but still) you have in your hands.

@centreejp
Copy link

As a Japanese OSM mapper, I also hope to add rendering place=quarter.
There are many places smaller than suburb, but bigger than neighborhood in Japan.
place=hamlet would be able to use instead of quarter, but especially in city/town area, these places are very near(not isolated), so I think using place=hamlet tag is not suitable.
Additionally, in OSM Talk-ja, we have discussed how to importing place name data that released by government for a while.(OSM wiki: http://wiki.openstreetmap.org/wiki/JA:MLIT_ISJ ;sorry, only Japanese page...) so I believe that place=quarter rendering would be encouraged to increase to add place name data near aroud Japan.

@1ec5
Copy link

1ec5 commented Mar 15, 2015

@ligfietser
Copy link

Please reopen this issue, quarter fills in the gap between suburb and neigbourhood in the Netherlands. At the moment there is no other tag to label city districts (wijken) in the Netherlands, people are now misusing place=suburb or landuse=residential for this simply because quarter isn't rendered. Place=neigbourhood (buurten) is for smaller subsections of quarters (wijken).

@dieterdreist
Copy link

dieterdreist commented Apr 28, 2017 via email

@jojo4u
Copy link

jojo4u commented Apr 30, 2017

I drafted a hierarchy of urban place subdivisions. Suburb would only be used in cities. Towns would use the smaller place=quarter: https://wiki.openstreetmap.org/wiki/User:Jojo4u/place_hierarchy
This draft was presented in german forum but did not gain any response :/

@nebulon42
Copy link
Contributor

Tag usage of quarter has increased significantly and there is evidence of tagging for the renderer. I'm reopening this so that the renewed discussion does not need to happen on a closed issue. This does not mean that this is ready to be rendered. Work that has to be done is to see if the scheme is consistent and how it would fit into the already rendered values.

Personally I think that we need to avoid rendering values that cover small areas and do not have much significance like city_block and maybe also neighborhood.

@ArcticGnome
Copy link

ArcticGnome commented Dec 14, 2017

The text for neighbourhood names is too small. It's smaller than features inside the neighbourhood like parks, and it disappears if you zoom out to look at two neighbourhoods at once. I see three possible solutions:

  1. Increase the font size for neighbourhood nodes.
  2. Render quarters nodes in a font size in-between the size of neighbourhoods and suburbs.
  3. Render the name of closed-way-neighbourhoods in font sizes that scale with the size of the area (like we already do for landuse).

@kocio-pl
Copy link
Collaborator

I would probably take 2.

The usage is high enough for me (4 712) and growing constantly:
taghistory 12

@IgorEliezer
Copy link

IgorEliezer commented May 4, 2018

I'm mapping a municipality consisting of a 23K town and 2 villages. Based on the wiki, I would use the following scheme:

  • city: suburb > quarter > neighborhood
  • town: quarter > neighborhood
  • village: neighborhood

But since quarter is not rendered, I used suburb for the town's subdivisions and neighborhood for village's. The village is perfect but the town is too eyesore with about 15 suburb labels popping out at z14, and sometimes the style picks the smaller suburbs over the bigger ones to render, even though all the nodes have population tag and are part of a type=boundary with role=label.

I propose the following options:

  1. render the most populated suburbs first, but I'm afraid the population tag on urban subdivisions is not widespread enough.
  2. render the biggest suburbs first, but this would require the node be part of type=boundary. Not only would it be too overkill but also it might be misleading as the biggest suburbs are sometimes the least populated (houses are quite spread, low density etc).
  3. render quarter, since it's documented on the wiki and iD supports it.

But if I had to stick to official data from the local townhall, I'd pick option 1 since we don't have an official suburb hierarchy -- there's no such a thing as a 'quarter' or 'neighborhood': no matter the place has half a block or 30 blocks they all are called suburbs -- and the inhabitants tend to use the "major suburbs" as their reference for their "minor suburbs".

@kocio-pl
Copy link
Collaborator

kocio-pl commented May 4, 2018

Are you willing to prepare the code?

@IgorEliezer
Copy link

IgorEliezer commented May 4, 2018

Are you willing to prepare the code?

I'm sorry if I caused any problem, sounded demanding or tried to rush developers. Please don't get me wrong, but your reply seems I'm required to code to be able to comment (my 1st comment on this git btw). I saw you commented "The usage is high enough for me (4 712) and growing constantly" and the discussion was reopened one year ago (as said here), then I thought it would be worthy commenting. :)

@kocio-pl
Copy link
Collaborator

kocio-pl commented May 5, 2018

Oh, that might really sound as a demand, sorry for that! I just want to ask if you're interested in coding it. because we have not enough active programmers and just asking helped some people to try it. I feel this is one of a big missing blocks (next to place=square, which was eventually added lately), so I would be happy if you will give it a shot.

@BertMule

This comment was marked as off-topic.

@dieterdreist
Copy link

what are you referring to? place=quarter is rendered for years now

@sommerluk
Copy link
Collaborator

@BertMule

As @dieterdreist said, place=quarter is rendered for years now.

Complaining about a tag not rendered on a feature request that has been implemented since 2018 (!) is pointless, therefore qualifying your post as spam is appropriate. We try to keep discussions on-topic on this issue tracker.

You seem to express that you do not like some general parts of the functioning of OpenStreetMap. Let me say that this particular project is about map style design. It is not about “Remove the tag (and replace by another).” neither about “Better not create it at all”. Here, we neither “create” tags nor do we “remove” them from the OSM database. Therefore, this is off-topic.

Please refrain in the future from discussing general views about OSM here. This issue tracker is only for map style design related discussions.

Repository owner locked as off-topic and limited conversation to collaborators Oct 22, 2022
@sommerluk
Copy link
Collaborator

qualifying your post as spam is appropriate

Maybe I could have tagged it rather as off-topic…

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests