Feature proposal - RFC - Historic

Hello.

I’m proposing to approve the historic=* key together with a number of tags.

historic=* is in widespread use and currently documented as de facto.

Please comment wherever you feel most comfortable:

1 Like

Hey,

I support approving the historic=* key itself, but a whole range of tags, especially in-use ones, still require much consideration before I would feel comfortable with approving them.

Examples:

  • anchor - is not necessarily historic. It’s just a generic object (man_made?) with a start date that may go quite far back.
  • bomb_crater - most are barely visible in the landscape, to the point that they’re not not even noteworthy on any map other than OHM.
  • castle_wall - We have at least 4 different tags for historic defensive walls. This mess needs to be cleaned up first before we can vote on it.
  • all the vehicles - These could be grouped in a sub-tag. I see no point populating the historic=* key with tank, armoured_personnel_carrier, ship, locomotive, railway_car, submarine, airplane etc etc etc.
  • ruins - historic=ruins + ruins=* is a tagging combination that means exactly the same as historic=* + ruins=yes, and still no clear consensus on a best practice exists.
  • road - What’s that supposed to mean? Some piece of asphalt in a museum, an old road that’s still in use, or a road that’s primarily visited by history enthousiasts? This needs to be clarified first.
  • archaeological_site - This scheme is a relic of ancient OSM in which many things are not even archaeologically relevant, such as objects and structures that never needed to be excavated but are still standing and are in a preserved state.

I could go on but I think I made my point. I am strongly against approving tags in the historic=* key en masse, but I do not dispute the value of the key itself.

4 Likes
Which do you prefer?
  • historic=* and values should be approved.
  • historic=* should be approved, but not values at the same time.
  • Neither should be approved.
  • Other.

0 voters

In order to give the proposal the best chances of success, I’m interested which option the community would prefer:

  • Approve historic=* plus values at the same time.
  • Approve only historic=* but not values thereof.
  • Approve neither.

Please note that it is a lot of effort to write separate proposals for each values.

Yes, I fully understand this concern. Problem is that writing separate proposals for each value takes a lot of work. Not sure anybody is willing to go through this.

In that case I would leave them alone rather than approving problematic tags that someone else may still revisit in the future. Some tags have simply been documented following the ATYL guideline without any community consensus, after all.

1 Like

OK. I’ve just reduced the proposal to only the key itself.

1 Like

Given that there are multiple historic=* tags already approved (battlefield, memorial, etc), I’m not sure what the point of approving the key itself is. In fact I’m not sure what that would even mean. A key is never used by itself but is always combined with a value. So only a key/value pair can be approved or not. building=river is a nonsense tag, despite the fact that the building key is approved.

3 Likes

Good point! Let me consider that…

Speaking of OpenHistoricalMap, the project has been trying to hew to OSM’s tagging conventions as much as possible, with only minimal adaptations. However, in historical geography, everything is historical, so the historic=* key doesn’t add much meaning and can even be misleading. A historic=fort that only existed for 10 years may not have carried any historical value at the time it was destroyed, but that’s the tag that OHM currently uses out of deference to OSM. It feels very much like OSM using tourism=attraction as a catch-all for anything interesting.

But back to OSM, when coining new tags, it’s worth keeping in mind that mappers are constantly pushing the boundaries of notability. I don’t think historic=memorial was coined with the idea that it would be used for the plaque dedicating a tree to a deceased pet in someone’s front yard, but it is valid for lack of something more fitting. This doesn’t mean we should deprecate historic=*, but approving the key per se may encourage new values that end up diluting the key’s meaning.

4 Likes

@Minh_Nguyen Excellent points. I fully agree with you. The historic key by itself, much like man_made, is an almost meaningless umbrella term for a list of tag values and their sub-tags, and it’s not always clear what is “historic”.

Your final remark got me thinking. I got the defensive_works=* key approved without relying on historic=* for exactly the reason you mentioned. Maybe we can use that as a template or precedence for coming up with more objective alternative keys for which we don’t have to push the boundary of notability.

Funny, this is the second time within just weeks that a primary key is being critized. (the other one being amenity).

Also, it turned out that primary key, feature key, main key are not well defined and non of them is approved as official OSM terminology.

Is it perhaps time to have a grand discussion about OSM’s highest-level tagging scheme in general?

1 Like

I am also interested in having a consistent and community approved “historic” key scheme. Even if this proposal does not go forward at this time, I want to thank @martianfreeloader for his work.

Based on my own previous experience, I have the impression that this is a complex issue to resolve that may require involving a group of collaborators with a good knowledge of tagging to resolve the mess.

That’s actually what’s lead to this. There is a proposal for a sub-tag in the historic hierocracy (Proposed features/crannog - OpenStreetMap Wiki) when the tagging scheme itself has never been fully discussed (site_type was only changed to de facto, from in use, recently).

Personally, site_type is a terrible key name. It isn’t clear what it applies to (without going to the wiki) and could be applied to any sort of “site”. A better name IMO would have been archaeological_site or similar.

I doubt we’ll get that changed now, but the wider issue is should we let low-usage proposals (such as the crannog tag) formalise a tagging scheme?

At least approving historical=* sets a precedent and says what sort of thing can be added as a value to this key. It’s a formality perhaps - but one that’s perhaps worth having. The same process can then be applied to sub-keys.

Alternatively, when a proposal is made that affects the whole hierarchy (such as the crannog proposal), it should be made clear in the proposal what the complete ramifications are.

Would you be in favour of removing the status of all keys and putting more focus on the status of tags (values) instead?

An issue with the archaeology tags is that something will be tagged as an archaeological site even long after the actual archaeologists are gone. So if they dig up a fort for example, do we tag it as historic=fort or as the site_type equivalent?

That’s a good point and I don’t know the answer. If something were tagged like historic=fort, I guess I’d expect to be able to see it (or at least remains of it). If it were completely hidden, e.g. having once been excavated and then reburied, it seems like perhaps it shouldn’t be tagged the same.

According to Wikipedia, an archaeological site:

may range from those with few or no remains visible above ground, to buildings and other structures still in use.

But for something like some ruined Roman baths, where archaeologists have exposed (and left exposed) only remnants such as the foundations then which method makes the most sense? I’m not sure!

And historic sites that never needed excavation but are in a preserved state, do we tag them as archaeological sites just because that’s a tagging scheme that already exists? I can tell you that’s exactly what people are doing.

But in the end it’s just one of the historic=* tags that has a problem. In Talk:Proposed features/Citadel - OpenStreetMap Wiki I’ve also outlined a couple of problems with castle_type=*, which are probably what sparked martianfreeloader’s original proposal here.

My point still is that historic=* needs a lot more attention and most likely some rewriting and retagging before all of it can even be considered for a proposal process.

Somewhat related: https://www.reddit.com/r/openstreetmap/comments/y2firn/difference_between_historicarcheological_site_and/

I’ve been wondering about that myself. There’s an old town located under a lake near where I live that someone recently tagged as an archaeological site, which I guess isn’t technically wrong, but doesn’t seem right either. I’m unsure what to do about it though if anything. Although keeping it tagged as an archaeological site doesn’t seem right since no one is, or probably ever will, be recovering and analyzing anything from it. Tagging it as a historic feature doesn’t sit well with me either though since it was built fairly recently, is still mostly intact, but is just not currently accessible :man_shrugging:

an archaeological_site does not have to be excavated, it is a site regardless of excavation or exploration (at least if it is confirmed, otherwise it would be a suspected archaeological site and maybe not mappable in OSM, but if the site is visible, there should be no doubt).