Proposal talk:Landuse=storage

Yes, please

I already used this, I could not find any accepted alternatives either. Intgr (talk) 18:19, 18 June 2020 (UTC)

What kind of storage? I am not a fan of this tag as it mixes cases like "storage of a logged lumber", "electronics warehouse", "storage units with personal items", "storage of firefighting materials", "storage of archival documents", "storage of mothballed tanks" and every other kind of storage. I typically use things like landuse=industrial + industrial=warehouse Mateusz Konieczny (talk) 02:36, 19 June 2020 (UTC)

To keep them apart, you can use the storage=* subkey. industrial=warehouse cannot be used for most storage facilities or areas, as it would violate the key definition "Type of industry". Storage is not a type of industry. Same as parking is not a type of industry. Do you tag parking places within industrial areas as industrial=parking? Do you tag trees within residential areas as residential=tree? --Fkv (talk) 07:21, 19 June 2020 (UTC)

I used it for outdoor storage like this: File:Paljassaare water treatment storage 2.jpg, but I see plenty of other uses too, such as timber, gravel, sand etc storage. I don't have strong opinions on whether to use landuse=storage or landuse=industrial + industrial=storage, I just could not find the latter when I was looking for it. Intgr (talk) 10:17, 19 June 2020 (UTC)

Storage rental

landuse=garages is an already used approved tag to for the landuse of storage buildings that can be rented. In America, we just call them storage units or something very similar, because we don't generally call something a garage unless it contains a car or was built for the purpose of storing one. So, I'm not sure how landuse=storage would conflict with landuse=garages or our usage of the word, but my guess is that it would with both.

landuse=garages *is* for cars only per definition: "One level buildings with boxes commonly for cars". An area full of one-level garages is a rare thing at least in my country, and I wonder why it is so abundant in the OSM data. Maybe it's because of an obtrusive menu entry in a common editor? Anyway, garages are parking facilities and should thus be treated similar to amenity=parking. I think that we can exclude parking places from landuse=storage, because we don't normally think of them as storage. --Fkv (talk) 12:03, 19 June 2020 (UTC)

landuse=garages is used primarily in Central and Easter Europe - https://taginfo.openstreetmap.org/tags/landuse=garages#map - where such areas are actually present. Is is also not very popular. +1 that it is for car storage in buildings, not other kind of storage Mateusz Konieczny (talk) 14:47, 19 June 2020 (UTC)

Also, most places in my experience don't consider lumber yards as a storage place. Since they usually very active and the lumber doesn't tend to sit there for very long. I've always thought a better tag for that would just be whatever=lumber_yard (probably industrial because it's the most intuitive. There's currently like 70 uses of it and it makes the most sense to me).

I'm not a native English speaker, and in German we don't distinguish timber and lumber by name - we just call it Holz (wood). But there is a difference: Timber in timber yards in the forest is often left there for months, whereas the processed lumber can't lie around for too long in bigger quantities, because either the wood quality would suffer or it occupies precious space. Anyway... Even if a timber yard is left empty for months, its main use remains the storage of timber. Those areas are not uses for anything else. I don't see what's wrong with a landuse=storage tag on an area that is mainly used for storage. That's the purpose of the landuse=* key, isn't it? --Fkv (talk) 12:03, 19 June 2020 (UTC)

Also, having a specific storage=material tagging scheme seems a tad to much like an attempt at inventory tagging. Which isn't the purpose of OSM, goes bad anytime it's tried, and there are already plenty of "material" tagging schemes that no one can agree on as it is anyway. Also, "lumber yards" don't always contain wood. A lot of times they are empty. The same goes for a key like "mixed." It's wannabe inventory tagging. Plus, keys like it aren't good because they just become a generic catch all for people who use them as an easy way to map something without putting in the time to be specific about what they are mapping. No map consumer is looking for "mixed" storage anyway, because it's so ambiguous of a word as to be completely meaningless. Otherwise, it will require the addition of a bunch of other tags that shouldn't be added just to clarify it. --Adamant1 (talk) 09:58, 19 June 2020 (UTC)

I am not fond of the "mixed" value either, but it's similar to leave_type/leave_cylcle=mixed or sport=multi, all of which you don't seem to oppose. It might be more useful to use comma-separated values if you know the components, or omit the subtag altogether otherwise.

Yes, there are numerous keys for inventory/content (material=*, substance=*, content=*, product=*, produce=*, ...), but each of them has their own purpose, their own right to exist, and I don't find them as disputed as you do. How did they "go bad anytime it's tried"? I don't get it.

Storage is another different subject that can hardly be covered by any single of the aforementioned tags. Of course, you could say storage=produce + produce=timber, but you still need the storage=* tag in between. Anyway, to work this out would be the subject of a separate proposal, as this proposal only intends to introduce the landuse=storage tag, not the subtag values. Strictly speaking, storage=* is not a subkey, as it can also be used for other (i.e. non-landuse) storage facilities such as buildings and cellars. E.g. I use to tag wine cellers with man_made=cellar_entrance + cellar:use=storage + storage=wine. --Fkv (talk) 12:03, 19 June 2020 (UTC)

How do you know I don't oppose those tags? I don't map leafs. So, I have zero opinion on that one. I am against sport=multi though (especially on places where it's clear multiple sports are involved). There's reason not to just use a semicolon value separator for it. Which you could do for storage also. My guess is that with storage there isn't that many places where it's multiple use or if it is there are either to few uses for a semicolon value separator to be a problem or the landuse areas could just be mapped separately. Which isn't possible with something like leave_type. That said, I generally find arguments like "It's OK if this is crappy is because other things are crappy" to be bad ones. The problems with Leave_type/leave_cycle/whatever isn't really relevant to this and their existence doesn't mean you shouldn't make this less ambiguous if you can.

The material key says it's used to "Describes the main material of a physical feature." That's it. So, I'm not really sure what your talking about in reference to it having it's "own purpose." Lumber is a physical feature. So there's zero reason the material tag wouldn't apply to it. Just like the picture for material=metal shows metal slats and the one for metal=brass shows bullets (I'm not to sure who is mapping bullets, but whatever. That's not really the point). Wood is a material.

I meant creating yet another tagging scheme for something, that already has multiple variations in use, always fails and just leads to useless fragmentation. Like you say, there's already 5 and problem more ways to tag that. There's zero reason to reinvent the wheel by creating yet another material tag that can only be used on storage, that only a small fraction of users will probably end up using. There's nothing particularly special about storage that warrants it and the Wiki says in many places that it's better to integrate new tagging schemes with currently existing ones. Otherwise, there could be a specific material tag for pretty much everything. Which wouldn't be helpful.

Have you bothered to think that maybe storage can't be covered by existing tags because it doesn't have to be since it's more a transient status then a landuse usage type or anything else (Kind of intermittent)? That's how I see it. Except in rare cases like storage rental, but that's already covered. As I've said, a lumber yard definitely isn't storage. Let alone should it be tagged that way with a landuse tag. Since it's an industrial area. Same goes most of the other examples your thinking of probably. If you just want to tag that somewhere serves the purpose of storage sometimes, just use the storage key. Just like how intermittent is used without there being a specfic waterway=intermittent tag. Storage already has 2400 uses. Again, it's better to use already existing tags instead of reinventing the wheel and there's zero reason to have a specific landuse tag just for storage. Most people are going to continue using landuse=industrial where it's appropriate and lumber yards needing their own specific tag should be dealt with on it's own.

Like with your cellar example, cellar:use=storage is completely redundant, because we know it's a cellar already from the man_made=cellar_entrance tag and we know it's storage from the storage=wine tag. The only thing cellar:use=storage imparts is the "use" but that's not worth having a separate tag for. No one thinks the cellar isn't being used for storage since you tagged it with storage=wine. Same goes with landuse=storage. Using the extra word "landuse" with storage doesn't ultimately add anything meaningful that don't already get from the storage key and whatever other landuse tag the place would be tagged with instead. Consider retail areas with an area for storage. It's meaningless and redundant to tag a smaller landuse=storage area inside of it. Just map the area separately and tag it with storage=yes or whatever, or add storage=yes to the storage building. Or are you going to tag a building (or cellar) with a landuse tag? What about the landuse around storage tanks? The area around them isn't storage landuse or being used for storage the water tank is being used for storage. That's it. The area it is either commercial or industrial landuse. Are you going to tag the water tank with landuse=storage or map a landuse=storage area inside of a landuse=industrial area? --Adamant1 (talk) 03:26, 20 June 2020 (UTC)

This discussion with you seems to lead nowhere because you are ranting against everything, and nobody knows what your point is. You find tags like sport=multi "crappy" even though they are standard in OSM. You want to merge all keys like surface/material/substance/content/product/produce into one. You hate subtags (A=B + B=C + C=D...) although they are the gold standard in OSM and applications rely on the higher-level tags to be set when they don't need the subtag values, in order to extract and parse as few tags from the database as possible. (E.g. highway=track + tracktype=*, would you omit highway=track because it's implied by tracktype?) Maybe you hate the tag-value concept in the first place and oppose everything that doesn't conform to relational database concepts? Come on, OSM is OSM, take it as it is. An apple is an apple, you won't turn it into a banana.

If you want to discuss a broad range of topics, PLEASE create a section for each topic. This section is titled "Storage rental", and as far as I can see, you haven't written anything here about storage rental (self storage) at all. I think that this would be a perfect example for landuse=storage. --Fkv (talk) 07:52, 20 June 2020 (UTC)

It's weird that on the one hand you tell me that no one knows what my point is, but then you spend multiple sentences saying what my opinions are and telling me where I should discuss things instead of here. I don't see how you can say to start a discussion about something on the storage rental article, or say I'm talking about a banana when this is an apple, while at the same time you don't know what I'm talking about. "shrug." Oh well, It's pretty clear you can't handle feedback and your dealing with it by getting defensive, because I didn't say anything you said I did, but it's exactly what someone who is acting defensive would claim I said. Otherwise, you could have asked for clarification. Instead of going off and twisting around what I said or telling me to discuss things somewhere else. "How dare you tell me what's wrong with my proposal!!! Don't you know OSM is OSM? You just hate everything!!!!" Your the one that brought up other tags in the first place. So, I'm ranting against everything and hate everything by responding to something you brought up? Right. Whatever, dude. Have fun with that. Don't be surprised if your proposal fails since other people will probably bring up the same questions I did. --Adamant1 (talk) 09:12, 20 June 2020 (UTC)

I already tried to get some structure into this discussion with my first reply by cutting your text into pieces and commented on each individual topic separately. But you didn't follow that structure. You mixed everything together in one long text again. In German, we call that a Textbandwurm (tapeworm of text). This is not how discussions work. Create a section for each topic you want to talk about, or I'll assume that you are only interested in ranting and not in working things out and getting OSM ahead. And stop blaming me for diverting from a topic. It were you right from the start who called the section "Storage rental" and at the same time used it to throw in comments about lumber yards, inventory tagging and values for mixed content. --Fkv (talk) 10:09, 20 June 2020 (UTC)

Good for Germans. Really. Last time I checked though, them and their particular ways of talking don't dictate the discussions here. Where I'm from in America we believe in freedom of speech (or at least we use to). If someone isn't 100% precise about how they say something listening to is just part of the cost of them feeling heard, understand, and upholding the freedom of speech standard. Which probably makes Americans (including me) more long winded then we probably would be otherwise. That's the trade off though. That's also where asking for clarification would come in IMO. At least that's how I see it. Anyway, I don't consider using multiple paragraphs, or multiple examples from the proposal, ranting. Since I wasn't angry or impassioned about the discussion. Ultimately I could really care less about your proposal. Except for a passing interest because I spent much of my week mapping U-Haul places and was just thinking there should really be a better/clearer tag for it. It has nothing to do with me hating tags or being angry about anything. I'd just like to see a better way to tag storage and I think storage as a key without the landuse tag would be a good option. That's it. --Adamant1 (talk) 10:59, 20 June 2020 (UTC)

I'm going to create a section for whether storage=* should be used without landuse=storage, so we can focus on storage rental here. By U-Haul places, you mean this? Yes, I suggest to apply the landuse=storage tag on these facilities (at least if they occupy areas of notable size). landuse=industry doesn't seem right, as nothing is produced there, neither does landuse=retail, as no goods are sold there. The best matching landuse tag apart from landuse=storage would certainly be landuse=commercial. For the company (non-physical map feature), a tag like office/amenity/whatever=storage_rental (or =self_storage) could be used, but the only proposal I can remember was rejected --Fkv (talk) 12:07, 20 June 2020 (UTC)

The proposal was rejected for good reason because storage rental isn't really a shop type IMO. Unfortunately it's widely used due to being adopted by iD Editor. I think all of your alternatives, including this one, would be better. Except it's usually a commercial or retail landuse area. --Adamant1 (talk) 01:30, 21 June 2020 (UTC)

storage=* as a main tag?

In the #Storage rental section, Adamant1 suggested to omit the landuse=storage tag and only use storage=*, with storage=yes if no details are known. I see the following drawbacks with such a solution:

1. A new main tag just for storage details will hardly get approved in a normal proposal process, because most people here want to keep the number of main tags low.
2. storage=* would be an attribute for cellars etc., but a main tag for open areas. Some editors and applications might not be able to handle that duality.
3. Main tags usually have no "yes" values.
4. If a land area is used for storage, why not apply a respective landuse tag? That's what the landuse=* key is all about, isn't it?

--Fkv (talk) 12:49, 20 June 2020 (UTC)

Thanks for creating a separate section for it. I wasn't suggesting it be a main tag. More like a key that can be applied to already approved landuse tags. For instance landuse=industrial, landuse=commercial, etc. Or in your example above man_made=cellar_entrance. Otherwise, it can't be used with those things or buildings. --Adamant1 (talk) 13:12, 20 June 2020 (UTC)

So the timber yard in my fist example would be landuse=forestry + storage=timber, the second example would be landuse=farm (or vineyard) + storage=yes, and the U-Haul self-storage sites would be landuse=commercial + storage=self_storage ? --Fkv (talk) 21:05, 20 June 2020 (UTC)

More or less. Except that lumber yards are usually tagged as landuse=industrial. Landuse=forestry isn't really a thing and would be a bad tag for lumber yards IMO anyway if it was. Unless you meant landuse=forest, but I don't think that would work either. Although some lumber yards are in forests. That said, I still think lumber yards should have a unique tag that isn't related to storage because like I said above storage isn't their main thing and it's usually temporary, but whatever. --Adamant1 (talk) 01:33, 21 June 2020 (UTC)

"forestry" was a typo. I meant landuse=forest. As mentioned before, there seems to be a difference between timber yards (unprocessed wood within or near forests) and lumber yards (already processed wood e.g. at a saw mill), although those who work in the forest are called lumberjacks, not timberjacks?!? Anyway, I don't see why temporary storage shouldn't be storage. On the contrary, I already wrote in the rationale that my proposal is ONLY for temporary storage, because permanent storage would be landuse=landfill. Note that the subkey landfill=* (undocumented, yet in use) adds to the wide range of inventory/content keys. --Fkv (talk) 05:41, 21 June 2020 (UTC)

Temporality

Currently the draft states "This is for temporary (short-term or long-term) storage only. For permanent storage, use landuse=landfill instead." This has at least two major problems:

• landfill does not equal "permanent storage". It is not generic enough since it only covers waste products.
• The description of the temporarlity is not only very fuzzy it, determining it is hard to impossible in many cases... we cannot look into the future and often related documentation of future plans (if there are any anyway) are not necessarily accessible. Also, temporarlity is usually of little to no concern for OSM.

Overall I like the idea and proposed syntax. Thanks Fkv. --Stefanct (talk) 23:26, 9 August 2020 (UTC)

Of course we can't foresee the future, and some waste from the past is now exhibited in museums and people pay entry fees to see it. But in practice, it's usually quite obvious what is waste and what is not. Try to come up with a counter-example if you doubt it.

Thinking about it, I realize that I forgot about archives. Things are stored permanently there not to get rid of them (waste), but to preserve them. Located inside buildings and cellars which serve educational etc. purposes (libraries etc.), they need not be considered as storage in landuse tagging. --Fkv (talk) 08:38, 10 August 2020 (UTC)

You are kind of acknowledging the problems since you are distinguishing storage from landfill by its contents/purpose only instead of the time the contents are stored there :) I did not mean that one cannot distinguish the two that way but that the temporal differentiation in the description does not make any sense. I still don't understand what you mean by storage is "temporary", which can apparently be "long-term" but not "permanent" like landfills. Maybe you meant that the contents of storage is retrievable later in an already planned process/fashion instead of recovery/excavation? --Stefanct (talk) 10:23, 10 August 2020 (UTC)