Proposal talk:Glaciers tags

A few remarks

First of all i think it is a good idea to improve the ways to accurately map glaciers in OSM.Imagico 20:45, 15 December 2012 (UTC)

Hello Christoph, thank you for your comments, some ideas bellow.Ocirne94 22:59, 16 December 2012 (UTC)

glacier:lenght

• length should be unnecessary if the outline of the glacier is mapped since this could be determined from the data.Imagico 20:45, 15 December 2012 (UTC)

I don't know other OSM users, but - even with complex math analysis - I can figure out only a rough estimate of the length, of any ice body: I don't think that anybody could tell me size measurements of Greenland only having a look at OSM data... :)Ocirne94 22:59, 16 December 2012 (UTC)

But I still feel the need/interest for the length parametre, especially for alpine glaciers: it isn't something which a computer could easily derive from the glacier's outline. An example is the Tour glacier, which has been officially measured to be ~4200 metres long: even a smart algorithm would probably have troubles finding the glacier's orientation.Ocirne94 14:14, 18 December 2012 (UTC)

Everybody will argue that there already is a length=* tag; in fact I'm uncertain whether it could well represent a glacier's body length: I feel the length=* is more about linear features (it's used 65,000 times out of 75,000 in combination with a waterway, 2,000 with a railway, according to Taginfo). The main difference is that a linear feature has got a well-defined, crystal-clear length; a wide body, instead, has got an officially measured value, which acknowledges the possibility of other measurements.Ocirne94 14:14, 18 December 2012 (UTC)

Agreed for me to keep this tag, but add a note about : "this is not to duplicate the lenght as computed by a program, but the lenght that you got from another source". sletuffe 14:53, 18 December 2012 (UTC)

And +1 for using length=*, I don't see any problem of confusion, this is an area, any user of the data will know what mean a lenght of an area. sletuffe 14:53, 18 December 2012 (UTC)

glacier:area

• area: should be unnecessary if the outline of the glacier is mapped since this could be determined from the data.Imagico 20:45, 15 December 2012 (UTC)

I can figure out only a very imprecise idea of the area Ocirne94 22:59, 16 December 2012 (UTC)

- concerning the difficulty of calculating values like glacier area from the geometry: i don't think this is a valid argument to store such values in the tags. If there is need to show such values in a map or another visualizations of the OSM data they can be calculated by the program rendering the map. There is also no area tag for lakes for example although this can be quite important (concerning fishing rights etc.). In any case it should not be something specific to glaciers!--Imagico 21:56, 17 December 2012 (UTC)

About glacier:area : This one is really the easier one to compute with math, maybe a note like : "Only use this tag if the area of the glacier's shape is so wrong that it can be calculated" sletuffe 12:40, 18 December 2012 (UTC)

- About geometry-related tags: you're convincing me on the "area" value, it can indeed be machine-computed and it would be cumbersome and of little use.Ocirne94 14:14, 18 December 2012 (UTC)

glacier:gradient / ele_top ele_bottom

• gradient: would be redundant since it can be calculated from ele_top, ele_bottom and length.Imagico 20:45, 15 December 2012 (UTC)

Although here the math is easier ;) , again I think that not everybody can/wants/has time to compute physical parametres from the "raw" data; as a database, OSM might be the right place to collect the available bits of information in an already complete form.Ocirne94 22:59, 16 December 2012 (UTC)

- on second thought the gradient value would make sense (although i would rather call it slope) if there are no elevation values given (and the slope would be something usually much more clearly defined and stable than the end elevations).--Imagico 21:56, 17 December 2012 (UTC)

glacier:volume / thickness

• volume, max_thickness: these are values usually inaccessible to the OSM mapper. So it would only make sense to have these when there are sources for this data that can be used. The world glacier inventory (http://nsidc.org/data/docs/noaa/g01130_glacier_inventory/index.html) for example only specifies a mean thickness (and only has few actual data on this).[User:Imagico|Imagico]] 20:45, 15 December 2012 (UTC)

* volume, max_thickness: I totally agree with you, in fact I think that all these parametres are optional and depend on available sources; those sources and their availability, by the way, are certainly increasing with time. Ocirne94 22:59, 16 December 2012 (UTC)

glacier:average_advancing_speed

• this is neither clearly defined nor very useful i think - unless it is applied to a single point on a glacier.[User:Imagico|Imagico]] 20:45, 15 December 2012 (UTC)

* average_advancing_speed: you're right, it feels somehow clumsy; I was thinking of some three tags like top_, middle_ and mouth_ advancing_speed (of course, without taking ablation into account: it's only the sliding speed of the ice); but I've figured out that it's a parametre which is very rarely known. Ocirne94 22:59, 16 December 2012 (UTC)

debris cover on top of a glacier

• debris_cover: this is usually significantly varying across the glacier - the upper part will hardly ever be covered by debris. I think therefore a separate possibility to map moraines would be better.

* debris_cover: you're right, it does vary across a same glacier; the idea (already in use in many locations: see [1]) would be to split glaciers into more objects, because usually (as you have correctly pointed out, if I have understood) there are some large main areas with a constant (maybe well patchy) feature; an example is the Bionnassay Glacier: [2]. I'm not sure that the moraines mapping would be enough, as distinguishing between rocks that cover some ice and rocks that don't can be of vital importance for hiking.Ocirne94 22:59, 16 December 2012 (UTC)

Now, about debris on the glacier itself, your exemple of the Miage glacier is an interesting example : It isn't completly covered on all it's lenght, near the "col de miage" it is much more white, wich mean it is hard to use only one tag for the whole glacier, and cutting into pieces isn't really good either. I'll suggest that it is best to draw a new surface with natural=scree and propose a tag to describe the "quantity of scree" (A moraine itself could be seen as scree on top of the glacier, or if we don't want to use scree something like natural=moraine + moraine_density=1/2/3) sletuffe 23:38, 16 December 2012 (UTC)

Seems fine, but wouldn't this produce intersecting surfaces, which - according to Osmose - are a bad idea?Ocirne94 19:28, 17 December 2012 (UTC)

For debris the existing Key:surface could be used, this would also allow to map the surface conditions otherwise (snow cover, crevasse areas) but all this would require splitting the glacier. I see no problem in splitting per se. If a glacier is split it would be useful to map the centerline in addition like it is done with rivers to indicate the flow structure of a complex glacier system. For debris having a separate polygon might still be better (or a line in case of thin medial moraines) - of course it should never cross the edge of the glacier (so no intersecting surfaces). --Imagico 21:56, 17 December 2012 (UTC)

About spliting the glacier to record it's surface type when it changes: If we do that, then the length, area, cannot be calculated any more ! That is why I think it is better to add a new surface on top or the allready existing glacier. And yes, that might create errors in some tools, but we shouldn't focus on that, we should find the way to record that in the database in a why it works, not so it pleases QA tools. sletuffe 12:40, 18 December 2012 (UTC)

- About debris: Sletuffe, you're right about the problems of splitting the glacier's area. Two options here:

• 1) Split the glacier anyway, grouping the elements into a relation;
• 2) Use a separate polygon for debris cover.

After what has been said, I'd tend to prefer the second one.

Only one more remark about intersecting surfaces: I agree that we don't map things in order to make happy the QA tools, but I also think that those same tools are there to make mappers mind of good/accepted conventions and codes of conduct [sorry for the clumsy sentence!] Then, of course, those rules and conventions are just waiting to be updated/upgraded/improved.Ocirne94 14:14, 18 December 2012 (UTC)

1) won't be good, if we do that, the relation will not be a valid multipolygon. sletuffe 15:00, 18 December 2012 (UTC)

2) should work, either on top of the glacier, or by creating multipolygons if we want to re-use the edges of both the glacier and it's debirs zones. (just like any polygon) sletuffe 15:00, 18 December 2012 (UTC)

QA tools : I do get what you mean, it is often considered that 2+ natural=* or landuse=* cannot be used to cover the same area. It helps at detecting real errors, and if we start to tag valid ones, that will get confusings. But the facts remains : a morraine on top of a glacier (is that still a morraine ?) is both a morraine and a glacier. We could then use Template:Type to express the fact the glacier is an underground object at this point. sletuffe 15:00, 18 December 2012 (UTC)

The whole subject of splitting is a more general problem so it would deserve a general solution - this is more or less part of what is discussed in The Future of Areas.

Currently mapping of glaciers is strongly varying in regard to splitting: European glaciers are mostly mapped as small areas often sharing edges - only this allows naming different parts of the same continuous ice surface separately. Elsewhere large multipolygons are more common (up to ridiculously large in case of Greenland and Antarctica)

A medial moraine is on top of the glacier so it is still primarily a glacier. Putting another natural=* on top of it would be somewhat ugly. That would be the elegance of using Key:surface since it is specifically meant for secondary characterization of the surface properties. But i agree splitting further than mandated by naming would have its problems as well. --Imagico 22:49, 18 December 2012 (UTC)

I've created a comparison table for the various options:

Method	Pros	Cons
natural=scree	Already existent, widely used tag	Produces invalid intersecting surfaces tagged with natural=* Those intersecting surfaces always cause wrong render in Mapnik A scree is definitely different from a moraine, both in terms of origin and appearance
surface=scree	No invalid intersecting surfaces Represents well the nature of a scree, which often covers another tagged area	Requires a great deal of areas splitting in order to be precise Requires the creation of new areas for those moraines which partly cover the glacier (e.g. lower part of the Mer de Glace and of Brenva Glacier) When mapping lateral and terminal moraines it violates the One feature, one OSM element principle Key surface=* was designed for the surface of linear features, mainly roads and paths
scree=yes or geological=scree	No invalid intersecting surfaces No splitting of areas required	A scree is definitely different from a moraine, both in terms of origin and appearance A scree doesn't seem so important to deserve its own tag namespace, and is usually not a geological site either
glacier:moraine=medial/terminal/lateral	No invalid intersecting surfaces No splitting or duplication of areas required Consistency with the other proposed tags Respects the One feature, one OSM element principle	None?

According to what emerges from the above, I propose the glacier:moraine=medial/terminal/lateral scheme. What do you think? Ocirne94 (talk) 15:33, 21 February 2013 (UTC)

The use of natural=scree seems out of question to me, both are tags indicating the primary land cover and an area can be either natural=glacier or natural=scree - not both. I see no advantage of scree=yes over surface=scree but using a percentage instead of yes/no would provide additional information of course. As for the glacier:moraine concept - this seems to provide very little useful information. In a way every valley glacier has lateral and terminal moraines - there is no objective way to decide if their prominence warrants tagging it this way. It would also be very difficult to display this information in a map.

I would rather suggest a natural=moraine tag - to be used primarily for tagging ways. This could be applied to both moraines on a glacier and moraines on land remaining for example from the ice age as common in many parts of the world. This would be similar to natural=arete and natural=cliff

The question how a continuously changing property like debris cover can be represented in OSM is something not specific to glaciers. A solution for this would be very important in my opinion but would need to be found on a broader scope. Until such is found the solution to draw additional areas above the glacier specifying the surface properties seems the best approach to me. This would probably also be easiest to convert to whatever solution introduced in the future. --Imagico (talk) 18:10, 21 February 2013 (UTC)

Quote: «the solution to draw additional areas above the glacier specifying the surface properties seems the best approach to me.»

That's exactly what I meant to do with glacier:moraine=medial/terminal/lateral! I think we're talking of two different meanings of "moraine": this tag would be designed for the most recent talus accumulation caused by a glacier's movement; I didn't even think of using it for older glacial landforms: this - for consistency - would require to map as "moraine" many formations which are actually located thousands of miles far from present glacial areas (example: during Wurm, the Rhone glacier used to reach Lyon!), and would turn OSM into a geological map. Then, I've thought of glacier:moraine=* because 1. surface=* was designed as additional information for a feature, and 2. it was meant to be used on linear features, mainly roads...

Ocirne94 (talk) 19:18, 21 February 2013 (UTC)

I am not quite sure if i understand - if it is a separate feature to be tagged natural=moraine seems a more logical choice. There is also no need to classify into medial/terminal/lateral then since this derives from the location. And i don't see why the possibility to also tag moraines remaining from former glaciers the same way causes problems.

Maybe the whole subject is a bit complex to be discussed in such an abstract way. It might be better to just try out several variants and discuss them based on practical examples.

--Imagico (talk) 23:38, 21 February 2013 (UTC)

I agree, here are a couple of examples:

• The Grosser Aletschgletscher

http://goo.gl/WP5Nl Start of a very long, thin medial moraine: "ridge of moraine that runs down the center of a valley floor; formed when two glaciers meet and the debris on the edges of the adjacent valley sides join and are carried on top of the enlarged glacier".

http://goo.gl/pIzjJ Lateral moraine: "parallel ridge of debris deposited along the sides of a glacier".

Both objects are:

1. "moraines", according to National Geographic's definition ([3])
2. different from screes
3. noticeable, worth mapping
4. not suitable for natural=* tagging scheme, as they intersect - or even lie on - the glacier.

It's because of cases like this that I have thought of glacier:moraine=*, because it appears to be the only scheme which is generic enough to reflect the various kinds of moraine, while being consistent with the other proposed tags. The problem is also that the lower part of some glaciers is covered with a supraglacier/ground moraine which blends seamlessly with the terminal moraine (http://goo.gl/7cO9x: Bionnassay) and is likely to be best mapped as a single object. Only the glacier:moraine=* scheme seems capable of handling such a situation. On the other hand, many terminal moraines are clearly distict on human view, but may mislead an algorithm (http://goo.gl/RgqEA: Franz Josef). For this reason I think that glacier:moraine=medial/terminal/lateral/supraglacier/ground is the best compromise.

• Vallée du Triége: http://goo.gl/12V7m. There surely was a glacier here during Würm - and even later. And it has left very noticeable traces: the U-shaped valley and very prominent "moraines" (http://goo.gl/cyDhv). But I would not tag the whole valley as a moraine, because trees have now taken over the area and are now the prevailing feature. In other places it can be an artificial lake, a grassland or even a city - but in my opinion the "moraine" is now a minor feature, which is already represented by elevation data/contour lines.

If you understand it as a primary landcover tag i agree, this is not the primary property to tag for such older moraines (although it could well be in case of recently vanished glaciers). If it is understood in a similar way as natural=cliff i think it is valid to put this inside a larger area with natural=wood/landuse=forest or other. --Imagico (talk) 12:19, 22 February 2013 (UTC)

Just for clarity, I have made a retouched version of the Mer de Glace area, featuring all of the tags discussed so far: http://www.filedropper.com/glacierstags. Please note that I have merged the Mer de Glace with the Leschaux and the Tacul to make things simpler, with a single glacier. Ocirne94 (talk) 23:17, 21 February 2013 (UTC)

Good idea but the download does not seem to work for me. --Imagico (talk) 23:43, 21 February 2013 (UTC)

Weird, here it's fine; new link: [4]

All right, this clarifies your concept - in fact this is quite close to what i had in mind for natural=moraine - just with a stronger focus on linear features. I don't think natural=* tags are mutually exclusive - this is well demonstrated by the use of natural=cliff and several others (i saw this differently in December but did not realize the variety of meanings of the natural=* key back then). And since several of the moraines in your example are off the glacier i would say it is clear that a) it would be possible to tag old moraines from glaciers that no more exist the same way and b) using a glacier: prefix is somewhat misleading since this is not always actually part of a glacier.

Or said in other words: Those areas off the glaciers - although they are clearly a natural feature they lack a natural=* peoperty. One could tag them natural=scree of course. This however is a land cover tag and would be conflicting with natural=glaciers in case of overlap. --Imagico (talk) 12:05, 22 February 2013 (UTC)

«glacier: prefix is somewhat misleading since this is not always actually part of a glacier.»

Ok, the original idea came from the fact that a moraine is always originated by a glacier, but I understand that planning to map also more ancient moraines, where the ice is no more present, goes beyond this approach. Thinking again about it, I've remembered the geological=* tag, which at the moment is almost ignored, but could become the solution to all our problems: a moraine is primarily a geological feature and the geological=* tag doesn't make conflict with natural=*. Furthermore, under the geological=* prefix there is already the geological=outcrop tag, which describes "a place where the bedrock or superficial deposits have become locally exposed and are directly accessible to analysis". Now, according to this definition, a moraine feels like a particular case of outcrop, and geological=outcrop + outcrop=moraine (+ moraine=medial/terminal/etc.) could be a good compromise. Ocirne94 (talk) 16:08, 22 February 2013 (UTC)

I think outcrop is something different, it is an afterwards exposure of something that originally has not been exposed this way. So if a moraine is cut into, for example by erosion processes this might be an outcrop but not the moraine as it is. But geological=moraine seems fine, probably better than natural=moraine.

Also have a look at Tag:natural=landform which already includes something for moraines - i see no real need for the landform concept though. --Imagico (talk) 16:54, 22 February 2013 (UTC)

Ok, I think I got the difference, and I am happy with geological=moraine. I would still add the nested moraine=* tag as an option, because it can be very difficult to automatically distinguish between a medial, a lateral and a supraglacial moraine, as these definitions rely on features which may be still not mapped [e.g. http://goo.gl/Q94ts: a medial moraine; but in OSM (http://osm.org/go/Uz9C9hP) there's only one glacial body, so that an algorithm stumbling upon a geological=moraine here may not see the merging of two glaciers and interpret the moraine as supraglacial]. An even more intricated example here: http://goo.gl/Y9hL2. At least two medial moraines are visible, starting from the bottom-left ridge; but in OSM the ridge isn't there (http://osm.org/go/U8gKluc--) so that any moraine drawn there would be interpreted as supraglacial.

I definitely agree: the "landform" concept is too generic ("a way to tag a large area that has certain attributes" ?!), it never appeared within the map features list and it was used only for a small automatic import (incomplete: see also CanVec:_Relief_and_landforms_(FO), many tags were never created); it's likely to disappear through manual refinements. Ocirne94 (talk) 17:34, 22 February 2013 (UTC)

glacier:type

• type: Currently natural=glacier is used for both general land cover mapping as well as for individual glacial features. So there are a lot of glaciers that cannot be assigned any single type because they cover multiple ones. Apart from that i think a few basic types would be sufficient, finer distinctions are often just characterizations of the glacier shape (which is in the geometry), often only apply to a part of a glacier (icefall) or characterize the location of the glacier (tidewater glaciers) which is in the map data.

I total i think a simple glacier=icecap|glacier|shelf|* attribute would be more likely to be used in practical mapping. Could use the WGI PRIMARY_CLASS classification as standard values. --Imagico 20:45, 15 December 2012 (UTC)

• type: I agree, but I think that the current system is a quite well thought scheme: natural=glacier means any area with is covered with ice throughout the year; nothing else can dispute that area: no trees or crops can grow, no highways or buildings can be created on a glacier. That's why I had thought of tags within the "glacier" namespace.Ocirne94 22:59, 16 December 2012 (UTC)

I definitely agree that the world glacier inventory files can be of great help for designing a new tagging scheme for glaciers, and I ultimately believe that we shouldn't limit ourselves to describing general geometry of a glacier, because of the reasons I wrote in the rationale and of the great potential of all the tags and features described on the world glaciers inventory page.Ocirne94 22:59, 16 December 2012 (UTC)

Proposal page layout

I then suggest that the proposal be built with usefullness in mind : One 1st table with only glacier:type and glacier:status (+ listing of all possible values) and then a 2nd table called "additionnal informations" or something like that with tsome "caution" message.sletuffe 23:38, 16 December 2012 (UTC)

Very good idea especially for those tags which describe information that is hard to get. Again, most if not all of these tags are optional.Ocirne94 19:28, 17 December 2012 (UTC)

I have updated the proposal page according to the ideas emerged so far in the discussion. Please notice that the presence of natural=scree is only a placeholder - by the final decision it will surely be modified. Ocirne94 23:28, 31 December 2012 (UTC)

A center line in the glacier ?

but what Christoph has proposed about centerline and the ice flow intrigues me.Ocirne94 14:14, 18 December 2012 (UTC)

Well why not (but how ?), but it doesn't change the good thing about tagging the glacier's surface with a name. sletuffe 15:01, 18 December 2012 (UTC)

My initial idea was that this could allow renderers to show the flow structure but labeling could be placed along the center line as well. Just like with rivers the name could be tagged to both the centerline and the area. I am not sure this is worth the effort though since glaciers in contrast to rivers always have a significant slope so if an elevation model is available the flow structure could also be automatically determined. --Imagico 23:09, 18 December 2012 (UTC)

Interesting idea, after all, most glacier are like rivers... flowing slowly ;-). Why not propose it, those who want will have an oportunity to tag the way the glacier flows. I favor the idea. sletuffe 11:11, 19 December 2012 (UTC)

Forwarding to tagging to gather thoughts

should we forward the discussion to the osm-tagging mailing list, so to collect more editors' thoughts? Ocirne94 23:01, 16 December 2012 (UTC)

A quick note : You are not only two interested in that subject ;-) But I doubt anyone on tagging will be more interested on a 2nd email compared to the 1st you allready sent. Glaciers, mapped to such extend are unlikely to interest more than 5 mappers in the whole OSM ;-). But it doesn't mean we can't do what we can beeing 3, and start tagging anyway. Maybe in the future people will join when more information about glacier gets in ! sletuffe 23:38, 16 December 2012 (UTC)

And thank goodness we aren't with the amount of things to do :)Ocirne94 19:28, 17 December 2012 (UTC)

General statements

- concerning those values not usually accessible to the OSM mapper: if you have such values available for example for a a number of french glaciers i have no objections. Depending on how such values are determined it might also be better to tag a separate node marking the measurement point (especially for thickness and speed).

For others, it should be written that the recorded values shouldn't be the one computed with the shape as it would be duplicate information but for data the mapper got from other source, an additionnal tag such as glacier:lenght:source=National glaciers studying association 2012 would be usefull to express : the currently known lenght is 15km, but the shape is not reflecting that correctly. sletuffe 12:40, 18 December 2012 (UTC)

Back to the topic, I first thought like User:Imagico that lots of your proposed tags seamed redondant to the shape or elevation of points. And that information will be outdated as time pass ("La mer de glace" in France is shortening every year) But as a whole, it is hard to decide which tag should be explicited, wich should be computed by math and if they can or cannot. That's why I think all can be kept as is, people will use them as they it usefull. Most tag will probably not be added at all. sletuffe 23:38, 16 December 2012 (UTC)

More tags proposals

tag	value	notes
ref:wgi_id=*	N	Glacier's id at the World Glacier Inventory
glacier:orientation=*	N/NE/E/SE/etc.	The main orientation. Quite interesting because it affects the amount of received solar radiation. Not easy to compute automatically, especially for small glaciers for which SRTM and ASTER data don't have sufficient resolution.

Ocirne94 23:28, 31 December 2012 (UTC)

ref:wgi_id seems fine, glacier:orientation would be redundant to Key:direction i think. Another possibility would be to tag the node of the lower end (which is often also the start of a river) with some special tag. --Imagico 15:53, 17 January 2013 (UTC)

That's a great idea! I propose glacier=mouth, although I'm not completely happy with using key "glacier" (feels a bit too generic). Ok for deprecating glacier:orientation=*; I'll add these to the proposal. Ocirne94 17:06, 17 January 2013 (UTC)

This is kind of related to the center line idea and i have not really thought it through. The end of glaciers can have various forms and not all of them have a clearly defined end point - see the FRONTAL_CHAR property in WGI for some possibilities. So for characterizing the orientation Key:direction would definitely be better. --Imagico 20:39, 17 January 2013 (UTC)

I get what you mean and I agree; I've added direction=* to the proposal page. Concerning glaciers' mouth, though, I think that it's just like not all glaciers have got a debris cover. Not all glaciers have got a mouth; as you said, not all glaciers have got even a precise end point. So, for those glaciers who do have it, the option of mapping the mouth seems useful, because it's a feature which sets them apart from the other glaciers. I'm thinking of situations like the mouth of the Mer de Glace, of the Franz Josef glacier or of the Langgletscher. The mouth could also be a worthy addition to rendering, just like locks are for waterways and gates for highways. Ocirne94 22:47, 17 January 2013 (UTC)

Bulk import of WGI?

Hey, I've been reading NSIDC and WGI policies and licenses; data reuse is possible with attribution; they even provide download link for the entire database. I think it would be a great addition to OSM, as it would fill most fields (tags) for all the glaciers, and even more (132,890 glaciers in WGI, 15,628 in OSM). What do you think? Ocirne94 23:28, 31 December 2012 (UTC)

Since WGI only contains the locations of the glaciers and no detailed info on the glacier shape it could only be used for supplementing existing mapping. And some of the data there is very old (like 50 years+). I am not sure if there is a reasonable way to automatically import data from there.

In contrast to WGI GLIMS contains outlines of glaciers and in various areas it is better/more complete than OSM (like parts of Alaska, Himalayas). It is however mostly poorly vectorized (the stairstep pixel based kind of vectorization) so it would require quite a bit of processing before an import. There are also areas where OSM data is better. License conditions are not very clearly stated. --Imagico 13:06, 1 January 2013 (UTC)

In fact my idea (as detailed as my brain allowed at 1am :) ) was to import data from the WGI in order to add tags to already mapped glaciers: in detail, useful data from the WGI would be MAX_ELEV, MIN_ELEV, PRIMARY_CLASS (type), TONGUE_ACTIVITY, MEAN_DEPTH (thickness), MAX_LENGTH, ORIENTATION. I agree that many glaciers have got outdated info; but a script could easily take care of checking the date and import only "fresh" data. Indeed, the GLIMS database could be a great addition, although as you pointed out there's no info about reusing the data. Ocirne94 17:36, 1 January 2013 (UTC)

There could be several problems with that:

• Multiple WGI entries on a single glacier area (would be common since many glacier areas in OSM lack splitting between different individual glaciers)
• WGI entries matching the wrong glacier in OSM due to location inaccuracies --Imagico 16:24, 17 January 2013 (UTC)

I've read the same pages and I see NO indication that the WGI data is available under a licence suitable for OSM. Unless clarification is sought I would also be hesitant about adding WGI identifiers too. OSM relies on EC law on database rights we should respect the rights of others who compile databases too. SK53 (talk) 17:00, 1 February 2014 (UTC)

type classification

Here a draft for a type classification scheme, intended to be useful, clearly defined and easy to determine by the mapper. --Imagico 14:30, 1 January 2013 (UTC)

value	definition	notes
icecap	Ice masses, dome shaped, with radial flow, see Wikipedia	Further distinction of ice sheets is only defined by size and therefore not really necessary.
icefield	Ice masses significantly covering underlying topography but contrained by mountains (in contrast to ice caps which lie on top of them), see Wikipedia	Distinction from ice cap is somewhat fuzzy
valley	Valley glaciers are glaciers at the bottom of a single valley flowing downward	Can originate from an ice field or be connected to other valley glaciers
outlet	Outlet glaciers are glaciers draining ice caps or ice fields	Distinction from valley glacier only by originating from an ice cap or ice field (so could be determined from the data)
tidewater	Valley or outlet glaciers reaching the ocean	Like for outlet glaciers easy to determine from the map data (shared nodes with coastline)
mountain	All smaller glaciers that do not fill a whole valley	Could be further distinguished into cirque, niche etc. but less clearly defined
icefall	Valley or mountain glacier with strong slope leading to breakup of the ice	No clear definition, usually only applies to a section of a glacier.
rock	Flowing ice masses not originating from snow usually containing significant amounts of soil/rocks
snow	Perennial snow patches (defined by being stable for more than two years)	Should be clearly distinguished in rendering
shelf	Ice shelves are larger areas of thick, permanent glacier ice floating on the ocean	Could include Ice tongue

Great work, very clear and comprehensive! Only thing, I would add the "remnant" type, to describe those sectors which got isolated from the main glacier's body after a rupture; they are no more fed by snow accumulation or by the glacier's flow, and are sometimes called "dead glaciers". An example is the tongue of the Argentiere glacier, which was separated from the main body in 2005 and is now thinning every year. Ocirne94 17:36, 1 January 2013 (UTC)

remnant seems a good addition - those are usually short lived but can of course be mapped none the less.

And thinking a bit about it i am not sure if having glacier:type=snow would be so good since this would really require to be rendered differently and it is not sure this will happen. A separate natural=snow proposal might be a better solution. On the other hand glacier mapping based on satellite images often includes perennial snow and therefore this distinction is not very strict in OSM anyway. --Imagico 16:11, 17 January 2013 (UTC)

I think it's worth adding hanging to these values for hanging glaciers. I also think you do not need to use glacier:type but just glacier. This is the normal convention for most OSM tags. SK53 (talk)

Some new suggestions

This proposal has been inactive for some time now and in the meantime mapping practice has changed a bit. There are a few things i would suggest to change:

• removing the glacier:type=snow in favor of a separate natural=snow. There is frequent confusion about the boundary between snow and glaciers in mapping but is is important to make this distinction in the primary tag i think.
• with the Antarctica imports use of glacier:edge=calving_line/grounding_line has become established for the outline ways of ice shelf polygons. In case of land based glaciers the same could be used to indicate the different sides of a glacier area using values like 'lateral' or 'terminus'.
• the ADD import also used geological=moraine for moraines as described in Antarctic_Digital_Database/Data#Moraines - more or less in line with the previous state of discussion here i think and subject to the limited information in the source data of course.

--Imagico (talk) 17:44, 11 November 2013 (UTC)

New proposals based on early implementation attempts

Hi, I was reading some publication about glaciers and I think that an important piece of information is missing from the tags in the current proposal: the estimated equilibrium line elevation. It is something which has been studied for most important glaciers, so it should generally be available. What do you think? Ocirne94 (talk) 14:49, 30 January 2014 (UTC)

Hello Ocirne94, the problem about equilibrium line altitude is that it is not verifiable. ELA estimations are usually based on long term observations and are frequently unreliable none the less. What is practically observable in many cases is the difference in the surface of a glacier between the accumulation and ablation area. I think it would be better to map that instead of the theoretical equilibrium line. There usually is no sharp line though.

Another argument is that the equilibrium line is not really a property of the glacier but a climatological characterization of the area (like an isotherm).--Imagico (talk) 17:05, 30 January 2014 (UTC)

Hum... I think I get your point. Indeed it's more a climatological feature, which probably shouldn't go on the map.

But if by "mapping the surface difference between accumulation and ablation area" you mean creating polygons which outline the two, I disagree: the two areas could be mapped only very roughly, would clutter the geometries and would be in many cases biased: they would generally be based only on the snow cover of one year (that of the aerial imagery). If instead you mean tagging the extent (square kilometres) of the two areas, doesn't this suffer from the same problem as equilibrium line (i.e. datum based on long-term observations, difficult to verify, etc.?)

I meant mapping the areas - this would probably only be possible to map on the ground based on thorough local knowledge.--Imagico (talk) 23:39, 31 January 2014 (UTC)

BTW, I've started adding some tags of the proposal to glaciers in the Mont Blanc range, in order to experiment with them and get some on-the-field feedback. And there is one thing which puzzles me: the glacier:type tag. It's often difficult to decide the type of the glacier, so that I'm often tempted to split the glacier's geometry: i.e. the summit of the Mont Blanc, with the Dome du Gouter, is an ice cap/field, but the separation from the ice tongues flowing from it isn't clear. Also there are some icefalls in between. I was thinking of a new approach, made of a relation for each glacier, in order to be able to map the correct areas accordingly. What do you think? Ocirne94 (talk) 17:54, 31 January 2014 (UTC)

In general i think there would be two different approaches for mapping glaciers interconnected in the upper parts: (a) split the upper part from the glacier tongues and tag it separately or (b) split the area according to drainage patterns. The latter is difficult from an aerial image alone of course. In case of Mont Blanc having the upper part as glacier:type=icefield seems appropriate to me but this is a rare exception in the Alps. An icefield according to my interpretation requires a significant thickness of the ice over the whole area. Usually the different valleys/flanks are only connected by thin snow/firn cover in the Alps.

Icefalls seem indeed tricky - splitting the glaciers here will create problems with the labeling. It might be better to use an approach like for debris cover, i.e. a separate polygon indicating the crevassed area.

We probably should move this discussion to the proposal talk page.--Imagico (talk) 23:39, 31 January 2014 (UTC)

I think we need a more general and consistent approach, which covers all the possible glacier's geometries: it doesn't seem fair to divide only the upper zone and the tongues.

This because there can be more complex situations: an example is the Triftgletscher. It starts as an icefield (I don't know the thickness, but looks enough to be one); then it flows NW in the shape of a valley glacier; then it has an abrupt icefall; and finally there is an ice tongue.

Similar to this there is the Khumbu Glacier: first an icefield, where Everest base camp lies, then a valley glacier, the Khumbu Icefall, and finally a terminal tongue.

I'm thinking of a relation:glacier which would solve many of these problems. Of course for smaller, single-type glaciers this would not be necessary.

The relation itself would be tagged with type=glacier and - in general - with name=*, ref:wgi_id=*, glacier:status=*, glacier:ele_top=*, glacier:ele_bottom=*, glacier:volume=*.

Members would be:

• the ice body's sections, with role=body (or role=ice). These would be tagged with a new tag glacier:section={values from glacier:type, and in addition terminal_tongue and crevasse_zone}. And - in case of local known information - with any of the tags above, such as name=Khumbu Icefall, glacier:status=stationary for the top of the Mont Blanc, etc.
• moraines, with role=moraine. These would be tagged with the already decided moraine tags.
• terminus lakes, if any. Role=terminus_lake.
• any more ideas?

What do you think? Ocirne94 (talk) 15:00, 1 February 2014 (UTC)

I do not really see what is gained by introducing this type of relation - it allows you to apply certain tags to a number of glacier polygons together and it allows you to bundle other non-glacier elements with those. But it is not clear to me what such a relation is meant to actually represent. The mapper would need a clear rule when to create such a relation and what to put in it and what not. Also in your concept the use of 'role' seems strange - roles are usually properties an element only has in the relation and not on its own - ice, terminal_tongue and crevasse_zone, moraine and terminus_lake are properties these elements have even without the relation.

The examples you gave (Triftgletscher and Khumbu Glacier) are essentially simple valley glaciers - both with tributary glaciers and both with strongly varying slope along their course. But neither of them is truly connected with other glaciers in the upper part (which is a prerequisite for an icefield) but instead are well separated from other glacier basins by mostly ice free ridges. If you split them along their course you of course have the problem that labels apply to the individual parts and not the glacier as a whole but this problem is not solved by combining them in a relation - the renderer would still have to merge all the individual polygons for a common label.

I am not opposed to using relations here in general but given the complex handling involved there would have to be a clear need that cannot be addressed in a simpler way.

If you want to facilitate labeling and other common attributes of glaciers which you want to split for other reasons i see two other options which are probably clearer and easier to understand for the mapper:

1. create a separate polygon (possibly using existing boundary ways in a multipolygon), give it a separate distinct tag like place=glacier_system and apply the common tags.
2. take an approach similar to waterways, i.e. map the glaciated areas according to the local properties with otherwise arbitrary splits and have separate skeleton ways to map the flow structure and names.

--Imagico (talk) 18:09, 2 February 2014 (UTC)

Well, concerning the use of place=glacier_system, that would be in some way quite similar to the relation:glacier approach. But as you wrote, it would require the creation of a separate (multi-)polygon: wouldn't that be against good practice?

I mean that I don't really see a thing such as a "glacier system". What I consider is a glacial landform - made up of one or more masses of ice, in case e.g. of remnants - together with the surrounding (related) features (mainly moraines and lakes). For this, the relation:glacier approach would be consistent with the current use of OSM relations: see for example relation:associatedStreet or relation:site. Those relations are used to interrelate all the elements pertaining to a certain feature, in our case the glacial landform. Now, for complex glaciated areas with interconnected medial moraines or distant bare-rock moraines it feels more appropriate to group these inside a relation, instead of creating a giant polygon (often tens or even hundreds of square miles big: consider the Aletsch or Baltoro glaciers). A multipolygon relation would also feel inappropriate: how to decide where the landform ends? Grouping together the single elements would be much easier than finding the largest (or optimal) boundaries of the glacier's surroundings.

Moreover, editing/updating the area would sometimes become dreadful, with perimetre polygons: think of a user willing to add a feature to a glacier landform; if the feature is external to the multipolygon, it would be required to split big polygons, remove some members from the multipolygon, add new ones (in the correct order); I think we would be in for huge broken relations and wrong geometries.

Concerning applicability and user guidance, at relation:site there is some definition of when the relation scheme isn't required: It is not necessary or appropriate to use a relation when all the elements contained within the boundary of the site belong to the site, and no elements beyond that boundary do belong. In this simple case simply tag the perimeter with all the appropriate tags. Users of the information can simply perform an 'is-in-polygon' test to determine which elements belong to the site. I believe this suits very well our needs: for larger glacial landforms, where the boundary isn't well-defined, and/or there are many surrounding/interconnected features related to the very glacier body, use the relation; for small glaciers, which haven't impacted significantly on the landform (or their impact just hasn't been mapped), simply use natural=glacier and the glacier tags proposal's tagging.

This because - even with the simplest geometry - in and around glacial landforms there can be elements not pertaining to the landform, such as paths (see the glaciers in Mont Blanc massif or in the Écrins or a bit everywhere), buildings (e.g. the Regina Margherita Hut on the Signalkuppe), or even more complex things (such as the Everest base camping on the Khumbu Glacier). These shouldn't be treated as parts of the glacial landform; and "all the elements around a glacier" can still be retrieved using a distance-based query.

I'm not sure about the use of role - actually in associatedStreet there are "house" and "street" roles - which are definitely something independent from being within a relation. Same for waterway: a "spring" or a "main_stream" exist even if they are not inside a relation.

Finally, I am totally for an approach similar to the waterway relation, but I conceive it within the glacial landform relation: the flow structure - which yes, I have ignored so far - would be traced with new ways belonging to the relation, tagged with glacier=flow_line or similar.

I hope my proposed approach is a bit more clear now. I'm also planning to create a demonstration file with JOSM.Ocirne94 (talk) 21:14, 3 February 2014 (UTC)

Thanks for the explanations but i am not really convinced here. A few points:

• The question what this kind of relation is supposed to represent is still unanswered i think. In (proper use of) relation:site you always have a clear concept of what the site is and can easily decide if for example a building belongs to a school or not. But what exactly is the Khumbu Glacier? The only clear answer to me seems to be the union of all bodies of ice that are part of what is named Khumbu Glacier. But this is in fact a polygon so making it a polygon would be logical i think. Otherwise this would just be a category relation for all bodies of ice named Khumbu Glacier - kind of similar to Relation:waterway which likewise is essentially a category relation for all waterways with a certain name and of very limited practical use.
• If your concept is different from this (which i assume based on your explanations) you would need to say on what basis to decide if a moraine for example belongs to a certain glacier or not. Does a rock outcrop enclosed by a glacier belong in that relation? If a terminal lake is included would you also include a river originating from the glacier and if yes, how far? The concept of Relation:associatedStreet works because every house number clearly belongs to a certain street but not every glacial landform can be clearly attributed to a certain body of ice.
• My criticism of the roles was probably not well understandable. As you described the idea it simply seems to me the roles are redundant and you can have an arbitrary number of elements of any role in any order. I think leaving out the roles would in no way affect the usefulness of the relation and would simplify work for the mapper.

--Imagico (talk) 15:41, 4 February 2014 (UTC)

Hi, thank you for your remarks. I understand I wasn't really clear nor complete about my idea: it wasn't probably completely clear to me either. Here I'll try to make sense and be consistent.

• The relation is meant to represent a periglacial landscape - i.e. the physical and geographical natural features related to a glacier (which no one would deny is a mass of ice).
• The usefulness consists in:

1. Establishing among these features a clear relationship, which models the real connection existing in nature.
2. Providing some effective tools for describing the elements' own features: for example, the flow lines modeled on the waterway relation approach.

• Given this as the goal, I agree there is some convention to reach concerning the features to include. Publications about glacial landforms can be a good starting point. Surely the very ice masses and their moraines find place within the relation; they aren't excessively difficult to determine, since generally vegetation or other features do marks their boundaries.
• For terminus lakes, well, the main issue is probably that they aren't always well defined. I mean: the Geneva lake is the terminal lake of the Rhonegletscher. At least, it used to be. But it wouldn't sound wise to tag it accordingly. Instead, the lake at the terminus of the Bionnassay glacier (and the Mer de Glace, the Triftgletscher, and counting) are clearly and presently belonging to the glacial landscape. I think the decision should be up to the mapper - just like it always is with OSM mapping. About the streams
• About the role, I now understand what you mean and I agree. If the relation members are properly tagged, the role becomes superfluous. I think this affects also other relations currently in use: for example, a multipolygon with a lake (role=outer) and an islet (role=inner). It would often be immediate to handle this automatically, according to the features' geometry. On the relevant page it is stated that roles are optional. So, unless mapping attempts prove it necessary to distinguish between roles, these can be left empty.

Ocirne94 (talk) 21:14, 4 February 2014 (UTC)

OK - i think i better understand your idea now. The main problem i see is that for all features geometrically connected to a glacier (i.e. touching/overlapping it) you do not really need a relation and for many features geometrically separate from a glacier the connection you establish with such relation is doubtful. In case of the lakes you mentioned two extreme cases (directly connected and far apart with clearly no direct relationship at the present day). But in most cases the situation is far less clear cut. Like:

• Argentino Lake - would you put that in a relation with each of the glaciers draining into it?
• Lake Hazen - would you make this a terminal lake of Henrietta Nesmith glacier and possibly others?
• Any of the lakes around Jostedalsbreen - here you have everything from directly connected to many kilometers apart.
• This lake on Novaya Zemlya where several of the glaciers draining into it have additional smaller terminal lakes.

With moraines the situation is the same - you have those directly next to or on the present day glacier which do not require a relation to establish the connection and you have those disconnected from the present day glacier where the relationship is often not so clear since they have been deposited by a glacier in the past that is not identical to the present day glacier you map.

--Imagico (talk) 10:59, 9 February 2014 (UTC)

They are very good and interesting points. These are the things that establish the resiliency of an approach.

So, concerning the lakes I think a rule isn't too difficult to find. Starting from your examples,

• The Argentino Lake - nope, I wouldn't say that the whole lake should be considered a terminal lake. More generally, the fact that a glacier ends in or near a lake in my opinion doesn't necessarily imply that it is its terminal lake. In many if not most cases there is a distinction, for example here: the small lake is the terminal lake of all the surrounding glaciers, and it is separated from the main lake.
• Lake Hazen - nope, it is even outside the recent moraines dug by all those glaciers.
• Jostedalsbreen - nope, there are very long streams connecting the glaciers to the lakes. The lakes are even in other (lower) valleys.
• Novaja Zemlja - the most interesting example. In general nope, big lakes are too far away and not inside recent moraines. But I've found this place, which in my opinion gives a very good insight of the features of a terminal lake. What I mean is that while looking at your examples I've figured out how a terminal lake looks like: it is

1. always smaller than the glacier's tongue (I wasn't able to find a counterexample for this, so I guess it's almost always the case - until contrary evidence)
2. always significantly closer to the glacier than the very glacier's size (generally, at a distance which is comparable to the lake's own size)
3. always inside one of the most recent moraines of the glacier.

Now, these criteria seem to me clear enough for any mapper; they can be more detailed or illustrated, but the concept is straightforward.

About moraines, it's true that they can be associated to the glaciers according to their position, but this leaves room for error, for example for neighbouring glacial tongues. The automatic approach can still be used if one wants to, in the form of a bot which associates the moraines to the relation within the database. But forcing the final user to decide on its own whether a moraine depends on a certain glacier or not doesn't seem to me the good approach. Also because the final users start with the OSM position data only, while the mapper can more easily access aerial photos, elevation data etc. It would be like leaving up to the users to decide the road which a certain address belongs to, this would be easily done from position data. Instead the addr:street=* tag is very important. Furthermore, the road name isn't always known, especially for small hamlets or (really unnamed) mountain roads. See for example the hamlets in the swiss section of the Mont Blanc massif, where many roads don't have a name, but just the name of the locality.

I would like to make one point very clear: the approach which I'm trying to gather here is an attempt to provide a general tool, in order to being able to map all the possible contexts. It is not the default approach which I would use for most glaciers. There are so many glaciers without notable moraines and terminal lakes, with a simple flow structure and geometry. Or in many cases for remote/unknown glaciers the data just doesn't have sufficient resolution to map those features. It's often like this with advanced tagging schemes: in populated areas (OSM-speaking) the database has an amazing level of detail, with very precise tagging and keys which one can't see elsewhere; but those advanced tags/tagging schemes have a low global usage due to the limited contribution level in the other areas. Of course I'm open to any other approach, provided that it allows to bring along the required information in a handy way. The relation just seems to me the data type which best fulfills this purpose...

Finally, in my previous message I had left an unfinished sentence about flow lines. I agree that these could just be stand-alone ways tagged with glacier=flow_line or something alike: the glacier whose flow they describe would of course be the one surrounding them. But I must confess I've never ever met such abstractly tagged ways in a stand-alone setup. In fact, the flow lines don't have an own existence, independent from the glacier. So I believe they are a very good candidate for the relation. Indeed, thinking about it, the most common kind of relation could be the one with the ice body and its flow lines: simple to create and maintain, crystal-clear and very easy to use for final users of the database. Ocirne94 (talk) 21:31, 9 February 2014 (UTC)

Fair enough - your rules for the lakes, while somewhat arbitrary, draw a clear line for the mapper. I still have my doubts about the usefulness of such data but that's of course no reason not to approve it.

Concerning the flow lines - as amply demonstrated by the river mapping scheme this would not require relations. Simply having lines tagged waterway=glacier for the glacier network skeleton would be sufficient. Yes, these do not represent a real feature but it's the same for rivers. There would be no harm to include such flow lines in a relation but there would be no gain either in terms of understanding the flow structure of the glaciers.

--Imagico (talk) 13:59, 10 February 2014 (UTC)

Hmm... I agree on the fact that it would be sufficient: the usefulness of flow lines data subsists only in association with the corresponding ice body, and this can be retrieved with position queries.

I'm just wondering about how to map the flow of a glacier which splits up into two or more arms and then becomes again a single body. This happens (although not often) on steep mountains, where glaciers sometimes fill narrow couloirs (bordered by rocky ridges) and then become again single valley or mountain glaciers. E.g. the Glacier des Bossons. And also sometimes on glacier tongues such as this one in Iceland.

I think this might correspond to the case where a side_stream is used within the waterway tagging approach; and for this the relation:waterway scheme is generally used.

On second thought, I think that such complicated glaciers do usually create notable moraines, which in fact sometimes are the rocky ridges. So there would already be a relation for them, and in this case it may be legitimate. What do you think? Ocirne94 (talk) 16:02, 10 February 2014 (UTC)

Flowline mapping for glaciers

(starting a new section here since this is a separate matter)

The idea is to map the flow structure of complex interconnected glacier systems with skeleton lines quite like the in case of rivers (waterway=river within a natural=water polygon). This could use the waterway=glacier tag for example.

I think like in case of rivers glacier centerlines could be of use without the outlines - as long as they are fully mapped of course. Also note it would be quite normal to have a glacier, especially in case of icefields/icecaps with flow lines belonging to different drainage systems. Like i said before however it could also be argued that the flow structure of glaciers can quite well be derived from elevation data without the efforts of mapping the center lines.

Branching is certainly more common with glaciers than with rivers but in neither case it poses any problems with flowline mapping as long as the directions are correctly mapped.

It might be important to establish some rules what tags to apply to the centerline and which to the area - in case of rivers is it established practice to mainly tag the waterway, especially for names. In case of glaciers this would probably not be such a good idea except in case of large ice sheets where ice streams have distinct names and flowlines while not being well separable in their extent (like Lambert Glacier). --Imagico (talk) 18:22, 10 February 2014 (UTC)

Hi, I don't really like the idea of using elevation data because it combines the errors present in the dataset itself (absurd values such as in the ASTER or interpolated values such as in the SRTM; and in glacier-teeming mountain areas the remotely-sensed elevation datasets are even crappier) with the errors which would be introduced by the flowline-finding algorithm (because the flow lines don't always follow the fastest descent direction, do they?). With this I mean that I wouldn't add machine-computed flowlines to OSM; a user can still apply this method (offline) if he wants to.

I agree that branching doesn't pose geometry problems; the problems come with tagging.

I would prefer to have a clear tagging rule: I'm scared of the prospect that in some cases the tags are applied to the waterway and in some others to the area. At the moment there isn't a way named "Lambert glacier"; there is the relation "Amery Ice Shelf" created by your ADD import, whose boundaries are the grounding and calving lines of the shelf. More ideas to come asap Ocirne94 (talk) 19:11, 3 March 2014 (UTC)

I did not mean to suggest the results of automatic elevation data analysis should be entered as data into OSM - this would be pointless. What i meant is that the basic flow direction could be determined from elevation data in most cases without any further data being in the database. This is a major difference to rivers where the frequently very low slope of the river requires information on the flow direction to be mapped explicitly.

In principle i would consider features like the Lambert Glacier in a similar way as bays and straits in the ocean but it is indeed difficult to draw a clear line between features mappable as distinct polygons with clear boundaries and those to be mapped as nodes/ways inside a larger glacier area. --Imagico (talk) 16:41, 10 March 2014 (UTC)

Ok, now I get it. But as I have mentioned, the freely available elevation datasets appear insufficient to get a precise flow map, for a bunch of reasons.

Near the Poles the only high-resolution dataset (AFAIK) is the ASTER, which is known for having a lot of errors and unwanted peaks; and these would be disruptive for an automated flowline-follower algorithm. Also, polar glaciers can be very flat, so that a computed flow line would inevitably suffer from oscillations and other aberrations. These could be reduced by averaging, splining etc. but it would still be a proble. But the most important point concerns mountain and hanging glaciers: elevation data sets are generally of a very bad quality around the peaks, with heavy void-filling interpolation. I have read what you wrote about accurate void filling with topo maps, but - as shown in your map, there are way more areas which didn't undergo that process. And for small mountain glaciers, which have been sampled for elevation at only two or three places, the resulting flow line can be quite disappoionting. Finally, if the mapped flow-lines have to follow the center line of the glacier, like they do with rivers and riverbeds, then the use of elevation data in my opinion is to be excluded in toto because the center line does not always follow the least-elevation line; especially when a glacier bends on one side for a turn. In the worst cases (e.g. the Unteraargletscher and the Oberaletschgletscher) there can be medial moraines at the very middle of the glacier, so that the center line is actually much higher than the surrounding ice.

About clumsy features: I agree but I believe that in any case the tags should be applied only to the area. It's the very body of ice which has some features, not the flow line. Ocirne94 (talk) 17:57, 10 March 2014 (UTC)

I am not trying to argue here that mapping centerlines is pointless, i am just saying that the incentive of doing so is most likely less than for rivers for the reasons mentioned. The map of voidfill elevation data by the way is way outdated, Jonathan provides global coverage for more than a year now, see [5]. --Imagico (talk) 19:13, 12 March 2014 (UTC)

Oh... I see and agree. I will perform some tries in JOSM in order to see how the mapping model behaves when put into action. Ocirne94 (talk) 19:40, 14 March 2014 (UTC)

Two new values for glacier:type

Hi, I think that the addition of two more values of glacier's type may be useful:

1. On 1th February user SK53 has proposed the value "hanging", and indeed this can generally be determined - extreme slope, broken terminus, no scree moraines. Example: the Weisshorn glacier. I agree there can be a bit of confusion with mountain glacier, but - for glaciers which are obviously hanging - why not use this value?
2. I think there is the need for a tag describing "Eismeers", that is, plateaux and large valleys covered with ice. There are some in the Alps, and more in the other mountain ranges. They can be defined as "[mostly] flat areas, at [relatively] high elevations, totally covered with [generally very thick] ice, without evident signs of ice flow, and giving birth to one or more ice tongues". Because of their flat nature, they often have glaciated cols. Examples: the Vallée Blanche and the Plateau du Trient in the Mont Blanc massif, the Plateau Rosa next to the Breithorn, the Tsanfleuron glacier in Les Diablerets. Plateaux are easy to identify also thanks to their names: they are often called "plateau", "vallée" or similar. In my opinion they deserve to be separated from ice fields because an ice field is "an extensive area of interconnected valley glaciers from which the higher peaks rise as nunataks", so that heavy-sloped glaciers and other mountain glaciers are included. This image from Wikipedia shows the difference: the ice field is considered to be the whole glaciated area. A plateau (or Eismeer) is at a lower level: it could be used to describe a part of an ice field. What do you think? Ocirne94 (talk) 18:44, 10 March 2014 (UTC)

In general i think you can use Any tags you like - no reason to limit this to a fixed set of values. I am not sure what exactly the difference between Eismeer and ice field is supposed to be except for the lack of large elevation differences - An ice field is characterized by the interconnectivity between different ice flows. If the Eismeer does not feature that i would probably consider it the upper part of a mountain or valley glacier. But if you think this warrants an own type that seems fine to me though. --Imagico (talk) 19:48, 12 March 2014 (UTC)

I agree, although setting some values for the most common kinds helps entropy (here synonym of "uniform tagging") - as described at the beginning of Category:Data_standards. From what I see (in glaciers' names) the Eismeer/Plateau definition is used for locally high mountain areas - for the Alps, they start around 3000 m; and usually (always?) there are notable ice bodies below that elevation, generally mountain ice tongues. Many plateaus (such as the Vallée Blanche) are even located completely above the snow line. Ocirne94 (talk) 19:36, 14 March 2014 (UTC)

Use of glacier:type=icefield

"An icefield is an ice mass (of less than 50k km²) significantly covering underlying topography but constrained by mountains". This isn't very clear for mapping purposes, and there appears to be no clear consensus about what is really an icefield. Current interpretations:

1) The flat region of a large ice mass (but not so big that it totally covers mountains as Greenland does).
This excludes from the definition the glacial tongues born from the region: they are outlet glaciers. It also excludes glaciers which are surrounded by mountains: it must be the opposite, that is, the mountains must be surrounded by the ice mass.
An example of an icefield, following this definition: the Northern Patagonian Ice field excluding all valley glaciers starting from it.
The problem: Wikipedia's article about icefields puts as examples ("Ice fields of the world") many ice masses which don't fit this definition; the idea of "icefield" derived from those examples is "any glaciated area". In fact, the Wikipedia article esplicitly states that "There are a several dozen small ice fields in the Alps and tiny remnants of permanent ice in Sweden, the Apennines, the Pyrenees and the Balkans".

2) An extensive area of interconnected valley glaciers.
This includes in the definition the interconnected valley glaciers, but excludes their tongues.
An example of an icefield, following this definition: the Bagley icefield.
The problem: how can we find a clear and universal criterium for deciding the place where an "interconnected valley glacier" becomes an outlet tongue and therefore is no more to be considered as part of the icefield?

3) A glaciated region.
This includes also the ice tongues. It's the definition used by whoever has compiled the examples section of the Icefield article on Wikipedia.
An example using this definition is the whole Aletsch glaciated region, from the Jungfrau-Monch-Fiescherhorn peaks to the snout of the Grosser Aletschgletscher.
The problem: this "icefield" isn't the name of a type of glacier. Its only use would be as a tag on a multipolygon relation containing all the glaciers of a region. Pretty useless.

Ocirne94 (talk) 15:40, 15 March 2014 (UTC)

Surely the term icefield is used in many different meanings. For the purpose of glacier type classification my approach would be: Any continuous glacier body that on a large scale has a non-trivial flow structure and that is not an ice cap. In detail:

• continuous means that there is a continuous body of ice, not just ridges covered by snow and firn.
• large scale means the complex flow structure is on a larger scale, normally at least in the hundred meters range
• non-trivial flow structure means there is a significant amount of branching and confluence, not just separate valley glaciers uniting into a common tongue or a single nunatak within a glacier.
• distinction from ice cap: if it clearly raises above the mountains it is an ice cap.

I would say if you include the outlet glaciers in the icefield or map them separately depends on how fine grained the mapping is.

The above definition would exclude most of the glaciers in the Alps since ridges are rarely ice covered there, the Mont Blanc area is the only fairly clear exception, some borderline cases exist in the Pennine Alps, the Bernese Alps are clearly excluded - the Aletsch Glacier is well separated from all the other drainage basins and has a simple flow structure.

This definition would also be pretty close to the one used in WGI i think.

--Imagico (talk) 14:03, 25 March 2014 (UTC)

Ok; but what if the single ice tongues have got own names? The problem is that the "icefield" definition doesn't seem to rely (only/mostly) on glacier's geometry (such as icecap or hanging do); it relies more on one region's general aspect (e.g. Patagonian/Bagley icefields). If the Mont Blanc is an exception, then it is an icefield? And if yes, how to map that in a way that preserves the finer mapping structure and naming? Ocirne94 (talk) 15:23, 25 March 2014 (UTC)

I see no reason not to split an icefield into smaller parts in more detailed mapping - all elements which are parts of the interconnected glacier area get glacier:type=icefield, the tongues could be tagged glacier:type=outlet. Of course for naming the whole icefield you would need a separate polygon then. --Imagico (talk) 16:43, 26 March 2014 (UTC)

As you know I'm against the creation of a new polygon just for one name. Here I've noticed a strong analogy with the multipolygon usage description: what one could do is create the geometries as you described - one or more for the interconnected things and some for the outlet tongues - and then add the whole to a multipolygon relation with glacier:type=icefield and name=* as tags. The problem would be: what about the icefield's parts which don't have their own name and which aren't outlet glaciers (nor have an own well defined geometry, but are just the interconnected areas)? Should they be tagged only with natural=glacier, with no glacier:type? Or should we look for another value describing this? Ocirne94 (talk) 23:12, 27 March 2014 (UTC)

Well - i think if you want to name both the ice field as a whole and the individual glaciers you have to create separate objects and if you can and want to specify the exact extent of those features they will have to be polygons. If you apply natural=glacier and glacier:type=icefield to the whole icefield polygon you do not need full coverage of the glaciated area by smaller individual glacier polygons so you can leave out the unnamed parts. Of course you would end up with two overlapping polygons both representing glaciers - we discussed this problem before. --Imagico (talk) 11:32, 30 March 2014 (UTC)

Crevasse mapping

Tagging

I recently saw someone mapping crevasses by adding them as inner rings to the glacier multipolygon - see [6]. While this is clearly wrong, the crevasses are part of the glacier and not holes, and it is an obvious case of tagging for the renderer it leaves the question how they should be mapped. I see the following possibilities:

• natural=crevasse - there is a proposal for this Proposed_features/crevasse which is marked approved although it only was discussed and voted as a side note to Proposed_features/ridge. This would have the disadvantage of having two overlapping natural=* features although the crevasse is clearly subordinated to the glacier - you can't have a crevasse outside a glacier. Practically there seems to be little disadvantage is this though and we have other features like natural=cliff which are also limited in compatibility to various area tags.
• surface=crevassed - this is based on the idea that you will hardly map the individual crevasses but the crevassed area in general.
• crevasse=yes or glacier:crevasse=yes
• glacial=crevasse would be analogous to geological=* and could also be used to tag other features of a glacier.

--Imagico (talk) 11:56, 13 July 2014 (UTC)

Wow, this is gorgeous! But yes, it is wrong. So:

• I would exclude the use of surface=crevassed, because the surface key is generally used to describe what the surface is made of - e.g. surface=asphalt or surface=metal. So on a glacier if I used that key it would be for surface=ice, and that would be redundant and pointless.
• The creation of a whole new namespace (crevasse=yes) in my opinion isn't useful (e.g. building=yes should generally be detailed in building=house and so on, but such a specialization doesn't apply to crevasses).
• natural=crevasse - apart from intentionally creating a tagging conflict - for me is misplaced because the natural=* key usually describes primary features (wood, water, glacier, peak), and - as you say - a crevasse isn't on the same logical level as a glacier.
• So glacial=crevasse looks like the best option to me. I definitely agree that the glacial=* key can hold also the other glacial features - as long as they directly pertain the ice body - such as glacial=snout and glacial=bediere.

As a side note, I add that single crevasses aren't often relevant to mapping because they are moving features which follow the glacier's flow and usually get closed in a few months. Also, from satellite imagery one may see some crevasses but miss many others. Instead, crevasses are generally formed always at the same spots, because the features which create them don't move (for example alterations in the bedrock, or the confluence with another glacier). For this reason I suggest the use of a glacial=crevasse_zone tag for marking areas where single crevasses - for some reason - aren't good for individual mapping. There are some very important exceptions, such as rimayes (Bergschrund), which generally hold their position and are easy to spot. Ocirne94 (talk) 14:37, 24 October 2014 (UTC)

I agree that of the mentioned possibilities glacial=crevasse is probably the most consistent. But i am not sure if mapping the general zone in which crevasses occur is practically feasible - this zone has no clearly defined boundaries and crevassing of a glacier often changes quite continuously - difficult to mark a border here. On the other hand if high resolution images are available the actual crevasses are usually well visible and even if the individual locations are quickly changing the overall pattern will show where crevasses occur - even if after some time the individual locations are completely pointless.--Imagico (talk) 13:15, 4 November 2014 (UTC)

Yes, looking at some imagery I think you are right. If you can say that a zone is crevassed, it is because you can (mostly) see the crevasses.

In my opinion it isn't too bad that single crevasses get outdated - that's what all topographic maps have done so far: map single crevasses at a defined timepoint and then update them when new imagery is available. In fact, also the ice body generally needs to be updated when new imagery is available, so this scheme isn't too bad. Crevasses are generally formed in groups, so an individually mapped one will never be more than a few (10?) metres wrong.

But sometimes mapping all the individual crevasses is just too much work, or the big, visible ones are surrounded by several smallish crevasses which aren't easy to follow in the imagery. For those cases I think the area-based approach is the most suitable, although of course every mapping case should ideally tend towards individual mapping. Some map is better than no map. Ocirne94 (talk) 16:35, 4 November 2014 (UTC)

Automated mapping ideas

I've been wondering a bit if one can at least partially predict crevassed zones and icefalls from elevation models applied to the glacier. My ideas are roughly as follows:

• Find the glacier mid-line fallline
• Find any parts of the edges of the glacier (i.e., those which partially follow a fall line, rather then the upper accretion zone and the ablation zone at the snout) which have an excessive curvature
• Find the average steepness over parts of the glacier.
• Areas over a given steepness are likely to be crevasse zones as are those where the curve of the edge of the glacier is over a certain amount.
• If these could be done it might be possible to create generalised techniques for rendering patterns of crevasses in lieu of the actual pattern.

I'll write up these ideas and current status of experimentation some time on my blog. SK53 (talk) 17:14, 24 October 2014 (UTC)

Nice idea indeed, and definitely worth a try, but as for finding crevasses I have some doubts:

• Most OSM glacier outlines are too primitive, many edges are very sharp even if in reality they aren't.
• Many crevasse fields happen even in relatively flat places, because the alterations of the bedrock make the crevasses but don't change too much the overall slope. An example is the first of the two crevasse fields of the Argentiere Glacier (Mont Blanc massif).
• Many steep areas give birth to seracs, not to crevasses. Distinguishing between the two is impossible using a free DEM.

What is most interesting, and which should indeed be implemented by renderers, is the drawing of unknown crevasse patterns with the correct orientation, which indeed requires knowledge about the direction of the glacier. But this could be derived from the corresponding flowline. The problem is, there are many crevasses which aren't perpendicular to the direction of flow. Ocirne94 (talk) 18:35, 24 October 2014 (UTC)

I doubt such approach would be very reliable in its results even if a high resolution elevation model is available. Occurrence of crevasses primarily depends on stresses in the ice and this in turn depends a lot on a number of factors that cannot be directly derived from the elevation model:

• Speed of ice flow
• Friction of the ice on the ground below
• Thickness of the ice

While you could try to make assumptions about those factors based on the data (upstream glacier size, climate etc.) this will get awfully complicated.

A more promising approach could be to detect crevasses from imagery - in particular autumn images after the first snow could be well used for that (uniform surface color due to fresh snow, low sun position leading to well visible crevasses). Sadly of course high resolution images from select time of the year are currently not widely available.--Imagico (talk) 13:15, 4 November 2014 (UTC)