Proposal talk:Ruins

New 2011 proposal(s)

with ruin_type=(type of ruin) in addition to historic=ruins

I'm a new user that started trying to tag a ruin I visited on holiday and immediately ran into the inconclusive discussion below. I think there is a need for a bit more detail than just historic=ruins but agree with the arguments below that it would be very disruptive to deprecate this tag.

I have therefore refreshed the proposal to suggest that there simply be a new tag ruin_type=*. From the discussion below, this was the least controversial proposal that poses the fewest difficulties for developers and for backwards compatibility.

I'd be interested in people's views.

--Zephyr123 15:45, 27 April 2011 (BST)

I don't know about global usage, but based on current content in the UK there are three approaches that are already in fairly common use, and a small number of examples that don't fit any of these patterns.

By far the most common usage of "ruin" in a UK extract of the database is "historic=ruin" (1380 occurrences out of a sample of 1696 uses of "ruin" or "ruins" as a key or value = 80%). Mostly there is no additional detail provided with this format, but sometimes there is a name. This might be termed the "concise format".

The next most common usage is "historic=<type of structure>, ruins=yes". This form is normally associated with quite a range of other detailed tags - including name, source, description, source, access, and so on. This might be termed the "verbose format".

I interpret this as meaning that where a contributor is unable to specify the type of ruin, then they use "historic=ruin". But if they are able to specify the type of ruin, then they normally use something like "historic=castle, ruins=yes" or "historic=abbey, ruins=yes".

In addition there are a few dozen instances in the form "ruins=castle" or ruins=abbey". These might be regarded as the "alternative format".

I can see why the verbose format "historic=<some building type>, ruins=yes" should be encouraged to capture that information wherever possible.

I can see why the concise format "historic=ruins" should be allowed as an alternative where the contributor is unable to specify the type of ruin. This is, after all, the most common approach

I can also see why those processing the data would want to handle a limited number of exceptions in the alternative format "ruins=xxx".

I think those three formats could form the basis of some general guidelines, but before trying to produce them I would be interested to understand better what situations you are finding that require another alternative and that couldn't be handled by one of the above?

--Peter Reed 18:14, 5 May 2011 (BST)

IMO using what you called the "concise format" and "verbose format" is both reasonable in the respective situations you mentioned. I also think that this way of tagging is used with many other tags, too. However, I personally like to have tags with some kind of logical structure and as few ambigious alternatives as possible. Therefore I do not like the "alternative format", because it allows to tag a historic place (e.g. a castle ruin) without using the historic=* tag. My favorite solution is thus quite the opposite of what User Zephyr123 suggested above. Let's make "ruins" a kind of sub-tag of "historic", using only the "verbose format" in a way like "historic=abbey, historic:ruins=yes, ...". So "historic" describes that type of object and the sub-tag denotes its status. I see two benefits in doing so:

* We can use "historic=building, historic:ruins=yes" as a replacement for the "concise format". This way someone setting up a map of ruins is able to identify each and every ruin just by one query, which looks for "historic:ruins=yes". Moreover, it's easy to explain: If an object is a ruin, it is always correct and save to add "historic:ruins=yes", no matter which other tags are used in parallel.

* We can add a new sub-tag "historic:reconstruction=yes" to tag a ruin that is (partly) reconstructed. I know several locations where ancient remains are partly reconstructed and I always shied away from tagging them just as ruins.

--Mstriewe 10:52, 7 May 2011 (BST)

I do agree with User:Zephyr123, but I do use historic=ruins + ruins=type of ruin (castle, building, farm, house, lighthouse, etc.) instead of historic=ruins + ruin_type=XX. But what ever the additionnal tag's name is, I do favor this way as it does not create inconsistency in data interpretation like adding a ruins=yes wich transforms a valid building into a ruin and needs interpretation of all kind of life cycle stages ( abandonned=yes, ruins=yes, disused=yes, planned=yes, project=yes, etc.) sletuffe 23:50, 9 May 2011 (BST)

The arguments for consistency in the data, and simplicity of rendering are well understood. However, contributors will surely describe what they see. In the case of ruined castles (just as one example), there is a whole spectrum of possibilities, from something that has barely changed in appearance from when it was a working castle, to a heap of stones that is unrecognisable, but we happen to know once used to be a castle. Somewhere in the middle we have something like this http://www.flickr.com/photos/37177488@N06/4408700212/ . To some this is a castle that is ruined. To others they are ruins that used to be a castle. And that doesn't begin to address something like http://www.flickr.com/photos/mervtheswerve/3341543237/ which looks like a castle, used to be a castle, is certainly not in ruins, but was largely rebuilt from ruins in the nineteenth century (as a house). Most people would still describe it as a castle. Consistency is good, but we are in areas where reality is messy. No practical tagging scheme is going to change that, so in areas like this, contributors ought to be allowed some flexibility to be expressive about what they find. Furthermore we don't know whether future users of the data will want to filter everything that was a castle, everything that is ruins, or everything that is a ruined castle - so it is fruitless to try and design tagging schemes on the basis that one must be easier than the others. To me "historic=ruins, ruins=castle" reads as though it looks like ruins, and used to be a castle; while "historic=castle, ruins=yes" reads more as though it looks like a castle but it actually is in ruins. Both have a place. --Peter Reed 11:39, 10 May 2011 (BST)

That is an interesting comment, the usage of ruins=yes might be a good way to describe that a castle (or whatever) is more a castle than a ruin in which case that whouldn't be too much of a problem if data users (renderers comes to my mind) consider it a castle. The case I see with more problems in data usage, is the case where the ruin could have been of usage today but is no more. The castle case or any man made feature of historic interest is easier to handle as almost no one expect a castle to still be in use as a castle but if we talk about a ruined pub, restaurant or modern amenity, using ruins=yes will become more tricky. So making a distinction between historic interest ruins and modern ruins might help (see my proposition down there).

The other point proposed earlier to give a ruin scale might also be used to help decide what to expect of the ruin : Can it still be visited (tourism interest) ? Is it still standing but with an high risk of falling (making it hasardous to go and see it) ? Is it torn down and only stone blocks remains ? sletuffe 16:33, 10 May 2011 (BST)

Mstriewe has suggested (below) a good basis for developing guidance on the main page to contributors on when "ruins=yes" is a useful approach, and when it is best avoided. It sounds as though we all feel much the same way on this. On your other points - the best way to indicate tourism interest is surely the existing "tourism" tag ("tourism=attraction"). That way any tourism-oriented process would also pick up interesting ruins. I'm not sure about hazards. It's not a problem I've come across, and on a quick look I can't see any existing usage of this type. Hazards are not a problem that is specific to ruins. Rather than creating yet more tags, it is more likely to be useful if any hazard warnings on ruins followed an established option somewhere else. Is there one? If this is something that renders don't generally handle, contributors could just be recommended to add a note to identify particularly dangerous ruins.

The same but with ruins=(type of ruin) in addition to historic=ruins

I still don't understand why "ruin_type=castle" is better than "ruins=castle", but maybe this isn't the place to discuss that --Peter Reed 12:36, 10 May 2011 (BST)

Well, to my point of view this is not that important after all, but since ruins=(type of ruin) is allready a little more used than ruin_type=* maybe we could construct this proposition with ruins=(type of ruin) ? sletuffe 16:13, 10 May 2011 (BST)

Historic interest and without historic interest ?

As written on Key:historic and as the name suggest, the historic=* tag is used for "features that are of historic interest." Also this might be subjective as interest is a subjective concept, I've seen the historic=ruins used for ruined man made structure of doubtable "historic interest". What do you think about proposing the ruins=* tag as standalone as well ? while the additionnal historic=ruins whould be added or not to the contributor's own feeling. sletuffe 16:20, 10 May 2011 (BST)

I agree, and I think what you say makes a lot of sense.

I think "historic" is mostly used to mean "this is something that is historically important", sometimes it is used to mean "this is something old", and less often it is used to mean "this used to be a <whatever>, but it isn't any more". As data quality issues go, that's not one of the most important issues, but the number of contributors is growing, and the range of information recorded is expanding. Before things get too woolly it would be good to tighten up the definitions a bit. Ultimately, of course, the contributor must decide, so I can't see how to get away from this being subjective (without laying down some really silly and complicated rules), but maybe some guidance on what criteria to use would help. I tried to start some general guidelines on the "historic" page.

I see no reason why any ruined structure shouldn't be tagged "building=something, ruins=yes", or "man_made=something, ruins=yes". As long as it is "mainly" a "something", and not "mainly ruins". So a "historic castle, ruins=yes" is as a castle by default. However, "historic=ruins, ruins=castle" wouldn't normally be rendered as a castle (unless the render was specifically looking out for that case). I think that's what people would naturally expect (as well a being easy logic for processing the data). Similarly a "military=bunker, ruins=yes", or "building=house"

However, "ruin=yes" can't just be applied everywhere. Anything tagged <key>=something, ruins=yes" would be be rendered (or processed) as a "something" even though it is ruined. I think that's what we would expect for features that are some kind of landmark - "it looks like a castle so let's call it a castle, even if it is ruined". But it's not what we would expect for an amenity. A hypothetical "amenity=bank, ruined=yes" isn't going to be much use to anyone! So "find me the nearest amenity" would need to make an exception for ruins (and disused, abandoned, proposed, construction, etc. as well). There are some edge cases - is a ruined "man_made=lighthouse" a useful landmark to walkers, or a useless aid to shipping? All this is solvable, but it isn't solved yet!

--Peter Reed 17:25, 10 May 2011 (BST)

Yes, that's a good point! Perhaps ambigious tagging of modern amenities with "ruins=yes" can be avioded by recommending to use ruins=* only with other values than "yes" and "no". Consequently, a contributor mapping an object (e.g. a castle) would have three options:

(1) Saying "Here are ruins of a castle, but I don't think they are of historic interest" will result in tagging just "ruins=castle"

(2) Saying "Here is a castle which is of historic interest, but I don't think we should call it a ruin" will result in tagging just "historic=castle".

(3) Saying "Here are ruins of a castle which is of historic interest" will result in tagging "historic=ruins, ruins=castle".

A fourth option for unknown objects would be to say "Here are ruins of historic interest, but I don't know what it was" resulting in tagging just "historic=ruins". However, I'm not sure how relevant this is... Can I state that something is of historic interest without knowing what it was?

--Mstriewe 00:10, 11 May 2011 (BST)

That's a good idea on handling the "amenity" problem. On the "historic=ruins" I think it is possible to see something that is obviously of historic interest, without knowing what it is. Castles are normally relatively easy to identify, but a lot of Roman remains and some medieval remains (in the UK anyway) are only seen as the stumps of walls. They would fall somewhere near to being classified as an "archaeological_site" (but with a bit more stonework visible). No doubt specialists can identify former uses, but most of us just see bits of walls. It's certainly better to collect the specific information if possible, but in my view contributors still deserve to have the option of saying "I know this is something historic, but I don't know what it is". With that, I agree completely with your list of options. --Peter Reed 08:16, 11 May 2011 (BST)

I like the 3 options you proposed as well. But what about "historic=castle, ruins=yes" ? When do we use it ? do we use it ? and what whould be the meaning ? sletuffe 10:45, 11 May 2011 (BST)

If we agree on the three or four options I suggested above, my personal decision will be to abstain from using "historic=castle, ruins=yes". I think its meaning is the same as of option (3). Same would apply to tagging "ruins=castle, historic=yes" (there are more than 5'000 objects tagged "historic=yes" in OSM at the moment). After all, the wiki page for historic=* discourages from tagging "historic=yes", so we can surely do the same on the page for ruins=* for tagging "ruins=yes". --Mstriewe 15:33, 12 May 2011 (BST)

That was my personnal feeling at the beggining (not to recommend "historic=castle, ruins=yes"), but as User:Peter Reed said bellow, it could be used to ditinguish a ruined XX that is more an XX than a ruin, therefore beeing rendered and used as an XX by not aware data users, wich shouldn't be too much of a problem since it is more an XX than a ruin. ;-). Also I have read on the Castle page that people have recommended the usage of ruins=yes, which mean people have found it usefull. In the database, the usage of ruins=yes is rather high as well. Two year ago (see 2009 proposal) I was against the usage of ruins=yes, now, I'm not sure anymore of what is best ;-) sletuffe 16:01, 12 May 2011 (BST)

I guess it's a trade-off: To recommend tagging "ruins=yes" allows for differentiation (and additions like "reconstruction=yes" as I suggested above on this discussion page). However, it also gives way for all the lifecycle problems with modern amenities tagged "ruins=yes". To discourage from tagging "ruins=yes" avoids these problems, but also limits differentiation. I'm also not sure what's better. :-) --Mstriewe 18:47, 12 May 2011 (BST)

I imagine that when somebody (who has thought about this) tags "historic=castle, ruins=yes" they mean it is "more a castle than ruins" (by default they will expect it to be rendered / processed as a castle), whereas when they tag "historic=ruins, ruins=castle" they mean it is more ruins than a castle - in other words it just looks like ruins, but they know that it actually used to be a castle (by default they will expect it to be rendered / processed as ruins. It's nice that it can be expressed either way so easily.

--Peter Reed 20:20, 11 May 2011 (BST)

Original 2009 proposal

Deprecate historic=ruins (using a ruins=yes tag)

Trying to evaluate this tag, I noted that all sorts of ruined things are marked with this tag: Castle ruins, church ruins, factories, houses, anything. This makes it impossible to identify ruins of real historic importance from abandoned modern buildings. I question whether this tag makes sense at all, as about any sort of building may be a ruin.

I believe that using ruins as an attribute to other tags makes much more sense, e.g. historic=castle, ruins=yes, amenity=place_of_worship, ruins=yes or building=factory, ruins=yes.

Therefore I suggest to deprecate the value historic=ruins. --Nop 13:03, 3 June 2009 (UTC)

Physical things turn into ruins and then they are no longer that physical thing. I'd say it's better as historic=ruins + ruins=castle (or ruins=church or ruins=mosque or ruins=outhouse.

"Find amenity=pub where not ruins=yes and not disused=yes and not abandoned=yes and not..." or "find amenity=pub"? Alv 15:13, 3 June 2009 (UTC)

Well, both would work, but tagwatch already shows 173 uses of ruins=yes and no other uses of ruins=*. So I'd say let's go for what works and is already in use instead of trying to reverse two existing uses for something completely new. But I'd still like to add a note to keep people from using the completely unspecific historic=ruins tag. --Nop 15:32, 3 June 2009 (UTC)

With 2800 historic=ruins (in Europe at the time tagwatch was last updated), many have not deemed the distinction between castle and outhouse ruins important (although the English guidelines "... of a castle or alike" do seem to limit it to ruins of older or bigger constructions). It would be meaningful to distinguish them and it should be encouraged first, before advocating abandoning it altogether. Nevertheless it's better to tag it as the physical thing (building/castle/wall/...) that has become ruins. Alv 18:24, 3 June 2009 (UTC)

We had the same trouble with the highways, where some people advocated to use highway=* and construction=yes, wich resulted in quite some mess. So now we use highway=construction and construction=* and it works much better.

With the ruis it ist the same thing. When there is only a ruin left, it is misleading to tag the building as it was before. So using historic=ruins and ruins=* would be the much more stable approach.

--De muur 17:30, 26 September 2009 (UTC)

I totally agree with Alv and De muur, creating a ruins=yes will only create backward incompatibilities in data usage and will result just like disused=yes, abandonned=yes and make usage of data a mess. Please don't. And please also don't add such important notes too quickly without reaching a consensus first. sletuffe 22:10, 6 December 2009 (UTC)

Did you bother to check Tagwatch? You just removed a usage that occurs over 600 times in Germany alone and is consistent with other wiki pages without providing a better suggestion. The problem with historic=ruins being used for everything from a castle over an old bunker to an incomplete hotel or factory is much worse than a possible backward incompatibility. It is not the highway-Tag, but an historic tag that is mostly ignored by the mainstream maps and needs some special rules anyway. And before you remove something that is in use, you should at least suggest and discuss an alternative. --Nop 07:55, 7 December 2009 (UTC)

If you want figures, you'll see that historic=ruins is used around 4800 times against 700 for ruins=yes. But that's not my point here. There was a tag, wether or not it was precise, you changed it's description on your own, while at least 3 personnes here shown doubts about your ruins=yes proposal. If you want to document then create the proposition Proposed features/ruins, explain it's usage and in which case it can be used (only historic ? amenity ? man_made ?), and then start a discussion to find a better way to represent ruins. But not by exposing a new born ruins=yes over an allready used (even if approximative) historic=ruins that noone had chance to discuss. sletuffe 12:30, 7 December 2009 (UTC)

Exactly, 700 uses by different users is a vote. A proposal had already been preempted at that time by other users with the use of ruins=yes in the definition of historic=castle. --Nop 16:30, 7 December 2009 (UTC)

Doh ! Okay, I see... you are of the "move forward no matter what" type with a "give a vote to any one using it". I'm part of the people who think that since you add something to map features, people will start using it no matter how unusable/duplicate/good/excellent/what ever it is, because I feel that people do trust the wiki because they think it comes from a smart discussion/voting/consensus process. Luring them by fast procedures aside long term reflexion looks some sort of betrayal to them. You'll decive people on the long term when they'll see their tagged ruins are considered castle by every renderer.

Please think again and engaged a discussion on the ruins page (I'm not gone revert anymore if we just keep the "it's still a proposal" note). Again, look at the disused=yes tag history (which share the same concept as ruins=yes). It exists around here (and in map features) since 21 April 2007, most people are complaining about it not rendered correctly (beside canals), people are fighting at creating bugs report, at osmarender, mapnik, mkgmap, cyclemap, etc. Don't you think people (14000 uses in the db !) using it are now bored and feel betrayed ?. Look at the answers from data use developers :

This type of tagging is extremely unfriendly to data consumers (don't assume that all data consumers that don't care about your pet tag supports it), and in osmarender it would require really big and ugly stylesheet changes to support it and it's related tags.

I'm not going to make the stylesheet almost impossible to figure out in order to support a bad tag.[1]

(others didn't said so, but in 2 year 1/2 existence, it isn't supported anywhere I know) sletuffe 11:26, 8 December 2009 (UTC)

See Comparison of life cycle concepts. Obviously ruins=yes is of the form <status>=yes That page seems like a good distillation of pros/cons and alternatives, but ultimately inconclusive. It's a tricky problem -- Harry Wood 02:23, 12 April 2010 (UTC)

Alternative way of representing ruins

I see no reason to deprecate historic=ruins, but rather add more information with a ruin_type=* and ruin_state=*, if known constructed=year of construction and ruined=year of destruction. The tag historic=castle already use ruins=yes to indicate wether the castle is ruined or not, but I think this is a rather bad way of doing it, specially if it should apply to any man_made=* structure. I live close to a ruined church. Now it is tagged only with historic=ruins but adding ruin_type=church will improve the information available. If it should be tagged amenity=place_of_worship with ruins=yes than I fear that we can have many examples of broken code, such as rendering as a church (instead of a church ruin), advice to go there for the sunday mess (in routing software) and so on.

Also close to where I grew up there was a ruin, this was so old, worn down and almost impossible to identify. How should this be marked on the map? I would there place a single center node with historic=ruins and if possible find a logical tag to show that it is almost completely erased. --Skippern 21:20, 7 December 2009 (UTC)

I agree with your proposed way to do it over the ruins=yes addition to allready established features. I do understand the ruin_type=*, but we might need to list possible value explicitly. However I don't get your ruin_state=*, do you mean a scale for the "ruined state" ? such as "almost_intact",..., "Torn down",..., "invisible" ?. About ruined=year of destruction, it might be a bit hard in some cases as a building does rarely jump from "usable" to "ruined", but it might be good of an estimation of the year it ceased to be usable.

About ruin_type, I don't have opinions about how far should it go, does a ruined farm should be historic ? Could the historic=ruins be optionnal ?

I'm updating the page, everyone feel free to remove, modify, change it. sletuffe 10:40, 8 December 2009 (UTC)

I thought about ruin_state=* to be some sort of scale from clearly abandoned to under a layer of peat just to take some extremes. The exact definitions to be used are of corse topic of discussion. For ruined=*, maybe roman numbers to show what century the ruin is dated from? It might be of interest to know the difference between a XV century and XVI century church ruin.... Also in many cases the constructed and ruined time can be extremely hard to determine, and accurate sources might be copyrighted in some way unusable for OSM, but that shouldn't stop us from accepting such tags, there are still sources we can use. The church ruin near my house have a sign infront stating year of construction and something about time of abandonment, havn't studied it that well yet, but will add it to the tagging soon. --Skippern 01:11, 9 December 2009 (UTC)

What about ruined construction places (investment rouins)? They occur when the owner of a building goes bankrupt before the building has been finished? I doubt that they are of historic interest as well as many other residental ruins. Keinstein 14:05, 24 October 2010 (BST)

Alternative tagging using lifecycle prefix, mark this proposal as inactive?

The use of a lifecycle prefix offers several possible alternatives, time for a fresh start of this proposal? RicoZ (talk) 14:03, 5 February 2015 (UTC)