Proposal talk:Multiple landuse

From OpenStreetMap Wiki
Jump to navigation Jump to search

Some thoughts on the concept

As the person who originally proposed the idea to introduce more fine grained optional classifications of land characterization tags through the establishment of natural:secondary=*/landuse:secondary=* tags i would like to make a few comments:

  • It would be good to introduce this concept in a generic form and not limit it to landuse=*. Its applicability is probably even higher for more or less natural areas than urban landuses.
  • Care should be taken of precisely defining when these tags apply and when not. This is not trivial. For example when you have a residential area with a single shop somewhere - does that qualify the area for landuse:additional=retail?
  • I would disagree that landuse:additional=* is more neutral than landuse:secondary=*. On the contrary it implies an additive relationship between landuse=* and landuse:additional=*. landuse:secondary=* does not. Also landuse:secondary=* has a natural extension of the concept to landuse:tertiary=* while with landuse:additional=* you would need to resort to the ugliness of landuse:additional_2=* or similar.
  • Semicolon separated lists are difficult to introduce in OSM. Data users for good reasons shy away from interpreting them and it is inherently unclear if such lists are ordered or not. Addon tags are impossible or extremely ugly and error prone (by having several lists with the implicit requirement of them being of identical size and sorting, the inherent need to introduce and interpret a nil or none value). So i strongly suggest to avoid that.

--Imagico (talk) 12:43, 7 August 2021 (UTC)

Actually, I had this system with secondary before but for the proposal I changed it to additional. The reason I changed is because using lists as values has been done before so I tried to stick to that scheme. Also, with one tag, it is for data users clearer what tags to expect on a feature rather than the posibility that a few tags CAN but don't have to exist. But because I had this scheme initially, I am not unwillingly to change to this scheme. Let me think about it and see what others think.
Addition: How often would a tripple or more landuse occur? Is it worth adapting the scheme to a situation that does not occur a lot. 2 landuse ( 1 via landuse=* and landuse=additional occur in most of the cases --Cartographer10 (talk) 16:20, 7 August 2021 (UTC)
Re "How often would a tripple or more landuse occur?" As the propsal and also Imagico explicitly mention, the approach shall be suitable not only for landuse but other keys as well - and e.g. for amenity and shop, more than 2 values are IMHO no rare edge case, so this shall not need a complete re-definition. --Schoschi (talk) 19:17, 30 September 2021 (UTC)

How to determine what is primary vs secondary, etc.

Having lived in a building with commercial, residential and retail businesses how does one determine which is the primary landuse as well as secondary? Unless clarified there will likely be disputes between mappers. Having a document to help the mapper decide which is primary, and secondary would be very helpful. My building had two levels of parking, one for the businesses and their customers and one for the residents. There were two floor of businesses and three floors of residential units. Because the businesses could change periodically, it seemed having a landuse=mixed would make sense. Glassman (talk) 19:01, 25 September 2021 (UTC)

@Glassman: Thanks for the critical question. I have thought about this to. I didn't take a position on this in the proposal because the landuse key it self should take care of that. The current value for landuse is often fine as primary use because that is how people use/perceive it the most. I also wouldn't put to much weight in the order of the values for secondary and tertiary. You should read it more as "beside the main landuse as defined with landuse=*, there is a second or third (or more) landuse on this area." --Cartographer10 (talk) 07:39, 26 September 2021 (UTC)

Alternatives

  1. You could simply remove the "residential=* is a subtag for landuse=residential" requirement. Then the discussion will become landuse=* + (residential=* vs landuse:residential=*) or similar, concerning the data format. (If you don't mind incorporating both in a hierarchy, you could even do eg landuse=commercial + landuse:commercial=main + landuse:residential=secondary + residential=urban) + landuse:retail=limited I don't favor this though.
  2. What does "retail=* felt to specific" mean? Does this apply to eg commercial=*?
  3. This does not specify the location, which could be more important for the prominence. "Mixed" itself can come in many different layouts. The existing abutters=* may be unclear, so one can envision eg frontage=retail + backage=commercial + topside=residential.
  4. Further to 3 above, determination of priority is not as verifiable. For example, almost all residential with a retail base is considered landuse=residential in my place, which I agree for the prevalence of residential over commercial. They are purposed and built for residential. Only in some cases, eg apartment tower shared with a hotel, are they set as landuse=commercial or landuse=retail.

-- Kovposch (talk) 14:50, 7 August 2021 (UTC)

But with (residential=* you are going to use a tag for something is has not been made for. It is used to further define a landuse residential, not to indicate that a landuse is residential. There is the landuse key (or my addition) for. And I don't prefer landuse:residential=*. landuse:additional=residential is a much nicer solution in my opinion and also create a more predicable solution for data users.
With "retail=* felt to specific" I meant that with introducting a sub tag for retail via the proposal,, the proposal would only cover a specific situation while in theorie it can occur to all landuse combinations
I don't see veriabiliy that much as a problem. In the current system, the mapper also choses the most dominant landuse. The rest are additional. --Cartographer10 (talk) 17:38, 7 August 2021 (UTC)
Ok, what about 3? Eg:
---- Kovposch (talk) 08:33, 8 August 2021 (UTC)
How does that differ from abutters=*? In my opinion, this is going to make it much more complex then for example landuse:additional=* or landuse:secondary=*,landuse:tertiary=*. :frontage and :overhead are information I would expect on buildings, not on landuse. --Cartographer10 (talk) 12:14, 8 August 2021 (UTC)

Semicolons

The subkeys “secondary”, “tertiary”, and “fourthly” (should be “quaternary”) don’t add any semantics beyond an inherent priority order. I would strongly suggest a semicolon-delimited list in the original landuse=* key instead, per Multiple values. Semicolons already imply a priority order for some keys, such as destination=*, flag:name=*, and cuisine=*.

Perhaps you’re concerned that many data consumers may not be expecting multiple values for a primary feature key, but I suspect many data consumers would find it easier to support that approach than this system of subkeys. For example, the Mapbox Streets source already supports a semicolon-delimited list in keys like shop=* and amenity=*, simply by ignoring all but the first value in the list. It can do so with a variety of keys using shared code without having to special-case a unique tagging scheme for each key.

Data consumers that don’t look out for semicolons would treat the multiple landuse values like an unrecognized value. In my opinion, that’s perfectly fine: it’s the same treatment that would be given to a hypothetical landuse=mixed (which I have used in the past). For these landuse areas, it is apparently remarkable that there are multiple land uses, as opposed to the additional land uses being an afterthought.

 – Minh Nguyễn 💬 16:43, 25 September 2021 (UTC)

Thanks for the feedback. The biggest downside is that the ; way, will break rendering and other workflows and the current proposed namespacing proposal doesn't. Beside, most people and renders like mapbox will only need the first value so nothing changes. If data users need the second or third value, they can easilly access it. From a data users point of view, whether run a loop on a ; seperated list or predicable key names does not make a difference. It is equally easy. Also, in reality, there will only be a few values (don't expect many areas with more then 3 landuse values) so there won't be many keys. --Cartographer10 (talk) 17:07, 25 September 2021 (UTC)
I agree with Minh Nguyen. The "biggest downside" seems like a rather minor downside, and a downside that is also rather temporary: it is very easy to adapt the rendering logic to simply take the first value. Usage of either landuse:secondary=* or landuse:additional=* strongly feels like "tagging for the (currently existing) renderer" to me. Using semicolon-separated landuse=* seems much more attractive long-term as it is simple to enter and consistent with other multi-valued keys, and this is worth the temporary inconvenience of having to slightly alter existing rendering software. --JeroenvanderGun (talk) 20:29, 12 October 2021 (UTC)
Your example are attributes, not an area object or feature. destination=* attempts to transcribe a text block into a list. They are started, or picked up, with this implication defined. It's not possible to ensure there's any meaning to the order in an existing key. ---- Kovposch (talk) 18:04, 25 September 2021 (UTC)
@Kovposch: As I mentioned, some data consumers already accept multiple values even for feature keys like amenity=* and shop=*, which can be tagged on areas as well as points. – Minh Nguyễn 💬 19:36, 25 September 2021 (UTC)
This still can't express a difference when there's a mix of same-order and different-order qualifiers. If this is accepted, you should be able to use semi-colons in both, when the there are multiple more landuse=* or less landuse:secondary=* defining uses of the same significance.
Assume there exist a large, wide, and prominent mall; with an smaller office tower, and small hotel + mostly apartments tower on it. It could be landuse=retail + landuse:secondary=commercial;residential when the latter half is of similar qualities, if you don't want to choose between landuse:secondary=commercial + landuse:tertiary=residential vs landuse:secondary=residential + landuse:tertiary=commercial.
---- Kovposch (talk) 20:41, 25 September 2021 (UTC)
I personally wouldn't put to much weight in which value to place in secondary or tertiary. It is more to indicate the land is used for other purposes to then defined in landuse=*. I prefer to be consistent and only place one value in the tags. This makes it also more predictable for data users --Cartographer10 (talk) 07:32, 26 September 2021 (UTC)
@Kovposch: In practice, a typical renderer would most likely fill or stroke an area with the color corresponding to the primary landuse value. A more sophisticated renderer might choose a distinct color to mean "mixed" or crosshatch all the colors of all the landuse values. What's the use case for distinguishing multiple tiers of landuse values, each accepting multiple values? With that level of granularity, wouldn't it be better for a data consumer to consider what's inside the landuse area rather than the landuse area itself? – Minh Nguyễn 💬 18:09, 26 September 2021 (UTC)
@Cartographer10: My broader point is that landuse isn't unique in that there can be multiple notable values to tag. Will there be a similar tagging scheme for all feature keys, or will there be a hodgepodge of list-like subkeys on various feature keys? If there is a generic tagging scheme, then why limit it to feature keys and require attributes to use a completely different syntax? – Minh Nguyễn 💬 19:36, 25 September 2021 (UTC)
@Minh Nguyen: And I acknowledged that in the proposal but the landuse key is one of the best known where this can occur. The same namespaced tagging can be extended to other tags to if it is a success here. Because of the principle of "all you can tag", it can be used in other tags to without going through the proposal process. --Cartographer10 (talk) 07:32, 26 September 2021 (UTC)
@Cartographer10: Where in the order of precedence should the proposed subkeys go? – Minh Nguyễn 💬 17:35, 26 September 2021 (UTC)
@Minh Nguyen: Not sure why you are bringing this up but I suppose that my subkey is what they mean with Sub-key in the table. Otherwise generic. --Cartographer10 (talk) 17:42, 26 September 2021 (UTC)
That page is using the term "subkey" more strictly, to refer to refinements specific to a given key, such as siren:type=* for emergency=siren. If you envision the proposed tagging scheme being reusable for other keys, there would essentially be another row in this table. I guess my point is that the colons-in-keys system is already complicated enough as it is, for both mappers and data consumers, without exacerbating the situation. Semicolons are at least more discoverable and predictable, in my opinion as a mapper and data consumer. – Minh Nguyễn 💬 18:09, 26 September 2021 (UTC)

By the way, Seamarks/Sectored and Directional Lights and parking:condition=* do use subkeys like *:2=* and *:3=*, but there's a desire to move away from that syntax in favor of semicolons: Proposed features/Parking lane conditionals. —Preceding unsigned comment added by Minh Nguyen (talk • contribs) 18:50, 26 September 2021 (UTC)

FYI, this discussion is related to the one around Talk:Proposed features/shop as post-partner so some thoughts may be "taken over" to here. --Schoschi (talk) 22:02, 30 September 2021 (UTC)

Querying use cases

Landuse areas aren't only for rendering. I think it would be helpful to consider some querying use cases with the Overpass turbo wizard syntax:

Use case Status quo This proposal Semicolons landuse=mixed
Find all mixed-use developments N/A "landuse:secondary"=* landuse~";" landuse=mixed
Find all areas dedicated to residential landuse and nothing else landuse=residential landuse=residential and "landuse:secondary"!=* landuse=residential landuse=residential
Find all landuse areas that are primarily residential landuse=residential landuse=residential landuse~"^residential" landuse=residential
Find all the residential landuse, regardless of whether it's mixed in with other landuse landuse=residential landuse=residential landuse~residential landuse=residential
Contrived: Find all landuse areas that are secondarily residential (specifically secondarily) N/A "landuse:secondary"=residential landuse~"^\w+;residential" N/A
Find all landuse areas that are used for apartments landuse=* and residential=apartments ~"^landuse"~residential and residential=apartments landuse~residential and residential=apartments landuse=* and residential=apartments
Find all apartment complexes but not retail buildings that just happen to have a few apartment units above the storefronts landuse=residential and residential=apartments landuse=residential and residential=apartments landuse~"^residential" and residential=apartments landuse=residential and residential=apartments
Find all landuse areas that are used more for residences than retail N/A (landuse=residential and ~"^landuse"~retail) or (landuse!=retail and "landuse:secondary"=residential and ~"^landuse"~retail) or (landuse!=retail and "landuse:secondary"!=retail and "landuse:tertiary"=residential and "landuse:quaternary"=retail) landuse~"residential;.*retail" N/A
Contrived: Find all landuse areas that have three or more uses N/A "landuse:tertiary"=* landuse~";\w+;" N/A
Contrived: Find all landuse areas that have more than four uses N/A N/A landuse~"(\w+;){4}" N/A

Feel free to add other use cases you can think of that illustrate the pros and cons of each approach. So far I can only think of a few queries where the proposal has a clear advantage over the alternatives, but in my opinion, they're pretty contrived compared to more basic queries that become less discoverable. To me, this table says more about the complexity of allowing multiple landuses to be tagged explicitly than about the particular proposal before us, but maybe I'm missing something.

 – Minh Nguyễn 💬 18:46, 26 September 2021 (UTC)

@Minh Nguyen: Thanks for the overview, it indeed gives a good overview of the differences. At first, the seamarks are much more complex using nesting up to 4 levels while here I only have 2 levels. Personally, I don't find the queries overly complex that I would say lets not do it. Besides, personally I don think the slightly easier queries weight up to the loss of render support for a lot of renderers and breaking workflows. The main advantage of the current proposed system is that it leaves the current tagging intact and provides an extension system. Also, by seperating the values in seperate tags, the data user can use what they want as the queries show. If they only want to analyse the main landuse they can without having to use regex to split the values. --Cartographer10 (talk) 20:20, 26 September 2021 (UTC)
At least with the Overpass API, regular expressions for values are often significantly more performant than regular expressions for keys or additional clauses joined by and or or. One of these use cases that I don't consider contrived would have so many clauses as to be unusable beyond a small bbox. So at least in that regard, it isn't clear that the proposal would be advantageous. This is just one example of a data consumer; other tools such as Sophox and osmium would see a similar tradeoff. I'm not quite convinced it's a good tradeoff for the claimed benefit to renderers, but perhaps the proposal could be strengthened by a mockup of the renderings that the proposal would facilitate. – Minh Nguyễn 💬 21:37, 26 September 2021 (UTC)
That use case list implies that the main criterion for the choice of a tagging scheme should be the ease of use for the data consumer. This is diametral to traditional wisdom in OSM that tagging should always be designed for the ease of use and maintenance and clarity for the mapper. Because the scarce resource of OSM are competent mappers and not developers of tools that provide ease of use to data users.
Independent of that the idea of semicolon separated list will simply not work for tagging secondary classifications like here - for the reasons i explained further up. The table does not include the cases where the semicolon lists would be ugly, error prone and difficult to maintain. Like `natural=wood;bare_rock;heath` + `leaf_type=needleleaved;none;broadleaved`. Not to mention cases where primary and secondary classification use different keys - where it completely fails.
--Imagico (talk) 21:54, 26 September 2021 (UTC)

@Imagico: I didn't say (and am not of the opinion) that ease of use for a data consumer should be the primary consideration at the expense of mappers contributing and maintaining the data. But we should still be cognizant of the tradeoffs. After all, I don't think we're trying to make life difficult for data consumers, and in fact data consumers do appear in the stated rationale of this proposal. Other than the queries I've marked as contrived, the remaining queries could just as conceivably be run by "competent" mappers in the course of routine mapping.

I suppose I simply disagree with you on the elegance and intuitiveness of a single semicolon-delimited list versus a series of key-value pairs that, in all likelihood, will be presented out of order in most interfaces: landuse=residential landuse:quaternary=commercial landuse:secondary=retail landuse:tertiary=education. It seems the parking:condition=* tagging scheme solved this particular issue using numeric subkeys, skipping *:1=*), but that tagging scheme is hardly an exemplar of elegance overall.

 – Minh Nguyễn 💬 04:31, 27 September 2021 (UTC)

A truly "binomial" (at least!) example

In Santa Cruz County, California, OSM has zoning (multi)polygons that were imported in 2009. These effectively translate into landuse=* tags, the wiki link (Landuse section) explains the years of untangling, consensus and refinement over the first three versions of updates that the local community took to establish what tags from the import logically map to what OSM tags. One tag which remains problematic is "RA," standing for "Residential-Agricultural." These might be quickly characterized as a "live-on-the-property family farm," but they are more complex than that: they are often (but not always) largely treed (2/3 of the county is covered by trees, frequently redwood but often oak, pine, spruce and fir), but these areas are distinctly NOT "timberland" (landuse=forest, meaning "has an active timber permit and presently fells trees according to it," characterized from zoning data as "TP," for "Timber Production"). Additionally, because of this distinct zoning, the intention for these "family farms" to be "agricultural-producing" areas often happens with the real-world practice of fruit trees being planted, viticulture being established and hothouses being built. So, additional polygons are "superimposed" where these occur with the respective tags of landuse=orchard, landuse=vineyard and landuse=greenhouse_horticulture. The upshot of what the local community has decided to do is to tag these "RA" as landuse=farmland, "ignoring" the residential component which additionally takes place here. Carto and most renderers do OK with the double-tagging (of two landuses, one smaller of orchard, vineyard or g_h being superimposed upon a larger one of farmland), but it remains true that the concept of "live-on-the-property" part of these "farms" is lost, as no landuse=residential tag occurs (because of a syntax collision with farmland), nor is an ADDITIONAL (multi)polygon that might be tagged landuse=residential added on "RA" areas. (Though, it could be, but what would / should then render? That was the unknown that prevented such "double polygons" from happening to RA polygons.) Another complication is that what OSM might agree really ARE landuse=forest areas DO sometimes logically agree with that tag being used on these "RA" areas, such as if they are used for "more forest-oriented agricultural production" semantics, like mushroom-gathering, beekeeping / apiaries, or the cultivation of beneficial insects like ladybugs for aphid infestation control — as many of them actually do, I can say from first-hand experience of knowing them or visiting them. The trouble is, each and every (multi)polygon zoned RA and entered into OSM as landuse=farmland would have to be visited or queried individually to determine if its particular agricultural proclivities leans more towards (all or partly) "row crops" (farmland), vineyard(s), greenhouses, orchards, beekeeping, mushroom-gathering, beneficial insect-cultivation, all but the former with their own particular, different tagging, even as the "overarching" landuse might be correctly characterized by "farmland," or "forest" or even a mix of the two. Oh, yeah, I'll mention again that "a family lives here" (residential), too.

This (tagging as landuse=farmland) has caused conflict by mappers who come along and confuse landUSE with landCOVER and add natural=wood on areas with trees they can see in a visual imagery layer, leaving poor Carto (or any renderer) deeply confused as to what to best render for this "somewhat treed farmland" (where people also live). According to other mappers in the area who have found the difficulty of renderers not coping well with multiple landuse and landcover tags (even as both are extant and accurate), there are some occasions where a correct "landuse AND landcover" can and do happen together, somewhat properly, as in the case of a "mostly treed (natural=wood) area where people live in single-family homes" (landuse=residential — amongst dense trees) and Carto produces a "gray (residential)" polygon, but (delightfully!) superimposed with dark-green trees, quite accurate and visually pleasing. However, many ask: what would be the equivalent rendering for "residential-agricultural" of this sort? The former is a gray fill, the latter is a dull yellow fill, and seemingly, never the twain shall meet (at least in Carto, other renderers might do something clever and/or different). By the way, a principal author of Carto has called this county "one of the best-mapped in the USA, certainly the best-mapped in California" and he uses its countywide data to test new features in the Carto renderer. That's nice to hear, but in my opinion, there is still "cleanup" work to do, in addition to better refining those areas where "only landuse" or "only landcover" could be much better mapped as "both accurate landuse AND accurate landcover," though possibly resulting in "how is this best rendered?"

This proposal makes me reconsider adding a second (identical) polygon to those which are RA (which the local community chose to be exclusively landuse=farmland): one which is tagged landuse=residential. But I also consider changing the tag on the existing polygon to landuse=farmland;residential, which truly is accurate, according to the zoning, according to OSM's "semicolon syntax." Let Carto and other renderers "figure it out," I'm here to tag what is accurate in the real-world: both as zoning translated as landuse=* and when appropriate — it isn't always clear — when I might also tag for landcover, as maybe it is correct to also tag natural=wood where that is true. I'm not here to tag for the renderer. Though, I very much like it when renderers parse somewhat complex multiple landuse / landcover tags and render something both visually pleasing and "accurate."

By the way, I can imagine quaternery landuses (they exist now, right?), and even beyond (fifth-level, even sixth-level...). This gets really complex, really fast; we are talking about "how land is used by humans on Earth" and that is a fantastically deep set. Six and beyond, to seventh, when you include future generations and how we must live upon this planet. But now we get into a whole squabble-squad who quibble over details...I'd not want anything to do with that. I can see it as a seven-dimensional space (or so) and mention it here as a place it could go. Maybe we are only squabbling over semicolons or colons in our syntax, and how and all that. "Keep it simple."

The upshot is that I don't know what to think of this proposal: it would add even more options to what has been confusing for virtually the entire history of OSM. For that reason (it further complicates what is already complex), I'm inclined to oppose it, leaning towards "semicolon syntax" being sufficient: let renderers "figure it out." Stevea (talk) 20:07, 28 September 2021 (UTC)

Thank you for the large example. Landuse can indeed be difficult sometimes. Is landuse=farmyard not more in the direction you want and landuse=farmland for the area around the yard? But that asside, this proposal should make these discussions easier. It allows for these complex cases to be possibly tagged in a way that there is render support (which ; separated values in the landuse key don't have) but where the additional landuse information is in the database. That you have such a complex case does not mean that this proposal is bad, maybe the specific case is not taggable in OSM in the way you want because the government classification is just to vague. As is writtin on the documentation page for your import, these RA lands should be converted into farmland or residential by the mapper based on local knowledge. Maybe for some edge cases, this dual tagging system can actually help the mapper in making this descision, knowing that they can tag both where needed.
As for landuse vs landcover, this proposal does not take a position in that and relies on the definition and use of the current landuse tag. This proposal cannot resolve the unawareness of some people about the difference between landuse and landcover --Cartographer10 (talk) 06:09, 29 September 2021 (UTC)
"landuse=forest, meaning "has an active timber permit and presently fells trees according to it,"" - that is not how this tag is actually used. Mateusz Konieczny (talk) 14:50, 29 September 2021 (UTC)
In this specific case landuse=farmyard and landuse=farmland areas would be valid tagging and this data was not directly importable into OSM. It is case illustrating damage caused by imports rather than supporting this tagging schema Mateusz Konieczny (talk) 14:52, 29 September 2021 (UTC)
Mateusz, thank you for chiming in. While I realize you do not "accuse" me directly of this import, please know that I did not do the import, user:nmixter did. Rather, I have spent over 11 years doing my best to clean up these data as best I and the OSM community know how to do, over multiple iterations of updates and during changing landuse, protected_area and other tagging schemes (these have been "mostly" stable, but there have been changes). This has not been easy, yet Joseph Eisenberg did make those comments about "best in California" and Santa Cruz DID win a "Gold Star Award" (one of the few places in North America to receive one) from BestOfOSM.org, with the notation "nearly perfect landuse." I wouldn't call Santa Cruz County "damaged by landuse imports," are you? You are correct that "farmyard" is appropriate in as broad a definition as you would have it be used here, as I have used this tag on areas which are adjacent to actual farmland (the traditional kind, what people sometimes call "row crops") in my county. These "farmyards" have a barn, feed bunker or other outbuilding, tractors and tillers parked adjacent (perhaps with a simple no-wall building=roof for rain protection) and ancillary equipment like irrigation fittings. If you assert that a farmhouse where "the family lives" is properly characterized by "farmyard" (I just checked our wiki, it DOES!), I'll start using that. But I didn't know that a farmhouse is correctly characterizable by "farmyard," and besides, with the relatively large amount of treecover on many of these "farms" (especially in Happy Valley area of Santa Cruz County), aerial imagery does not always reveal where "the farmhouse" is actually located. (Lots of people around here LOVE the fact that we live in densely-treed areas!)
Cartographer10, yes it is true that landuse/landcover issues have relatively widespread confusion and are sometimes difficult to articulate to some people. My point is that sometimes (as in "RA"), either a choice must be made between residential and farmland, and/or a "double-polygon" (or even triple or quadruple if this proposal is correct about quarternary) would have to be added, a seemingly great amount of data when a smarter tagging scheme (semicolon-separated?) would do just fine instead. I'm still "sitting on the fence" (undecided) about this proposal, as it is "complex on top of what is already complex" but it definitely addresses a need in OSM. I'm just not sure if it is the best approach. It seems like a thoughtful "first draft," but there is a great deal to consider here. It also seems like it could turn into a nightmare of "OK, go ahead and do it differently in your country, but we do it like THIS in our country..." kinds of squabbles. Stevea (talk) 21:39, 29 September 2021 (UTC)

BTW, there certainly are "mixed use" areas in Santa Cruz (City and County, two different jurisdictions), such as a commercial building at street/ground-level with apartments above (sometimes, not always) lived-in or owned-by the owners of a downstairs business. Right now, our "county zoning" does rather finely-granularized characterize these as what mixes of what uses are blended together. I can even think of a tertiary (or even quaternary if you include the space as "museum") where an "art colony" of medium-density two-and-three-level "flats" (where people/maybe-owners live) where there is either industrial space or commercial space (or both) for them to use as a "crafter." This is a sort of professional artist who "makes things" and/or "sells things" in a lower floor (industrial, commercial) area of the building they live in upstairs. That's at least three uses (tertiary) and maybe four as the space in general is an "arts center" and has exhibitions as a particular flavor of "local museum." How would/do I (best) tag this in OSM? Well, I consider this proposal.... (I've already learned a lot I didn't know about farmyard and more as I listen). Stevea (talk) 22:26, 29 September 2021 (UTC)

Details to refine after voting

https://wiki.openstreetmap.org/wiki/Proposal_process#Voting says during voting, the proposal must never be changed. So let's start a collection of what shall be refined after voting ended, i.e. what shall be edited while revising the proposal before the next voting starts, or while transitioning the proposal to the approved tag wiki page:

  • "Features/Pages affected" does not mention changes of existing features
    • Migrate features with keys landuse_1 etc to newly approved tagging scheme
    • Migrate features with key landuse and having multiple values to newly approved tagging scheme
  • missing/redundant words, grammer, typos etc
    • "if the edge is not withing view"
    • "Note that for if example"
    • "make sure the properly cut out the polygons so that"
    • "Atleast on carto"
Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=Proposal_talk:Multiple_landuse&oldid=2515876"