Proposal:Multiple landuse 2
Multiple landuse | |
---|---|
Proposal status: | Abandoned (inactive) |
Proposed by: | Zaneo |
Tagging: | landuse=* |
Applies to: | |
Definition: | A way to map multiple landuse on a single area |
Statistics: |
|
Draft started: | 2021-10-03 |
RFC start: | NA |
Vote start: | NA |
Vote end: | NA |
Proposal
This proposals proposes to codify multiple landuses to be semicolon separated values
- landuse=* = value1;value2
Rationale
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 maintainability, 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 semi-colon separated values for the tag landuse via for example landuse=*=residential;retail.
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=* with a semi-colon separated list of the land uses. The order of the items in the list specifies their importance. While this is up to the mapper to decide, it does not deviate from the existing problem mapper face (In which all other values are discarded).
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.
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.
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. Such implementation is left to the renderer.
Features/Pages affected
If this proposal gets accepted, the landuse=* page needs to be edited.
External discussions
This proposal has first been discussed to death and has a counter proposal at https://wiki.openstreetmap.org/wiki/Proposed_features/Multiple_landuse which is going to be rejected because people want to have semi-colon separated list.
This proposal is announced on the tagging mailing list and discussed on the talk page by extension of the original multiple land use proposal.
Comments
Please comment on the discussion page.
References
Voting
- Log in to the wiki if you are not already logged in.
- Scroll down to voting and click 'Edit source'. Copy and paste the appropriate code from this table on its own line at the bottom of the text area:
To get this output | you type | Description |
---|---|---|
{{vote|yes}} --~~~~
|
Feel free to also explain why you support proposal. | |
{{vote|no}} reason --~~~~
|
Replace reason with your reason(s) for voting no. | |
{{vote|abstain}} comments --~~~~
|
If you don't want to vote but have comments. Replace comments with your comments. |
~~~~
automatically inserts your name and the current date.For full template documentation see Template:Vote. See also how vote outcome is processed.