Talk:Key:cutting

Has this been proposed? If so, please link to the relevant sites. If not, it should. Additionally, a hint how to tag and an example wouldn't be that bad. -- Malenki 23:54, 28 August 2009 (UTC)

No, it shouldn't. It was in the very first version of Map Features and is in widespread use. I'll add something about the how to tag. Alv 08:32, 30 August 2009 (UTC)

cutting on one side

I often find cuttings on one side of a railway=* or highway=* sometimes even with an embankment on the other. I propose to use embankment=both/left/right/none and cutting=both/left/right/none.--Skyper 12:02, 10 November 2009 (UTC)

I like your proposal. I suggest you make on official proposal of it. --Kslotte 14:50, 17 February 2010 (UTC)

It is at Proposed features/right left. --MattGPS 20:37, 14 October 2010 (BST)

You could also use barrier=retaining_wall that is also used for cliffs AFAIK, for single sided embarkments.

Doesnt it make more sense to make it analog to embankment with a man_made=cutting line on either side? Flohoff (talk) 10:19, 16 May 2018 (UTC)

further usage

Is it common to use this tag also for streams or canals that are cut into, and thus lower than, the surrounding area? Recently, I met a ditch, shaped like a key stone. The water bed itself was 3 meters lower than the area, and while the water bed measured only 1m accross, the shoulders of this ditch were 4 meters apart. Is this a case for a cutting tag? Cheers. --RalfG (talk) 19:33, 22 January 2014 (UTC)

Wikidata

Why is there a Wikidata link in the keys description? Flohoff (talk) 10:15, 16 May 2018 (UTC)

Wikidata provides additional info and subclassification details in various standards. It helps describing features, allows joining OSM features using these tags with items in Wikidata which are classified with them. This allows cross checking the list of features, and detecting equivalent or poor tags in the current OSM ontology, or conflicts of interpretation. It is a great help to consolidate OSM data and finding other relevant OSM tags because the links are bidirectional too (from Wikidata classes to OSM tags), and also helps finding exceptions to our "common" knowledge. Both Wikimedia and OSM cooperate to exchange data (note: Wikidata is CC0 and is fully compatible with OSM data; this is not the case of Wikipedia whose data under CC-BY-SA cannot be reused in OSM, unless the Wikipedia authors and Wikipedia community accept to first publish or transfert the Wikipedia data to Wikidata).

We don't necessarily need to import data of Wikidata in OSM, as we can now just link the items. Wikidata IDs are also stable (not the case of OSM data, and even OSM tags which are continuously changing with various experimentations. OSM however provides interesting datasets that can also be used to help creating and maintaining the Wikidata ontology. So both projects cooperate and there are quality tools that compare the two datasets (including for the detection of spam/fake data in OSM, or knowing that something has changed somewhere and needs update).

We don't need to insert all the data triplets from Wikidata into OSM tags or in their description, we just need to define how the two datasets can be correlated. A single Wikidata link in keys/tags description pages summarizes many properties that we don't need to explicit more on this wiki. In fact it could also replace the wikipedia links, but Wikidata is still too technical for most users and Wikipedia is more descriptive and contains many things that Wikdiata currently does not encode in its ontology.

So think about this as part of the large cooperation projects between OSM and Wikimedia. — Verdy_p ^(talk) 21:48, 26 May 2018 (UTC)

Is the combination with another highway/railway/waterway required?

Was wondering about more complex cases, such as a wide cutting where some features are next to a road or water channel. In such cases it might be better to map a an extra way cutting=left|right ? RicoZ (talk) 17:15, 1 November 2019 (UTC)

Perhaps I am misunderstanding the example, but if you are talking about a wide cutting where the edge of the embankment/cutting is not right next to the road or canal, then this can be mapped by using man_made=embankment at the top of the slope. --Jeisenbe (talk) 23:44, 1 November 2019 (UTC)

This would be indeed a possible workaround although for a purist a cutting and an embankment is a huge difference. Is that workaround needed? Is there any important reason (other than OSM tradition) that there should not be a way tagged merely with "cutting=yes|left|right"? Looking at the logic with embankment and man_made=embankment it seems like man_made=cutting should be created for this purpose? There are 126 uses of that. RicoZ (talk) 18:59, 2 November 2019 (UTC)

Re: > "for a purist a cutting and an embankment is a huge difference" - Is there simple way for mapper to distinguish between a man-made embankmant and a man-made cutting? I can imagine saying "he slipped and rolled down the embankment" if someone fell off the edge of one of these, but not "He fell down the cutting" - but then again, we hardly use the word "cutting" in American English. I'm inclinded to say that most mappers won't be able to clearly distinguish between an embankment and a cutting: they are both artificial slopes, and one needs to know the original lines of the terrain to tell the difference. Furthermore, it's already common to use man_made=embankment for slopes in quarries and mines. --Jeisenbe (talk) 23:49, 2 November 2019 (UTC)

You can probably construct ambiguous example buts I think the difference between and is clear. Some of hte embankments in mines and quarries may be real embankments but if not man_made=cutting should be considered. Or maybe completely new landform features that are more flexible.RicoZ (talk) 21:06, 3 November 2019 (UTC)

Edit to discourage cutting=yes and promote cutting=both?

This page was just recently edited to suggest use of cutting=both as the standard tag for a cutting where the ground level is higher on boths sides of the way. This value has been used 463 times (https://taginfo.openstreetmap.org/keys/?key=cutting#values), but cutting=yes has nearly the same meaning and has been used 55,294 times as of today. I believe it is a mistake to try to change this established practice. Also, consider that embankment=yes is also the standard way to tag the opposite feature. --Jeisenbe (talk) 17:47, 5 October 2020 (UTC)

I have made this edit because I thought it would make sense, and while there are only 463 instances of both currently, the tagging is superior by making the reference explicit. Similar tags like “sidewalk” already show a clear preference to “both” https://taginfo.openstreetmap.org/keys/sidewalk#values —Dieterdreist (talk) 22:24, 5 October 2020 (UTC)

Please ask about the change on the Tagging list or some other wider forum first. I also think that it would be necessary to propose the change for embankment=yes at the same time, since they are complementary features. --Jeisenbe (talk) 05:47, 8 October 2020 (UTC)