Proposal:Multiple landuse

Multiple landuse
Proposal status:	Rejected (inactive)
Proposed by:	Cartographer10
Tagging:	landuse:secondary=*
Applies to:
Definition:	A way to map multiple landuse on a single area
Statistics:
Draft started:	2021-08-01
RFC start:	2021-08-07
Vote start:	2021-09-28
Vote end:	2021-10-12

Proposal

This proposals proposes a namespaced addition to landuse namely:

• landuse:secondary=*, landuse:tertiary=*, landuse:quaternary=*: A series of sub-tags to add additional landuse values to an area to indicate mixed landuse as addition to the main landuse mapped with landuse=*.

Rationale

Example of multiple landuse drawn on top of eachother. Note that features like buildings have been hidden for this image. Image taken in JOSM

Especially in cities and villages, land often has multiple purposes like a mix between landuse=residential, landuse=retail, landuse=commercial. For example, in a city center, the main landuse of a shopping area might be landuse=retail. It is quite common however that apartments are present above the shops. The current landuse tagging scheme cannot deal with the dual (or more) use and forces the mapper to choose the most dominant landuse. This also results in mappers drawing two landuse areas on top of eachother like can be seen on the image at the right. It might look fine on the map but this makes the data messy. For several reasons this is not desirable:

• In terms of maintanability, this means that in case of changes, two or more polygons have to be edited. The second landuse might also be missed if the edge is not withing view.
• For data users, this way is also not desirable. In order to determine for example dual use, they would have to analyze the areas first. This would also be true for renderers wanting to render dual landuse. They first have to merge the overlapping features.
• Restricting the landuse tag to only one entry per polygon also makes it harder for mappers to choose which landuse they want in case they don't want to use overlapping polygons. This proposal fixes that by giving mappers the option to add multiple landuses.

This proposal seeks to introduce and document a solution to fix this problem and enhance the data via namespacing the tag landuse via for example landuse:secondary=*.

For now, this proposal is made for the landuse key. In theory this dual use can occur at other keys to like natural=* and the same namespacing of :secondary,.. can be used. This dual use problem occurs a lot at the landuse key so that is why this proposal focusses on that. If it is a success, it can be used for more tags.

Choice for tag

Several tags have been thought of:

• landuse:additional=* has been considered but that would mean that for example multiple additional landuse values would have to be seperated with ;. This makes it harder to data users to use because they first have to split the value and secondary etc seems like a clearer solution
• landuse_1=* and so on has been used a few times according to tagInfo. This would introduce new top level keys where with namespacing, you built upon the existing landuse key. Also, landuse_1=* would mean it is the first landuse while this needs to be landuse=* to not break rendering and existing use. The 1 is misleading here. Additionally, this means that in potential, multiple tags could be created on the same area. This can also be confusing for data users in case multiple landuses are tagged. Namespacing is a much clearer solution here and looks nicer.
• It was thought of to use residential=apartments as addition to landuse=retail. However, residential=* is a subtag for landuse=residential, further specifying the residential landuse. Also, this means tags like retail=* have to be created. Residential and retail are just examples. Theorerically, any landuse can overlap requiring multiple of these sub tags.
• It would also be a lot of work to add all the information to individual buildings. That would also require a dual use tagging scheme to indicate dual use of buildings so the same problem stays. Next, all the buildings in an area need to be analyzed to derive the landuse. This makes it hard to use dual landuse in the current system, both for renderers and data users.

Tagging

Draw an area and use landuse=* to indicate the main use of an area. Next, use landuse:secondary=* or others like tertiary to indicate additional landuse. Additionally, all sub tags that can be applied to landuse can be used as normal like name=* or residential=* without namespacing.

The detail on which the landuse is mapped is up to the mapper. People can map landuse for a large area, per building block or per building (for example in a street with mixed landuse use and where the mapper wants to micromap the landuse). Note that for if example within a residential area (lets say covering a city (block) or neighbourhood) there are a few single/ small businesses, dual tagging the retail/commercial use should not be used. This is not in proportion and then retail and commercial can be added to a lot of landuse areas. It is then preferred to split up the area and map it in more detail.

Changing existing situations

If in the current situation, two landuse areas are drawn on top of each other, make sure the properly cut out the polygons so that they don't overlap anymore (example 2 below). Then use landuse=* and landuse:secondary=*.

When not to use dual tagging

Dual landuse tagging should not be used if a value already implies the presence of another landuse value by definition. For example landuse=farmyard by definition already includes a house. There is no need to draw an area of landuse=farmyard and use dual tagging to add landuse=residential for the house.

Examples

Below some examples are illustrated. Note that this is not yet present in the database but that the data is temporarily edited for these images. Also, the examples are about retail, residential and commercial but this could apply to any landuse values.

Example of the dual use. The dual mapped area is the rotterdam used for both offices and living. Image taken in JOSM

Example of the use of both landuse=retail and residential. Note that optionally, you can cutout the landuse on the roads but that is up to the mapper. Image taken in JOSM

Rendering

Atleast on carto, these additional values do not need to be rendered. Like in the current situation, the value landuse=* is used for rendering. In the future, common combinations like retail and residential can be rendered differently.

Features/Pages affected

If this proposal gets accepted, the landuse=* page needs to be edited. Also, a new page for this tag will be created.

External discussions

This proposal has first been discussed on the Discord OSM World server (Discord account needed), and the Dutch forum

This proposal is announced on the tagging mailing list and discussed on the talk page.

Comments

Please comment on the discussion page.

Voting

Voting closed

Voting on this proposal has been closed.

It was rejected with 14 votes for, 23 votes against and 3 abstentions.

There seems to be some interest in this dual landuse tagging, only not enough. This is also because of the discussion about the use of ; seperated values

• I approve this proposal. --Cartographer10 (talk) 17:47, 28 September 2021 (UTC)
• I approve this proposal. It happens often enough that areas are multifunctional, and if we can tag that while preserving the main landuse tag, I think this is a decent way to do it. --501ghost (talk) 18:04, 28 September 2021 (UTC)
• I approve this proposal. Doesn't conflict with existing tagging or add any new landuse values, allows specificity and hierarchical organization. I think this is a good approach to the problem. --Jdcarls2 (talk) 18:08, 28 September 2021 (UTC)
• I approve this proposal. I foresee the need to refine/extend the system later on, but let's start with the simple cases presented. --Peter Elderson (talk) 18:16, 28 September 2021 (UTC)
• I oppose this proposal. (1) definitely against approving landuse:quaternary=* monstrosity. (2) overlapping landuses are sufficient. Neither arguments applying to mappers nor data consumers are convincing me. Mateusz Konieczny (talk) 19:16, 28 September 2021 (UTC)
• I oppose this proposal. as Mateusz --Polarbear w (talk) 20:22, 28 September 2021 (UTC)
• I oppose this proposal. Sorry, but this tagging scheme just doesn't seem sensible - as a data consumer how many values do I check for? What happens after four etc (although I admit very unlikely)? We already allow for multiple values in most keys and, indeed, this is already in use for landuse too. --Casey boy (talk) 20:46, 28 September 2021 (UTC)

@Casey boy: More then four is indeed rare but after that you can just continue (bit first reconsider the size of the area you are mapping). A lot of renderers and other data users cannot deal with ; seperated lists meaning that if a mapper wants to tag dual use, rendering for large areas will drop. This proposal extends the landuse key in a none conflicting but yet predictable way (you just have to check for several values after landuse: --Cartographer10 (talk) 05:55, 29 September 2021 (UTC)

Thanks for the response. I can see there has been a lengthy discussion on semi-colon seperators. Unfortunately, at least for this proposal, I agree that semi-colons are the better approach to take. Just to note, it's not that renderers/data consumers can't deal with it, it's that some don't. Big difference. Any renderer could easily cut the string at the semi-colon and only use the first value. Casey boy (talk) 14:06, 29 September 2021 (UTC)

• I oppose this proposal. This proposal seem cumbersome. A simple landuse=mixed would have be much simpler. It also create a potential for arguments over what is primary, secondary, etc. --Glassman (talk) 22:22, 28 September 2021 (UTC)

@Glassman: But in my opinion, landuse=mixed is to general meaning a lot of areas will get this tag. You then have to specify the actual use via sub tags. Do you have an idea how this solution would look like? Additionally, this proposal should reduce problems for mappers because currently they have to chose 1 value and this proposal removes that constraint. --Cartographer10 (talk) 05:55, 29 September 2021 (UTC)

• I approve this proposal. There seems to be two camps on if semicolon separated values are good or not. This proposal is valid given that no matter what, you’ll have opposition from one side. Having to check overlaps of polygons is way more expensive than checking 4 defined tags. I disagree that mixed is a good enough tag, given the number of possible mixes. -- Zaneo (talk) 00:36, 29 September 2021 (UTC)
• I oppose this proposal. If you think you need more than one land use, odds are your landuse polygons are too generous. --Baloo Uriza (talk) 01:19, 29 September 2021 (UTC)
• I oppose this proposal. Despite I understand the concept here, I don't support reflecting in landuse the marginal features you may find in a more global polygon. For instance, I fail to catch the relevancy of defining a commercial zone for shops in the basement of residential buildings. Fanfouer (talk) 08:32, 29 September 2021 (UTC)

@Fanfouer: Concerning your example (which IMHO is not really heavily triggering/benefiting by the proposal): Imagine a city with an extensive residential area and only in one small part oft it, there are shops in the basements. You're in need of some stuff, hence want to know where to walk. If tagging the whole only as residential, you need to zoom in so much that shop icons will be visible and then need to pan around in the map a lot until you find the "also commercial" zone. If most of the area is tagged only as residential and the small part as both commercial & residential, you could see on low zoom levels where you shall zoom in until you see shop icons - quick and straight forward. --Schoschi (talk) 21:43, 30 September 2021 (UTC)

• I oppose this proposal. This still leaves unsolvable decisions for the mapper, e.g. where a building has retail in the ground floor, 3 floors of offices and 5 of apartments above, which would be primary and which secondary and tertiary? Depends on what you are interested in. For more detailed usage information, my suggestion would be adding building usage on a floor level (or floor range level). I can imagine secondary landuse being useful in rural situations. Quaternary should be out of discussion ;) --Dieterdreist (talk) 08:43, 29 September 2021 (UTC)

Number of levels or floor area doesn't necessarily imply its significance. If there are 3 levels of parking or warehouse in between 2 base retail levels and 5 higher apartments levels, it doesn't mean the middle section is more prominent than the lower section. While deciding between landuse:secondary=* and landuse:primary=* is a concern, the same would apply to landuse=* itself as well. ---- Kovposch (talk) 20:08, 30 September 2021 (UTC)

I agree to Kovposch: If primary versus secondary landuse is an unsolvable decision, having only one landuse value will be even more unsolvable, because one landuse will be completely lost/dropped. --Schoschi (talk) 21:43, 30 September 2021 (UTC)

I did not write that quantity was a way of deciding significance, what I suggest is adding all the various use values by level or building:part and let the dataconsumer decide how to valuate them.Dieterdreist (talk) 08:39, 11 October 2021 (UTC)

• I approve this proposal. I see it similar to Zaneo. Multiple polygons for the same object can quickly lead to inconsistent data if changes are not captured correctly on all polygons. In any case, it is better to use multi-selections. It should also be kept in mind that especially beginners often have difficulties with polygons. And if there are several for the same purpose, this group of mappers has even greater problems not to make mistakes. - BLE (talk) 12:38, 29 September 2021 (UTC)
• I oppose this proposal. Same as Mateusz Konieczny --Mueschel (talk) 17:08, 29 September 2021 (UTC)
• I have comments but abstain from voting on this proposal. I recuse myself, as I have said a lot in the Talk page, and after voting started. --Stevea (talk) 23:02, 29 September 2021 (UTC)
• I approve this proposal. --Roef (talk) 09:02, 30 September 2021 (UTC)
• I approve this proposal. Despite the debates, this should be able to co-exist with any possible further specification in landuse:*=*. ---- Kovposch (talk) 19:59, 30 September 2021 (UTC)
• I oppose this proposal. Overengineered, to be blunt. We have too many tags of marginal utility, and this proposal is a clearcut example. It is unlikely to ever come into widespread use, and puts too much burden on data consumers for unclear benefits. Duja (talk) 20:31, 30 September 2021 (UTC)
• I oppose this proposal. +1 for Zaneo's and BLE's points. I don't belong to any of the two "camps", i.e. I have neither a preference for one key with ; or | separated lists as value, nor for multiple keys using suffixes -- but I do not support this concrete suffix proposal because I dislike the suffixes :secondary, :tertiary, :quaternary:

• They are lengthy to type
• They use words that are not common in everyday language ("quaternary" has only 26 mio results in Google) and whose spelling is not trivial. That combination will cause a considerable amount of typos, especially by those ~7,6 billion out of the earth's ~8 billion humans whose mother tongue is not EN
• They will be shown alphabetically sorted in many apps instead of natural/logical/semantical sorting.

I would rather type 2nd, 3rd, 4th (or just 2, 3, 4 like parking:lane) because it's shorter, more common ("4th" has 762 mio results so 30 times more), has easier spelling, and the number-based suffixes will be sorted "naturally" at least until we exceed 9 values (then, sorting may be like for strings so 2, 21, 22, 3, 31,...). All of that would not bother me for only landuse, but the proposal explicitly tells it's currently only targeting the landuse key while ultimately aiming to be used on more tags - so probably also frequently used ones like building, shop, amenity etc. --Schoschi (talk) 21:43, 30 September 2021 (UTC)

@Schoschi: Is is possible to have purely numeric tags/sub tags? If so then I concur. Zaneo (talk) 00:58, 1 October 2021 (UTC)

Numbers doesn't show a priority in parking:lane=*. What search results do you mean? "quaternary land use" shows up ~2k, seems to be a somewhat used terminology in land utilization classification together with others. The same words are used in education and economic sectors.

"Primarily" I support this system because it reminds me of voltage:primary=* and voltage:secondary=*, which is common enough. There are tertiary windings too, so possible to have voltage:tertiary=*.

---- Kovposch (talk) 10:26, 1 October 2021 (UTC)

@Kovposch: AFAIK purely numeric subtags are possible and e.g. parking:lane) is using that and while there, numbers are not required to reflect priority, we may define them with clear priority order in landuse context like we did e.g. for Key:layer values. Concerning search: I use amount of Google search results as one indicator how common a word is. "quaternary" may be known by EN native speakers as well as it may be common in some domains also for people with EN as 2nd/3rd/4th language, but it is very uncommon in the everyday English people with other mother tongue hear/read frequently - e.g. in pop songs, advertising, product handbooks, discussion forums, popular citations, etc. which also reflects in factor 30 less search results than "4th"). Similar for term "tertiary" versus "3rd". In contrast, "primary" and "secondary" are IMHO much more common terms (1480 mio respectively 648 mio search results, many languages know a variant of these 2 words, these words are more often used in forums, handbooks,...). --Schoschi (talk) 22:37, 1 October 2021 (UTC)

• I oppose this proposal. I agree with many of the points made above. OSM already has a widely used way to represent keys with multiple values (the ; separator). That method isn't without its drawbacks, but having two competing conventions (; separators vs :secondary etc) will cause unnecessary confusion. — Jake Low (talk) 00:48, 1 October 2021 (UTC)
• I oppose this proposal. I don't think expecting data users to parse *:secondary,*:tertiary,etc is reasonable or scalable. There are already exisitng methods (overlapping polygons or semi-colon separated values) to denote mixed land-use. I don't think we should add something else that isn't necessary. --Rjw62 (talk) 12:08, 2 October 2021 (UTC)
• I oppose this proposal. Reasons already stated above --Lejun (talk) 05:40, 3 October 2021 (UTC)
• I approve this proposal. --EneaSuper (talk) 09:47, 3 October 2021 (UTC)
• I approve this proposal. A welcome addition to cope with the many instances of an orchard which at the same time is also a vineyard. --Marczoutendijk (talk) 12:04, 3 October 2021 (UTC)
• I oppose this proposal. Smaller overlapping polygons are a better solution in most cases of urban land use, as shown in the examples here (e.g. mapping specific buildings) - adding a new key to tag the ground floor vs upper level usage for mixed-use buildings with for example retail on the first floor, hotel above and residences at the top would be more useful and specific than this. I particulary oppose the proposed landuse:tertiary and landuse:quartenary tags - how is a mapper really supposed to determine which of 3 or 4 uses is primary vs less important? --Jeisenbe (talk) 21:05, 3 October 2021 (UTC)
• I oppose this proposal. Reasons already stated above --TheBlackMan (talk) 05:47, 4 October 2021 (UTC)
• I oppose this proposal. Reasons already stated above --Fnuttens (talk) 07:09, 4 October 2021 (UTC)
• I oppose this proposal. Please use ";" scheme already in place for any tag, including "landuse". --Reino Baptista (talk) 07:24, 4 October 2021 (UTC)
• I oppose this proposal. Why not use 2 more refined to tag those “landuse=residential+landuse2=commercial”? you can separate this area and tag the one that more close to road with "landuse=commercial", another with "landuse=residential". Although I often meet with so called "沿街房" or "门头房" in China, but I don't think landuse2 is a good way to tag this, the tag will made new mapper mixed. And How will you render the landuse2? --快乐的老鼠宝宝 (talk) 08:23, 4 October 2021 (UTC)

(For my opinion's addition) I'm afraid there will be more "secondary" tag born, and the naming style that Schoschi said above, :secondary, :tertiary, :quaternary…… will grown after this tag approved. I'm afraid this will be the precedent of this kind of naming style. If you really want to enum a lot of landuse, why not use ";" to make a list? --快乐的老鼠宝宝 (talk) 08:30, 4 October 2021 (UTC)

• I have comments but abstain from voting on this proposal. I'm missing criteria for the ranking of land uses, i.e. which is landuse, which is landuse:secondary etc. Does landuse=retail always has precedence over landuse=residential or is the proportion of the areas decisive? On the other hand, overlapping landuse areas or using the semicolon separator in a top-level tag seems very bad for data users. --Dafadllyn (talk) 21:13, 4 October 2021 (UTC)
• I approve this proposal. --LouisXIV (talk) 09:45, 7 October 2021 (UTC)
• I approve this proposal. Initially this proposal felt a little awkward, but that is due to the general fact that OSM tagging is ill designed for multiple values. This proposal gives a defined location for multiple values while keeping compatibility with the main value and not breaking anything. Suggestions like semi-colon values or "mixed" would damage existing maps and data consumers, so this proposal is definitely the better alternative. --Nop (talk) 07:51, 10 October 2021 (UTC)
• I approve this proposal. I agree with Nop and Dafadllyn: alhtough the proposed method may have its drawbacks I think it is preferable over the poorly supported use of semi columns ";" in OSM or overlapping areas within the same key. A ordered way to use multiple values is a step forward in my opinion --Multimodaal (talk) 10:18, 10 October 2021 (UTC)
• I oppose this proposal. Same as Duja --Geim (talk) 07:00, 11 October 2021 (UTC)
• I have comments but abstain from voting on this proposal. I tend to prefer to a single system. If this'd be the method for multiple values, it should be the same for all tags. On top of that, secondary, tertiary, ... suggest a most important, less important tag, which is not ambiguous for landuses nor many other tags. And regarding the semicolon values being poorly supported, data consumers could (as an intermediate solution) use i.e. [landuse=~/^residential/] or [landuse=~/^residential(;|$)/] instead of [landuse=residential] to match the 'primary' landuse: matches both residential as well as residential;retail --Famlam (talk) 07:02, 11 October 2021 (UTC)
• I have comments but abstain from voting on this proposal. I see the value in documentation additional landuse, and it makes sense to keep landuse=* itself as a single-value tag for the primary landuse. I agree with others that :secondary etc. is too unwieldy. There is nothing that prevents data consumers interested in additional landuse from parsing a semi-colon separated list in landuse:additional=*. The semi-colon separated list is a well-established notation in OSM for multiple values after all. --JeroenHoek (talk) 07:56, 11 October 2021 (UTC)
• I oppose this proposal. I feel that only the primary landuse should be tagged for an area (residential, commercial, industrial, etc..), based on what is present at ground level. Additional information such as "there are apartments above the shop" can be micro-tagged at the individual building level. For example, an area with shops on the ground floor and apartments or flats above the shops should be landuse=commercial (or retail). I would be okay with extending the commercial=* key to express a more fine-grained description of the type of commercial area, for example (hypothetically) commercial=strip_mall. I am also opposed to semi-colon separated landuse values as this breaks or frustrates many data consumers. --ZeLonewolf (talk) 12:47, 11 October 2021 (UTC)
• I oppose this proposal. I only see this tag being used for urban areas with mixed zoning, but you can pretty easily just make smaller landuse polygons for different buildings, and specify on the building object the exact purpose. ZeLonewolf said. --SherbetS (talk) 15:14, 11 October 2021 (UTC)
• I oppose this proposal. I strongly oppose this tagging for many of the reasons already given above by others. --Riiga (talk) 18:30, 11 October 2021 (UTC)
• I oppose this proposal. I'm not convinced that this is workable --Rskedgell (talk) 12:55, 12 October 2021 (UTC)
• I approve this proposal. --Shaun das Schaf (talk) 13:46, 12 October 2021 (UTC)