Talk:Approved features/Tag:natural=volcano

• I've been mapping volcanos so far as simply as natural=volcano and adding type=active|dormant|extinct if I am sure I know. Both approaches have their advantages. Mine is simpler and avoids people making guesses (an active volcano to me as an ex-geophysicist may be dormant to a layman). Yours is more precise and allows more adventurous rendering. Any other views? Whichever, I'd certainly like to see these being rendered. MikeCollinson 14:26, 30 October 2007 (UTC)
• That has merit as well. Using the tag without an active/dormant/extinct qualifier could default to....? On the other hand, when does an extinct volcano become a peak/lake? or should it be both at once? Myfanwy 20:36, 4 November 2007 (UTC)

Good questions. I'd default to type=active as that is probably the main reason something gets tagged as natural=volcano. On a general map, I'd render an extinct volcano as a peak (any crater lake would probably be traced in separately anyway) and the information would be there for specialist maps of for any future pop-up description on online maps. MikeCollinson 19:56, 9 November 2007 (UTC)

• I also feel natural=volcano is appropriate and that the condition, if it is known or as it changes, goes under status=active|dormant|extinct. active|dormant|extinct=true|yes would also be appropriate. Blackadder 08:53, 21 November 2007 (UTC)
• We should avoid having too much "top level" tags (e.g. makes it difficult to remember), so having natural=volcano and describe the current state with a second tag might be a good idea. I would also prefer something like active=yes to tag the state. I don't think a default value makes a lot of sense, so not tagging the state means "I don't know". Will this tag only apply to nodes (like the peak one does) or do we need to tag also areas that way? Will it replace the peak tag for a volcano (in this case, we need those additional tags like elevation)? -- Ulfl 09:09, 21 November 2007 (UTC)

• yes to all ulf's points. one thing that has occurred to me: a volcano is not necessasarily a peak. lake pupuke in auckland has a crater rim that is level with the surrounding land - i.e. a volcano can also be a peak, or not. so, the elevation need not be added to volcano. i don't think the area tag is needed - if it is worthy of being an area, then it will also be something else (e.g. a lake), tagging an area with two types sounds like we're asking for trouble Myfanwy 10:14, 21 November 2007 (UTC)

• to mikecollinson: is there any more info we need to add? are there types of volcano? Myfanwy 10:14, 21 November 2007 (UTC)

The main classifications are its activity (active|dormant|extinct) and the geological type (stratovolcano|scoria cone|shield volcano) - on the surface, this basically controls its shape - I found a good summary at http://www.geology.sdsu.edu/how_volcanoes_work/Volcano_types.html . If any anyone gets seriously into locally mapping volcanos, we might want something to mark geysers, fumaroles and craters. Me, I'll be happy with natural=volcano! I think it is a good guiding principle, as Ulfl suggests, to have an easy-use-basic tag and then other tags for specialists and devotees. MikeCollinson 20:28, 21 November 2007 (UTC)

great! i'll add those in as optional extra tags then. can't have too much info... Myfanwy 20:35, 21 November 2007 (UTC)

in retrospect, should we scrap the whole volcano tag, and introduce something called 'geothermal site'? with sub-sets of 'volcano', and i'm guessing here, but things like 'geyser', 'mud pools' (technical name?), 'fumaroles', etc? and then have sub-types to define shape, activity, etc.? what do you think, too complicated, should they all have their own tags Myfanwy 20:49, 21 November 2007 (UTC)

I suggest that the basic volcano tag should be left in place as it is a very important general feature. But I think you very definitely have something. Let's open up a separate proposal for a geology=tag ? That would cover the interesting fun things like geology=geyser but also opens up a whole new field of OSM mapping as nodes, ways and areas. There are thousands of interesting rock features if you just know where to look: faults, synclines, rock outcrops of a particular type ... Oh, and we could still use geology=volcano in conjunction with the type tags proposed. MikeCollinson 12:57, 26 November 2007 (UTC)

I think the status and type tags should be namespaced. volcano:status and volcano:type. Otherwise those tags are far too generic. --Hawke 09:52, 15 December 2007 (UTC)

is that necessarily a problem? what potential issues do you see if we use generic keys? Myfanwy 19:46, 17 December 2007 (UTC)

it means that only one key gets to use the "type" and "status" tags. For example, what if there's a key "peak" or a key "mountain" which also has a type and status? They would conflict. --Hawke 13:07, 21 December 2007 (UTC)

that's true, they may have the same key but that does not necessarily mean they would conflict. if i wanted to select only volcanoes which are dormant, i can use the 'volcano' tag to select all volcanoes, then i would use a filter to select those of status 'dormant' within that selection set. yes, a user could select everything with a 'type' tag, but that would be not really useful (as far as i can see), even if the tag were used for just one class of element. your point seems to have hypothetical benefit, but nothing i can see that would be useful in a practical sense. can you describe an actual situation where this has/may cause some issues? the downside to your suggestion is that key names become ever more complicated and long. if this is a worthy idea, IMO it needs a well-laid out piece on a dedicated page, explaining it's pros and cons, as it affects a huge number of items, including highways ('ref' tag). i will be glad to join the discussion there and vote to modify keys as necessary if your idea becomes common practice.Myfanwy 05:20, 27 December 2007 (UTC)

I don't have any in-use examples (except for the 'ref' tag which you mentioned...and its problems aren't at all the same as this). As I said, I could envision a 'peak' or a 'mountain' having a type or status tag which would conflict with that of a volcano. I mostly just think it would be wise to be careful about using extremely generic tags. (And IMO, knowing that everything beginning "volcano:" has to do with a volcano rather than having to examine another tag to see what this 'type' tag means is a worthwhile benefit as well) --Hawke 23:45, 31 December 2007 (UTC)

When looking at wikipedia I see an attibute "Last Eruption" which could be used to indicate activity of a volcano (last_eruption:1880). When would you say an volcano is active? --katpatuka 11:50, 29 July 2008 (UTC)

Volcano big-small

Is there a way to specify what type or size the volcano is? I am thinking of the difference between volcanos that have built major mountains and such that are not as large and may be part of a field like to the northwest of the Vesuv or as a assembly of vents and cinder cones that would clutter the map if rendered at every scale yet may be prominent features when hiking. --T.woelk 09:31, 26 September 2009 (UTC)

Underwater volcanoes?

How should underwater volcanoes be tagged? Just out of curiosity :) --Skippern 16:34, 30 October 2010 (BST)

A long time answering, but I have just started tagging them and use exactly the same tagging. Same goes for sub-glacial. MikeCollinson (talk) 06:30, 26 April 2013 (UTC)

"Used on these elements"

If "Add the natural=volcano as a node" is correct, then the types listed under "Used on these elements" is incorrect, i.e., only onNode should be selected. -- Simon04 18:52, 4 August 2011 (BST)

This clearly is a bug/typo (take a look at taginfo). I fixed it. --Tyr (talk) 12:11, 5 February 2013 (UTC)

Crater rim?

DE:How to map a also has natural=crater.. I don't see any examples but think it would be be a good way to mark the extent of the caldera? Other real life volcano calderas are tagged with natural cliff which is fine in some case but in sometimes there are no real cliffs. RicoZ (talk) 23:15, 24 February 2014 (UTC)

I've started a doc for natural=crater, however I don't know if that's the best tag for this. Mrwojo (talk) 00:18, 24 August 2015 (UTC)

There is now also Proposed_features/Volcanic_features. The fact that some craters are represented by unclosed ways results partly from the fact that mapnik did not render closed natural=cliff ways and partly that a section of the crater rim is simply missing.

natural=crater has one huge problem - as far as I remember the great majority of those are actually bomb detonation craters in the Arozina/Nevada deserts. The tag should be discouraged because it was never properly documented and usage is a mess. RicoZ (talk) 16:18, 28 August 2015 (UTC)

Usage didn't look that messy to me. Craters are not limited to volcanos. Mrwojo (talk) 01:51, 29 August 2015 (UTC)

Initially I also wanted to use natural=crater but reviewing the usage about one year ago I left it - it seemed impossible to produce meaningful documentation reflecting the usage back then.

Also note that the Pico Viejo ( Pico Viejo Pico Viejo ) that you included as example in the crater page was actually mapped as natural=cliff and last I looked most volcanoes were probably tagged this way - unfortunately this is not easy to check other than by looking at single volcanoes.

Given that craters have many appearances I believe the best approach would be to map the appearance (cliff, ridge) with some secondary tag or relation to indicate that it belongs to either a volcano, bomb crater or something else. RicoZ (talk) 10:11, 29 August 2015 (UTC)

That Pico Viejo relation is mapped natural=crater. Again, these are separate concepts. The rim of a crater isn't necessarily a cliff. A circular cliff/ridge isn't necessarily a crater. Mrwojo (talk) 14:42, 29 August 2015 (UTC)

Sorry, didn't pay attention to the detail that is tagged assnatural=crater+natural=cliff. Also I think this is hackish at best, one object should not have two natural=* values at the same time combined in this way.

I understand the difference in concepts. The proposal that has been around since last year suggests tagging volcanic crater rims with geological=volcanic_caldera_rim if it is a volcanic crater, this can be combined with cliff, ridge or be left alone in parts where neither is visible.

For meteor and bomb craters something else is needed. Maybe geological=meteor_crater would work, not sure about bomb craters.

For more elaborate volcano mapping I am inclined to propose a relation to allow the specification of more than one vents and group all elements together. RicoZ (talk) 10:41, 30 August 2015 (UTC)

Using relations to tie together volcanic features sounds reasonable.

To me, the bigger bombshell (sorry) in this discussion is the claim that natural=crater shouldn't be documented or used for any purpose. Ideally, mappers should be specific about crater types just like they should be specific about natural=water types. That doesn't make crater or water wrong on its own.

I don't think it's hackish to include a natural=* way in a natural=* multipolygon, like reusing natural=coastline as part of a natural=beach. Mrwojo (talk) 17:10, 30 August 2015 (UTC)

It is hackish. with natural=coastline+natural=beach you have two truly separate objects which only share an osm-way for technical reasons. You could also map them (and I often do) with separate ways and the result would be the same and equally correct. With natural=cliff;crater you have one object with two separate natural values. I believe something like this would never get approved.

You could use crater if you find a use for it but it won't serve you well. It will never be rendered in any way and when searching for volcano craters it does not help to sift through ~360 bomb craters in the desert of Nevada, the same if you are searching for bomb or meteor craters - you will find all the stuff that you don't search.

Which objects would you like to use it for?

• volcano crater: the proposal to use natural=cliff+geological=* is better and would have no trouble getting approved. Introducing an additional possibility does not help. I haven't sent this proposal through a formal RFC and voting yet because there are other areas which need some more thoughts - lava flows/channels/rivers need the possibility to map the flow direction etc and hot springs needs to be decided either way.
• meteor crater: you want to have rendered the cliffs etc, it is easier and more useful if you use natural=cliff + some meteor crater specific tag. Perhaps geological=meteor_crater would serve you for this purpose?
• bomb impact crater: natural=crater doesn't seem like the ideal way to do that, neither geological. Maybe the "historic=bomb_crater"?

I believe the best way to proceed would be to document specific tagging rules for the distinct crater types and deprecate "natural=crater" so that people get alerted to update their craters. RicoZ (talk) 10:53, 31 August 2015 (UTC)

Would it have the same meaning with natural=cliff on the multipolygon and natural=crater on the members?

The wiki should be more careful about eliminating description in favor of prescription. Speculating about whether natural=crater will be approved or rendered doesn't change the fact that craters have been mapped, that it's a meaningful concept, and can be documented. There's solutions in actual use that detail craters with natural=crater (e.g. natural=crater + crater=* which could also be a property of another natural=* ; crater as a relation with roles for the rim, peak, ejecta). Mrwojo (talk) 17:21, 31 August 2015 (UTC)

natural=cliff+natural=crater: I do not think that it is supported to combine natural tags/values by inheriting them from relations this way. Most data consumers will probably drop ("override") the one or the other value. This is a case where an object should really have two values which would be written as "natural=crater;volcano". Wiki says the use of multiple values is supported for certain cases (conditional restrictions, addresses) . No idea if it is supported for natural tags but overall it is advised to avoid this where possible. Google for "OSM relation inherit tags" and look at http://blog.jochentopf.com/2013-09-23-semicolons-in-osm-tags.html and Semi-colon value separator.

The problem with the wiki is that every time you document a tag/value it will show up in taginfo as "documented" and people don't go on to read the documentation. If one tag/value has 3 documented meanings and for example crater for volcano craters is deprecated taginfo can not adequately reflect this. It is even worse, taginfo will display even keys with deprecated status and pages with a "delete" template as "documented", misleading people quite frequently. I have filed bugs against taginfo but the author of it says it would be too complicated to improve this.

The natural=crater+crater=* idea is quite nice but still won't fix the other problems: a single object should not have more than one natural tag values, past usage is inconsistent and some of the craters are not natural.

Also keep on mind that some things that work well with popular objects (like natural=water+water=river) require considerable development effort to actually implement and will never be implemented for rare tags. highway=construction+construction=primary works, building=construction + construction=school does not work as expected and the mapnik developers say they won't support new special cases like this. Maybe mapnik support does not matter for natural=crater but it is an indication that it may cause complications elsewhere. RicoZ (talk) 11:17, 1 September 2015 (UTC)

(outdent for readability)
There's no inheritance on that multipolygon. Do you see the point of my question about flipping the tags on a multipolygon? The crater is polygonal, whereas the cliffs are linear.

• single object should not have more than one natural tag values: how is that a problem for crater=* but not geological=*?
• past usage is inconsistent: can you be more specific, like with examples? I looked at a lot examples and saw craters from volcanos, meteorites, and bombs. Other crater types can be handled with one key, crater=*. Non-craters would need fixing regardless of this discussion.
• some of the craters are not natural: natural=* isn't always for naturally created features, see water=*

This discussion has been too long and has too many tangents. natural=crater means a crater, and if the wiki cannot represent that then it's a problem with the wiki. Mrwojo (talk) 15:57, 1 September 2015 (UTC)

it doesn't matter at all whether the crater is polygonal and cliff linear. Most tools have assumptions about tag inheritance on OSM relations and this will not do what you think it does. There is also no reason why a crater should be a multipolygon and apparently only a small fraction of existing natural=crater are.

It is not that I have a fascist predilection against natural=crater but we need something better. Have a look at the history and discussion of natural=lava. It was not such a bad tag after all but people shot it down.

We don't seem to get any further with this discussion so I would suggest to ask for more opinions in osm-talk. RicoZ (talk) 09:52, 2 September 2015 (UTC)

Btw I found an old discussion about natural=crater and lava fields in a German mailing list, "[Talk-de] Vulkane und natural=crater". Some opinions were that natural=crater could denote either the center of the crater (node) or the area of the crater but other tags like ridge,cliff or crater_rim were suggested for the crater rim. RicoZ (talk) 11:04, 2 September 2015 (UTC)

The difference between polygon and line does matter, as documented on Tag:natural=cliff (synonym for bare_rock).

I know you want it to be better. Better doesn't necessarily exclude natural=crater. Mapping around the terrain rise is another reasonable approach. Mrwojo (talk) 16:06, 2 September 2015 (UTC)

The multipolygon natural=cliff explanation in that proposal is marked obsolete - and given that perhaps 249 objects use it I would be very surprised if anyone would actually implement it. Applying this rule to the Pico Viejo example (http://www.openstreetmap.org/relation/2059371 ) would mean that the cliffs won't be drawn at all but the whole area is interpreted and rendered as bare_rock instead which was certainly not the intention of Javier when he mapped it this way.

However this has nothing to do with the fact that placing natural=volcano on a multipolygon and natural=cliff on its member is subject to relation inheritance rules where most likely one of the values will override the other. From my own experience with waterways inheriting tags from relations to members and the other way around in OSM leads to unexpected results quite often.

You could define a relation type=crater+natural=crater/volcano/meteor_crater with members crater_rim,natural=cliff/ridge/arrete} and that would work. However a multipolygon is a special type of relation where you are not expected to do this and if you do it will cause problems somewhere.

Defining a volcano/crater relation is something I would support.

I did find the old discussion which you may perhaps grasp with the help of google translate http://markmail.org/message/i3tnevpin5dppf4b. It was in fact me who started the discussion and wanted to document things. After the discussion I concluded that natural=crater is not what I want and started the discussion at natural=lava which lead to the current proposal.

natural=crater might be documented as either of the center or area of craters - assuming that the pre-existing usage is compatible with this documentation. Using it for crater rims won't work even though teose are seemingly very similar and related. RicoZ (talk) 11:32, 3 September 2015 (UTC)

natural=crater has presumably been mapped along the rim for practical reasons (a crisp, obvious feature). 95% of all natural=crater are either nodes or areas. There's no way-chaining to suggest mappers meant only the rim. Mrwojo (talk) 14:37, 3 September 2015 (UTC)

You are right, there is no way we could second guess what mappers wanted to map when they mapped natural=crater before it was documented other than asking them. Which makes it pretty hard to write meaningful documentation. If there are only a few mappers who mapped the majority of these object it might be worth to ask them. The crater as area/center of crater is the only meaningful idea of documentation that I see for this entity. RicoZ (talk) 15:24, 3 September 2015 (UTC)

I have rewritten the documentation. RicoZ (talk) 10:19, 5 September 2015 (UTC)

Sinkhole has the same problem when natural=sinkhole+natural=cliff should apply: Talk:Tag:natural=sinkhole RicoZ (talk) 10:25, 5 September 2015 (UTC)

Same namespace for related features

A mix with "historic" or "geological" only creates confusion. Also see Category:Crater

◆ Taglist ... 

LOADING TAG LIST...