Proposal talk:Industrial tagging scheme complementing man made=works

From OpenStreetMap Wiki
Jump to navigation Jump to search

Comments

I'm delighted to see effort in this area. I'd echo a comment on the mailing list that a different name than "type" would be better -- but I'm not sure what else to call it. :-/ I'll keep an eye on the discussion, and certainly support it once voting opens. JesseFW (talk) 00:41, 27 April 2024 (UTC)

Recurring issues from previous discussions

First of all, works=* already has some uses. *:type=* is a useless suffix with no meaning on its own. It only serves to avoid conflict with the parent, which is not needed here.

One of my concerns with industrial=* , as brought up before, is whether having many different *=*_mill and *=*works is scalable. You also have to decide between *=steel_mill vs *=steelworks , where there had been much more industrial=steelworks at a small scale, at the time before the arbiary promotion of industrial=steel_mill over other "deprecation". https://taghistory.raifer.tech/?#***/industrial/steel_mill&***/industrial/steelworks (I suppose you have been using it for now which is fine, but it was created by another user) Last time I check, "works" seemed be more common than "mill" in British English, when the decline of the industry has been considered. https://books.google.com/ngrams/graph?content=steel+works%2Csteel+mill&year_start=1800&year_end=2019&corpus=en-GB-2019&smoothing=1

It can be seen *=metal_processing requires product=steel to be associated with steel. It is at a higher level than the more specific *=steel_mill . By the same token, it would be unscalable to have *=*_processing for every metal ie *=steel_processing , *=aluminium_processing , etc. This grows into the question of whether product=* should be generic or specific, eg the other 2 options in https://www.naics.com/naics-code-description/?v=2022&code=3312 of pipe & tube, and wires.

Besides, a 3rd option arises for *=metal_processing from the 185+7×2+5+4+2×4+36×1 =252 product=steel_products (There's another more verbose "fabricated steel products" seemingly for the further manufactured product). Personally, I find *=metal_processing not having an obvious meaning to others. There are other possible aspects, eg semi-finished vs finished steel.

While eg industrial=steel_mill may be argued as a simple, unique, identifiable label, I'm not very convinced this is necessary when man_made=works + some variation of steel in product=* is used. Instead of product=steel , the grouping of *=steel_mill and *=metal_processing + product=steel may be achived by eg industry=steel , from the example of the few industry:*_code=* . This frees up product=* for the aforementioned alternative uses. (The industry=* may not need to be exactly the same as the statistics code)

I don't think *=integrated is a "process"? If following power=* , there is generator:plant=* to distinguish generator:plant=intermediate and generator:plant=output . It can be aligned with eg works:stage=* from eg works:stage=raw (placeholder) to works:stage=finishing , with works:stage=integrated used for start-to-end instead of listing everything works:stage=raw;*;finishing using semicolon.

*=sugar_beet and *=sugarcane aren't "processes". It could get eg works:input=* . Treating together with the above, works:process=* could be changed to works:method=* to align with power=* 's *:method=* . This avoids the vagueness of "process" to mean the status in the production. Furthermore, a new works:output=* could be invented to move specific products away from product=* , if it is to remain as an intermediate classification.

—— Kovposch (talk) 08:02, 27 April 2024 (UTC)

First of all, works=* already has some uses. *:type=* is a useless suffix with no meaning on its own.
Somehow, I had missed works=* entirely. I think changing to use that instead is sensible - especially as it's already being used in that way. The *:type=* suffix is definitely not popular!
[comments on using words like "works" and "mill" as part of the description of the industry, and odd problems with ]
After reading your comments, I do now strongly agree with your point that using specific terms like "steel_works" or "steel_mill" to try and define primary steel facilities is not good. It is very common to refer to downstream "metal_processing" plant as a rolling mill or a finishing mill, with the word "steel" implied - and looking at the tagging of some facilities, mappers have commonly applied "steel_mill" / "steelworks" tags to facilities that process steel. The problem of having an explosion of descriptive tags to split these categories does worry me.
It's now clear to me that my thinking involved using works=type to describe both the field of industry and the stage of processing in that industry, and works=process would also overlap with describing stage of processing in that industry as well as type of activity carried out.
It feels more sensible to tag works=steel + works:stage=raw;intermediate;finishing (or works:stage=integrated) + works:method=blast_furnace;basic_oxygen to describe a primary steel facility with some finishing capability, and works=steel + works:stage=finishing (+ works:method=coating to get really specific) to describe a separate downstream steel coating facility. The output coated steel could then go to a works=automotive + works:stage=intermediate for an automotive body stamping plant and then a works=automotive + works:stage=assembly for the construction of cars (would works:stage=* be better as a standardised term, or one that depends on the works=*?). The fact that I can quickly invent tags for various processes suggests it's a good fit.
*=sugar_beet and *=sugarcane aren't "processes". It could get eg works:input=*.
Happy to do that. I was a little wary of adding too many tags, but having few tags which are too complex is looking like a bigger problem.
Furthermore, a new works:output=* could be invented to move specific products away from product=* , if it is to remain as an intermediate classification.
Tempting - I have wondered about tagging more specific outputs, but also don't want to pollute the high level product=*.
I'm then a little unsure how product=* would fit in, if at all. Is works=steel + works:output=flat_steel + product=steel too much redundancy? Perhaps that's just a problem with the terms for that specific industry - works=oil + works:output=petroleum;diesel;fuel_oil + product=petroleum is a little less repetitive.
--Danny252 (talk) 09:45, 27 April 2024 (UTC)
Although the definition of product=* is specifically to describe the output of works=* and similar, so it really should stay, especially given how widespread it is. Maybe having very detailed values in product=* is less of a problem if works=* provides the high-level grouping? product=* is currently trying to describe both field of industry and output of this specific works, and could migrate towards just the latter. --Danny252 (talk) 09:50, 27 April 2024 (UTC)
Choice of what to use for product=* : It's why I thought about using industry=* for the field of industry, and works:output=* for the specific item produced. Keeps a balance between not being too generalized (otherwise you have the same product=steel for both "steel works" and "metal processing"), and not being too specific.
works=steel + product=steel : Indeed, this repetitiveness is why I thought works=steel doesn't add much over man_made=works + product=steel , if product=steel is kept that is. I mentioned product=finished_steel mainly to suggest a possible solution to keep what man_made=works does easily identifiable, although this may still have some overlap if eg works:stage=finished is used for steel industry specifically.
But let's take a look at another metal as well: There are currently 61 aluminium_smelting=* (disclaimer: presumabling created by User:Hiausirg/Key:industrial_overhaul_draft#Metal_Production_and_Processing ), and 4 industrial=aluminium_processing . A few industrial=smeltery , industrial=smelter , and industrial=smelting independent of the metal. So I also thought about going works=smelting (ie alumina to alumionium) for the activity, then there could be works=refining (ie bauxite to alumina) etc. However, I don't know what steelmaking can be said as. Is it still alloying?
—— Kovposch (talk) 09:05, 28 April 2024 (UTC)
For further reference first, I forgot to mention one example: Drinks have to differentiate between production of the concentrate, and bottling to consumers. In your original method, it would be difficult to think of a works=* for the concentrate even if works=bottling is used. (Also: works=bottling_plant ? works=bottling_factory ??? Being descriptive there can generate many disagreements) And then, using using the same product=* for them may be inaccurate, while the use of different product=* needs to be taught to users. Worse, bottling and "canning" are technically different.
The drinks example is a very good one that supports going with industry=* instead of works=* because of the semantics.
For the aluminium example, works=refining and works=smelting both feel to me like tags that are too general to be of much use, and suffer from the "being descriptive" problem. "Refining" in particular feels bad because it has a very strong association with the oil industry, even if it is fair to describe the production of most metals as "refining" in a specific context. For "smelting", grouping by the industry (steel, aluminium, other metals) feels a lot more meaningful than grouping by "smelting". Grouping by a descriptive tag would also suggest the divide between "smelting" (from ore) and "recycling" - both of which result in producing steel or aluminium - is more important than the type of metal involved. In my experience, the use of data would be the opposite - it would be very rare to consider the aluminium and steel industries together in an analysis or discussion, but considering steel produced from ore and from recycled scrap together is very normal. To me, it suggests that being able to group by industry=steel is better for data consumers.
On your query about describing steelmaking as "alloying", I'd say that the production of pig iron from iron ore is smelting, while the production of steel from pig iron is alloying (the process of alloying iron with carbon). However, it's quite unusual to describe it as such - I had to check the Wikipedia article to make sure that alloying as a sensible term! It's also common that the alloying is done at the same location as the smelting. My (poor) understanding is also that the steel+carbon alloying process is much more challenging and complex than many other metal alloying processes, as most others can be created simply by mixing the two alloying components together (the fact I can't even find any information on how aluminium alloys are created suggests it's not complex). Those facts also push me to say that industry=steel vs. industry=aluminium is a more meaningful division, while lower tags like works:stage=* and works:method=* might use the same words but in quite different contexts, as determined by the higher level tag. They can also use different names, as appropriate for each industry, rather than trying to force a specific standard language.
What I then worry about - and has been discussed before - is that industrial=* (for land use) and industry=* (for works) are a very confusing pair, especially to new mappers. Should industrial=* be deprecated or renamed if industry=* works so well - does landuse need to be tagged at that level if better tags exist at the man_made=works / industry=* level? That would be a very big change! --Danny252 (talk) 18:28, 28 April 2024 (UTC)
works=smelting etc: I mentioned it for the case when you want to keep works=* , to make it more meaningful for the activity. It is to facilitate comparison with the other proposal. In the last forum post, one of the needs voiced is to easily characterize them. So on top of man_made=works + some product=*aluminium , it could get works=smelting to maintain the identity of aluminum smelting. From your conclusion, this has to be relegated to works:stage=* . So the question is whether man_made=works + product=* / industry=* is enough to make them recognizable...
works=bottling : It seemed to be a good attribute. This gets backs to the issue of whether works:stage=* should be industry-specific terminology. Or , as you prefer industry-specific, could there still be a need for both that and an industry-neutral classification? Eg works:stage=final / works:stage=packaging + works:process=bottling , adopting works:process=* for the industry-specific step in the production process, and making works:stage=* be industry-neutral. works:process=* could be considered as more detailed and specific than works:stage=* . Eg if someone doesn't know drinks manufacturing culminates in works:process=bottling , works:stage=final / works:stage=packaging can still be added.
industry=* : I imagined it similar to utility=* , so that it could be used on storage and other facilities as well, not only the man_made=works . industrial=* is an attribute of landuse=industrial . They are different aspects of different features. I haven't found industry=* vs industrial=* much more confusing than product=* vs produce=* for grown food.
— Kovposch (talk) 06:36, 29 April 2024 (UTC)
I've put together a long list of examples below that I think cover most of the concepts we've discussed (apologies for the lazy and quite space-intensive formatting). In particular:
industry=* as a way of grouping facilities by the type of product they produce or process
works=* as a general, cross-industry term for grouping similar facilities that work with different products
works:stage=* to describe where in the processing chain a facility falls. This tag is the one I'm least sure on how it should work. I went with generic stages of "raw", "intermediate", and "final", but should "final" mean "an end product that is sold to end users", or "the last stage of this item before it leaves this industry"? E.g. steel sheet is sold by the steel industry to other industries, so it's "final" in that sense, but it's rarely an item a consumer would buy rather than a product made from steel sheet.
works:method=* for an industry-specific term describing what this facility does.
product=* for describing the output as it already does, which can be more detailed now that industry=* groups the facilities
works:input=* for a few cases where it is useful to differentiate facilities (aluminium vs. steel cans, sugarbeet vs. sugarcane).
Do you think this captures most of what we've discussed? --Danny252 (talk) 15:16, 30 April 2024 (UTC)
{{{title}}}
Integrated steel mill

industry=steel
man_made=works
works=smelter
works:stage=raw;intermediate;final
works:method=blast_furnace;basic_oxygen
product=steel_sheet;steel_bar

Electric arc furnace

industry=steel
man_made=works
works=smelter
works:stage=intermediate;final
works:method=electric_arc_furnace
product=steel_bar

Direct Reduced Iron plant

industry=steel
man_made=works
works=ore_processing
works:stage=raw
works:method=direct_reduced_iron
product=iron

Steel rolling mill

industry=steel
man_made=works
works=metal_processing
works:stage=final
works:method=rolling
product=steel_sheet

Steel coating facility

industry=steel
man_made=works
works=metal_processing
works:stage=final
works:method=coating
product=steel_sheet

Car part stamping facility

industry=automotive
man_made=works
works=metal_processing
works:stage=intermediate
works:method=stamping
product=vehicle_parts

Car assembly plant

industry=automotive
man_made=works
works=assembly
works:stage=final
product=cars

Alumina plant

industry=aluminium
man_made=works
works=ore_processing
works:stage=raw
works:method=bayer
product=alumina

Aluminium smelter

industry=aluminium
man_made=works
works=smelter
works:stage=intermediate
works:method=hall_heroult
product=aluminium

Aluminium can production plant

industry=drinks
man_made=works
works=metal_processing
works:stage=intermediate
works:input=aluminium
product=cans

Drinks canning plant

industry=drinks
man_made=works
works=drinks
works:stage=final
product=drinks

Sugarcane refinery (production of white sugar)

industry=sugar
man_made=works
works=food_processing
works:stage=raw;intermediate
works:input=sugar_cane
product=sugar


Sugarcane mill (production of raw sugar that needs refining)

industry=sugar
man_made=works
works=food_processing
works:stage=raw
works:input=sugar_cane
product=raw_sugar

Sugarbeet factory

industry=sugar
man_made=works
works=food_processing
works:stage=raw;intermediate
works:input=sugar_beet
product=sugar

I have hidden them as point form using find & replace in the main page. Please check them in the collapsed box. — Kovposch (talk) 10:14, 2 May 2024 (UTC)

— Kovposch (talk) 11:00, 2 May 2024 (UTC)
Thanks for tidying it up.
Cool, looks like we're mostly just down to discussing the exact wording - which I'm partly putting off as "not this proposal" (too many industries!). The point on the word form for works=* is fair - I can see I jump between the two forms. I'll get on with revising the proposal.
On one specific bit, I avoided works=canning as I came across definitions where it's used solely in reference to food, but searching more widely (e.g. "drinks canning") it does seem to be used in that context too. That sort of thing is partly why I don't want to dig deep into classifying all industries on one proposal; I don't personally know enough to sort out the correct terms for everything! --Danny252 (talk) 12:25, 3 May 2024 (UTC)

industrial=*

This looks like an overall good idea for more detailed industy tagging, but what I don't understand why you would want to use something like "works:type" to replace "industrial". Your "works:type" is essentially the same as how industrial=* is used, was used, and was always intended to be used (see one of the older versions of the wiki page - "type of industry" and the listed facilities make it ovbious that it relates to the type of industrial facilitiy, not something like "industrial land".). "works:type" cannot be used to further describe industrial facilities, such as trucking yards/warehouses/petroleum storage/other logistics/scrapyards, which are not "works"/factories - while "industrial=*" can. And don't forget that industrial=* has already over 260,000 uses, tha majority of which describing exactly what your "Works:type" is supposed to be. You are saying "Industrial activity is sufficiently complex that attempting to use a single tag leads to a very large number of possible values for that tag" - exactly ... not. I created User:Hiausirg/Key:industrial overhaul draft with the idea of creating a reasonable number of defined values, which encompass all type of industrial facility imaginable - I have listed ~120 values, and let me assure you: You are not going to be able to add much more values to that list. (Compare the 120 to the 350 documented "shop=*" or 120 documented "office=*") Every type of work/industrial facility which I came across can be sorted into one of those categories - there is no need for "a very large number of possible values". (And I know what I'm talking about, I came across an awful lot of industrial facilities.) "industrial=* is closely linked to landuse=industrial" - Well, yes and no. It is just as closely linked as man_made=works or "works:type", because industrial facilities or "works" are generally located within industrial areas - obvious, right? As stated above, industrial=* is not a subtag of landuse=industrial - It describes the type of industrial facility, not "industrial land", whatever that's supposed to mean or be useful for. Hiausirg (talk) 08:49, 2 May 2024 (UTC)

Firstly, I'll say that I've just updated the proposal based on earlier feedback, which makes use of a few existing tags instead of using new ones, and also splits out tags for some separate concepts that I was still grouping together in my mind - just letting you know that the change has happened.
While the proposed broad-level tags for industrial=* are a reasonable categorisation, I do think they suffer from several of the problems outlined in this proposal:
* They require deciding when to group together similar facilities/processes that are involved in different industries (e.g. smelters, rolling mills, ...), and when to divide them. Tasks like "find all steel facilities" require searching by a collection of descriptive tags, which does not feel friendly to data consumers.
* They don't allow any differentiation of industries within a single tag, except by introducing a new one. Having a hierarchy of more detailed tags allows for this, while allowing the top-level tags to be slightly simpler.
* There is a strong feeling in the community that industrial landuse and specific works/facilities/factories are different concepts. A single landuse=industrial + industrial=* should be able to cover multiple works, storage facilities, etc., with each of those distinct features being tagged separately as appropriate.
I am partly undecided on whether to split away from industrial=*. I am wary of it, however, because that is such a widely used tag already with so little discipline in its values (I think we both agree on that point!), and redefining it has proved contentious because of concerns around whether it would be describing too many different levels of "thing" on the map. I opted to go with different tags for tagging facilities specifically in the initial proposal, and most of the feedback received has indicated support for moving even further away rather than moving closer to it. --Danny252 (talk) 13:24, 3 May 2024 (UTC)
industrial=* can be reserved as a top-level attribute for facilities not having a feature tag yet, and any other undetermined use. industrial=metal_processing etc are clearly different from industrial=depot , industrial=port , industrial=warehouse , industrial=storage . There's even industrial=oil , industrial=gas , and industrial=timber not describing their activity at all. This is unstructured. They shouldn't be mixed. Separating out what we can to works=* under man_made=works makes it usable.
Danny252 Responding to your points:
- Different industries: Tags that are incredibly broad such as industry=steel or industry=mining are maybe easy for the mapper, but utterly useless for any realistic data consumer. Using these two values as example: What about a factory that produces steel machinery for mining? Now, what industry is this? Every mapper will view this differently.
Having a couple of clearly defined values, such as industrial=sawmill, industrial=chipmill, industrial=wood_processing, industrial=paper_mill, industrial=paper_processing, industrial=paperboard_processing and industrial=printing (+industrial=furniture) are much friendlier to data consumers - those values are documented as being "Wood & Paper Industry": Consumer can query for those 7 values and has the entire, actual wood&paper industry, as well as the direct information on the type of industrial facility. A very reliable result using one simple overpass query.
- Differentiation of industries within a single tag: Probably I'm misunderstanding something, but this sounds like more like you're talking about the proposed works=* instead industrial=*? Looking at the examples, I'm seeing for example works=food_processing works:input=sugar_cane product=sugar for a simple sugar mill. That's !three! different tags for which I would have used one: industrial=sugar_mill Result is the same, except that the example above is much more complex, and horrible for any data consumer and mapper. Specialized information such as weather the input is now sugar cane or sugar beet or whatever, this has much less relevance, and can be expressed using adidional tags - It shouldn't be anything one has to research before being able to tag a simple sugar mill.
To highlight this again: Such a industry tagging scheme needs to be as simple and straightforward as possible, without being too complex such as requiring three tags for simple facilities - but also without being too simple and too general to be useful. As in the sugar cane example above: "food_processing" is horrible as a tag for "type of industrial facility", because it encompasses a very large variety of completely different types of facility, and depending on the mapper, can encompass basically anything thats in some very long way related to food (such as manufacturing of household mixers - they're processing food!).
The proposed solution to this issue is, judging from the examples, a mix of up to four different tags: works:stage, works:method, works:input and product. ?!?
I fully support an ability to be able to tag absolutely every aspect of a industrial facility/factory. But we cannot expect the average mapper to research all such aspects before being able to reliably tag the type of facility. Thats simply ..absurd, and exactly why industrial mapping is basically non-existent within OSM for the past ten years - the lack of a tagging scheme (at all). Introducing an extremely complex one where everyone will have their own ideas on how to tag this and that - that is not going to solve anything.
The average mapper sees: "Hey! There's a factory that produces cabinets and sofas! Let me tag it!" What the mapper is looking for, is a simple industrial=furniture or let's say works=furniture, and not some industry=wood man_made=works works=assembly works:stage=final works:input=lumber;foam;upholstery product=cabinets;sofas monstrosity. Of course there should be a possibility to tag this level of detail, but it should not be required.
- "Industrial landuse": Once again, I have absolutely no clue what "industrial landuse" is supposed to mean in this context. Is this something like industrial=factory? industrial=industrial_park? industrial=zoning:heavy_industry? If you tag something as man_made=works, you obviously imply that this landuse=industrial is used for factories, you don't need a seperate tag. Tagging the type of industrial facility always implies the type of industrial "landuse", but this dosen't work the other way.
Simply tag those "multiple works/storage facilities" individually as works/storage facilities etc.

I fully agree that the current industrial= includes many bad/unclear values, but they are the minority. I see it that way: Either we continue to use industrial and need to cleanup a portion of the current values, or we make a new key for the same concept and need to cleanup all current industrial=*. Thats ultimately much more work. Hiausirg (talk) 19:14, 7 May 2024 (UTC)
You are contradicting your unreasonable example by mentioning product=cabinets;sofas at the end. One part of the discussion above is exactly about how to formulate furniture vs cabinets. The details are obviously not a must, if you haven't realized when you try to be funny. man_made=works + product=furniture / industry=furniture is what's suggested. I mentioned works:output=cabinet;sofa depending on how they should be used. Whether this should be considered wood or furniture industry is an additional problem here. This still doesn't cover flatpacked to-be-assembled vs entire already-assembled furniture.
As I mentioned, industrial=* is mixed with the chaos of top-level attributes, or the thing handled. industrial=oil , industrial=factory , industrial=wellsite, industrial=depot , industrial=gas , industrial=scrap_yard , industrial=port , industrial=warehouse , industrial=well_cluster , and industrial=mine (in descending order) are not a "minority". If you use industrial=* in lieu of works=* , that's a mismatch in what they are referring to. This proposal doesn't seek to solve oil & gas, depots, ports, storage, and mines. works=* clearly specifies this is an attribute of man_made=works showing the type of factory. industrial=* doesn't.
—— Kovposch (talk) 12:40, 8 May 2024 (UTC)
Once again, product=* cannot be used to determine "type of industrial facility/factory". The two are different concepts. industry=*? Some random made-up key that appears to be a unnessescary fork of industrial=* but with only totally random nonsense values? No thanks. So yes, such excessive tagging is a must when using keys like works=assembly. Furniture to be assembled/already assembled? That's nothing I particularly care about, as long as knowing this isn't a basic requirement for tagging a furniture factory.
works=* clearly specifies this is an attribute of man_made=works showing the type of factory. industrial=* doesn't. Why wouldn't it? If industrial=* is combined with man_made=works it shows the type of the factory. (and even if it is combined with landuse=industrial, it still shows the type of the factory to which the landuse refers to).
From your examples which should show what a mess "industrial" is: "wellsite", "depot", "scrapyard", "port", "mine" are indeed "industrial facilities" as defined by the key. So is industrial=factory, although this is way too broad to be useful, and an 1:1 duplicate of man_made=works. "gas" is formally deprecated.
But what about the great works=*? From the ten most used values nine (electric, wood, metal, food, machinery, mnaufacturing, farming, building) are garbage way too general to be meaningful, and "oil_refinery" is a duplicate of industrial=refinery. And this goes on for de facto all other values, at max 1 or 2 useful values per taginfo page. So no, this key is not in any way more clear. Hiausirg (talk) 17:05, 8 May 2024 (UTC)
1. Once again, please read the entire paragraph. You are already using a sense of product=* in industrial=furniture . Please tell us how the ~600 product=furniture mean something different. It is a matter of how product=* should be used, as I reiterated. This is classifying industrial=* by the industry or product.. We are suggesting to start using industry=* as defined here.
2,3,4. Your problem is establishing the type of factory alongside the type of industrial facility. in industrial=* . Our argument is for separating such industrial=* into works=* .
I will conclude you have nothing to say other than sticking to industrial=* . Thanks.
—— Kovposch (talk) 07:46, 9 May 2024 (UTC)
1. I use industrial=furniture, because it is already used 500 times. "furniture_manufacturing" would be better, but okay. But how often should I explain the following? Do you have any actual industry mapping experience? I seriously doubt. Yes, if you use product=furniture, on all "furniture factories" you don't need a seperate industrial/works=furniture. But if you want to map the product more specific, and use something like "product=kitchen_cabinets", you can no longer easily query for "furniture factory" - you would need to maintain an incredibly long list of "product=*" values. (This applies to all types of industrial facilities/factories obviously.)

2,3,4: How exactly is that a problem? "industrial=*"+"man_made=works" for "type of factory", only "industrial=*" for "type of other industrial facility". Hiausirg (talk) 16:35, 12 May 2024 (UTC)
1. Why do you want to resort to questioning others' qualification? I "seriously doubt" the knowledge about industries for someone who didn't consider the difference between concentrate and bottling, if you want to play this game. As I have repeated many times, the use of product=* is a discussion topic here. It is not a decided matter. If people want it to be specific, we suggested industry=* . If it should be general, I also mentioned works:output=* . But a general product=* doesn't work easily in prominent cases viz drinks, as the author agreed above. Sho
2,3,4. Why should this be proposed? I "seriously doubt" your OSM working logic if you don't find this a problem.
—— Kovposch (talk) 03:27, 13 May 2024 (UTC)
1,2. It is intentional for me to advocate for separating manufacturing from storage and other facilities, which are all mixed up in industrial=* . Maybe think of it as sorta industrial=works + works=* . If you rely on industrial=* alone, you can't even interpret whether it is manufacturing unless you have understood everything. This is solved by man_made=works . works=* is a logical, organized, scalable, and consistent attribute to accompany this feature. works=* improves on all the variation in the styling of industrial=* , including not having to argue about how to word the suffix as "works" , "plant" , etc.
3. To give you a sense of the scale in your problem, I have already asked why should industrial=metal_processing not be industrial=steel_processing and industrial=aluminium_processing , etc. Your industrial=nonferrous_mill is misleading, and relies completely on a specific definition to know it excludes aluminum. Your industrial=soft_drinks doesn't distinguish between concentrate and bottling. Furthermore as illustrated here, your industrial=sugar_refinery doesn't handle output of raw sugar alone, relying on knowledge of sugar refining resulting in (white) sugar. Users will simply attempt to use industrial=sugar_refinery for everything making some form of sugar, not confined to refining to (white) sugar properly.
4. What is industrial=* used on? landuse=industrial . If you claim industrial=* is a type of industrial facility, you are still missing the feature tag for that, which industrial=* is not yet, and it conflicts with established man_made=works .
— Kovposch (talk) 14:55, 4 May 2024 (UTC)
I think we're talking past each other. I have never suggested that man_made=works should be deprecated. In fact, the required tagging difference between manufacturing and non-manufacturing industy is that factories have an industrial/works=* for the "type of facility" + the man_made=works for "manufacturing". The difference between industrial= and works= is that the "works" key is currently mapped using industrial=*, and splitting that out creates incredibly much cleanup work (that no one is ever going to do) for no obvious benefit.
Once again, arguing about weather individual values I listed are good or not is not the point of this discussion. I have put up the disclaimer "It is likely that there are still many issues with those values" already long ago.
But anyway, I have used metal_processing, but also steel_mill and aluminium_mill, because the difference between which metal is processed in a given factory is often not easily visible for outsiders (=the average mapper), and often multiple metals are processed. The difference between steel and aluminium mills is not only a much more significant distinction, but also much easier to find out for the average mapper. "nonferrous_mill" as a tag is certainly not perfect, but industrial smelters of any other than those two types are very rare, in my experience. "soft_drinks" issue is a good point that needs to be reflected, I agree that it's a significant difference in terms of "type of facility".
"Users will simply attempt to use industrial=sugar_refinery for everything making some form of sugar" - Yes, that's the point. Excact input/output should be specified using subtags.
"If you claim industrial=* is a type of industrial facility, you are still missing the feature tag for that, which industrial=* is not yet, and it conflicts with established man_made=works ." I don't "claim" that, that is how it is used and was always supposed to be used. In which way does it conflict with man_made=works? man_made=works -> Factory, industrial=* -> type of industrial establishment/factory. The tags compliment each other. Hiausirg (talk) 19:36, 7 May 2024 (UTC)
I was responding to your proclamation of "I have listed ~120 values, and let me assure you: You are not going to be able to add much more values to that list." in how that's flawed. The complementary pair is man_made=works + works=* , not industrial=* which is associated with landuse=industrial . Adopting industrial=* is the horrific mess that "creates incredibly much cleanup work (that no one is ever going to do) for no obvious benefit.". It can be anything including type of facility, type of factory, and the thing handled ; and has every level of detail possible squeezed in it.
—— Kovposch (talk) 12:21, 8 May 2024 (UTC)
Don't twist things: man_made=works + works=* is what is proposed, not what is used currently. industrial=* is not getting "adopted" to anything, it continues to be used how it was intended. And no, with proper documentation it can't be "anything". Hiausirg (talk) 17:05, 8 May 2024 (UTC)
You are twisting my words. works=* is the logical pair of man_made=works . Proposal:Industrial had already intended it to be landuse=industrial + industrial=* . You have to pre-define all the industrial=* that are production facilities, when works=* clearly specifies this. This is not extendable and scalable. Your use of industrial=* is at a level from industrial=oil to industrial=mine .
—— Kovposch (talk) 07:35, 9 May 2024 (UTC)

Ambiguity on "finished"

In the works stage section works:stage=finished is described as "the processing of the intermediate product into a final form that can be sold to other industries or to consumers. E.g. rolling of steel or aluminium into sheet, bottling of drinks, canning of food". I think this is a little ambiguous. For example zinc plated steel sheet rolls might be sold to a company producing e.g. electrical panels (probably another industry in this scheme) or converted into corrugated steel for roofing and siding without necessarily leaving the steel industry. I think the aluminium can example shows how confusing this could be as a can ready to be filled with a drink is almost certainly going to be sold into another industry (food/beverages) and so fits the stated definition of "finished" as it is going to another industry, but is instead listed as "intermediate". --InsertUser (talk) 14:08, 5 May 2024 (UTC)

I agree about it being confusing, but your last example isn't what the page (currently) says -- the bottling example is listed as finished; it's the can-making example that is intermediate. But I agree, the definitions for works:stage=* could use tightening up. Another issue is that raw is based on the inputs, but intermediate and finished are based on the outputs. It might be worth just punting this key to a later proposal. JesseFW (talk) 21:23, 5 May 2024 (UTC)
I meant this example:
Works input is probably aluminium sheet too now that I think about it. Many plants will have multiple inputs so multi-value lists should probably be considered standard on the rare occasion a mapper can actually identify them --InsertUser (talk) 12:44, 7 May 2024 (UTC)
This is overly complex tagging for no benefit, this example is totally sufficient here:
This is a scheme that can be detailed using more specialized tags - those specialized tags should not be required to be able to map anything. (I elaborated on this in the topic above). Hiausirg (talk) 19:43, 7 May 2024 (UTC)
This is off-topic in this section, and you aren't answering the same question. In your case, product=aluminium_cans still doesn't express they are drink cans. Of course one can start with man_made=works + product=cans . You are wrongly targeting the most detailed possibility as "overly complex tagging for no benefit", then comparing unfairly by saying "This is a scheme that can be detailed using more specialized tags".
—— Kovposch (talk) 12:56, 8 May 2024 (UTC)
(Generally responding to overall feeling so far)
works:stage=* is probably the tag I feel least confident and certain about - both in terms of its value to data consumers, and how to actually use it. It seemed more useful at an earlier stage of the proposal, but I think now the other tags mean it's not so useful. I agree with all of the points about the ambiguity, and in retrospect, I found it a little challenging to choose values for the examples.
Does it feel necessary at all? If product=* (and works:input=* as needed) contain more detailed descriptions of what item is being made, and works=* and works:method=* can provide a more detailed description of what is being done, maybe an arbitrary "stage" just has no use. A data consumer might choose to infer the stage as it makes sense to their specific use case, but OSM data doesn't have to do that for them. Happy to drop the tag from the proposal if no one feels it adds much value. --Danny252 (talk) 09:46, 10 May 2024 (UTC)
Yeah, let's drop it from this proposal -- once we have a bunch more industrial facilities tagged, we can see if it makes sense at that point. Thanks again for continuing to push on this! JesseFW (talk) 14:39, 10 May 2024 (UTC)

works:fabricating?

This new key is mentioned in the description of works:input, but isn't explained. Is this an oversight? JesseFW (talk) 21:14, 5 May 2024 (UTC)

Sorry, this was a typo - it should have read works:method=fabricating. --Danny252 (talk) 09:36, 10 May 2024 (UTC)

Proposed values for industry=

While it may be somewhat out of scope for the current proposal, it would be good if we could also propose at least a basic set of values for industry=* and works=*. Since we're starting from a clean slate, we have a chance to get the things right, and not repeat the ATYL mess that is currently industrial=*.

w:Industry classification page has a number of national and international standards. Of those, the most international and appropriate for OSM seems to be UN-sponsored w:International Standard Industrial Classification, of which the Revision 4 (2008) is the most recent. It's 308 pages long, but the Section C Manufacturing (p. 85–165) seems the only one relevant for our case.

Now, we should try to extract a high-level subset from that deep hierarchy and propose some mapper-readable values. For example, class 10 (food products) is probably too broad, but then it has sub-classifications 101 (meat), 102 (seafood), 103 (fruits and vegetable), 105 (dairy), 106 (grain), 1071 (bakery), 1072 (sugar)... which might be useful for us. If you agree, I'd like to prepare an appendix proposal for that. Do we have a proposal for possible values in works=*, which should be relatively small (I envision some 20-40 common values)? Duja (talk) 10:31, 23 May 2024 (UTC)

What you're looking for exists already here. Hiausirg (talk) 16:27, 23 May 2024 (UTC)
Hiausirg: thank you. Would you mind if I edit that section, for possible repurposing in industry=*, or wherever it may be eventually useful. For the first iteration, I would only make insubstantial changes:
  • Remove mentioning of industrial=* in the first column (it's redundant anyway)
  • Remove Bing map links (not something we normally do, and probably not very useful)
  • Add a column with ISIC classification number(s), and perhaps w:NAICS code later on.
? Duja (talk) 12:20, 24 May 2024 (UTC)
Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=Proposal_talk:Industrial_tagging_scheme_complementing_man_made%3Dworks&oldid=2712571"