Do we have a coherent tagging scheme for the dates related to monuments and artwork?
They typically have two or three dates associated with them:
when they were designed / produced / created
when they were installed
(possibly) the year of the event they refer to
What does the Wiki say? The definitions for memorials and artworks have not been changed for many years, but are already contradictory in their use of tags:
start_date - Date when feature opened, the construction of the feature finished, or the feature was first at location
construction_date - Date when the construction of the feature finished
year_of_construction - Year when the construction of the feature finished, year range when the construction took place
old_start_date A statue was moved to a different place, use for the date of its original creation
I think this needs to be cleaned up - what are your suggestions? It seems a bit complicated to get to a coherent tagging scheme that doesn't invalidate all the tags added up to now...
start_date= in OSM is about the feature predominately, not the entity. The =artwork definition is non-conformal.
“Complete” was added early, while I would rather see this as vague Tag:tourism=artwork: Difference between revisions - OpenStreetMap Wiki
But is after the vote, and doesn’t seem reviewed Proposal:Tag:tourism=artwork - OpenStreetMap Wiki
“Not installed” was 2 years later Tag:tourism=artwork: Difference between revisions - OpenStreetMap Wiki
We should check whether actual uses follow this first. It might be ignored or unaware by most, and therefore it’s wiki not documenting the standard practice.
I would say this start_date= is unspecified/undefined. If the creation date is needed, it should be clarified eg artwork:start_date= (still not ideal) similar to memorial:*= etc. It would allow =memorial + start_date= + artwork:start_date= to describe when a piece of art is now installed to commemorate. Proposal:Subject - OpenStreetMap Wiki
Thank you to @mueschel for starting this thread. I’ve sometimes thought about this myself. I hadn’t noticed the historic:date tag, that seems pretty nifty to make the difference between when the monument was erected and the date of the event it refers to! I’ve always included either a description or (whenever applicable) an inscription that usually contains this information, albeit not in an easily machine-readable form.
I would have thought that start_date always refers to the actual, physical, object. So for a memorial/monument, that tag would contain the date it was erected.
I’ve always assumed the exceptions for memorials and works of art are because the dedication plaque at a memorial or the outdoor sculpture would typically indicate the dedication or installation date, not the completion date. A building’s cornerstone could indicate either the completion date or the (re)dedication date.
Essentially, OSM asks what’s on the sign. No one should be using OSM for precise time series data on every feature’s actual evolution. That’s what OpenHistoricalMap is for.
Additionally Key:year is sometimes used for some of these uses.
The definition of “Key:start_date” is “Date when feature opened or the construction of the feature finished”. The use on some artworks doesn’t appear consistent with that.
The keys “year”, “date” tend to invite indiscriminate uses.
this is really out of scope for OpenStreetMap and we should not map this here
we should not use either of this tags, and delete them if present
(yes, I am aware that it is controversial for start_date - that is why I do other things, still I consider start_date as a bad mistake - partially because it encourages even worse things like this ones)
Can we at least stop new historical data such as historic:dateyear_of_constructionconstruction_dateold_start_date and mention on wiki these tags are unwanted, dubious, out of scope, deprecated and bad ideas?
Well, in case the memorial actually has the date it was erected or made inscribed in it somewhere (and many do), and if it includes a plaque or a slab that has an inscription that commemorates the memorial to a specific event (as many do), then I don’t see a big reason not to include that data in OSM (and not merely in a description or a inscrption tag).
Of course, if either one is missing, then that information cannot be verified easily and that might be grounds for omitting the date data.
I completely disagree. We’re not talking about things that existed in the past and are not there any more. These tags are for existing objects - how old are they, when have they been built? These are facts that often can be verified on ground and are of general interest. I wouldn’t call them “dubious” or “bad idea” any more than e.g. the material a building is made of (which often is even more difficult to verify).
also say " * historic:date - Date when related event happened" ? How you verify this one on the ground?
Often monuments or plaques or memorials do not include relevant dates or these dates are wrong.
(to say nothing about mythical, religious, controversial or about otherwise tricky cases, which historic:date should be applied to artwork depicting creation of world in place of worship operated by religion XYZ ? )
Yes, I agree with you. Fundamentally, it should be discussed whether a feature should be allowed to define the same universal attribute differently. This is bad and unexpected. It should have at least used artwork:start_date= for many reasons.
By the way, shops often indicate their start dates too. For example, this shop says it’s been around “since 1926”:
But what it doesn’t say is that 1926 was when the shop first opened for business. It moved to a new building in 1955. I see this kind of information on signs and menus constantly and would love to have an unambiguous key to put it in. I’ve omitted possibly thousands of these surveyed dates from OSM out of concern that start_date=* would be misinterpreted. This wouldn’t and shouldn’t be useful for any sort of time machine simulation or neighborhood gentrification analysis. Mainly it would just be a place to put the literal information that’s staring me in the face, like anything else in OSM.
OpenHistoricalMap would model this as a building and POI with a start_date of 1955. The POI would be a member of a chronology relation with a start_date of 1926. If that relation has no member that also starts in 1926, then we know there’s a gap in coverage to fill in. OHM’s modeling would be useful for rendering and analysis use cases.
(Incidentally, is it an amenity=cafe, shop=deli, shop=pastry, or amenity=restaurant? Maybe it’s been all of those things over its lifetime!)
Yeah, I had been looking for a good key for that too. “year” could be a lazy solution, but a solution for such years of shops and other organizations would be good to have. It’s easier if there is a memorial to map with the information (we map the memorial that commemorates a year (or an event in a stated year)). Such years can be accurate or not, just as any information that is based on signs, even trivial points such as opening_hours .
“artwork:start_date”: I’m not sure if this really avoids the problems we have with “start_date”.
Right, that sounds like the year it started to be an artwork.
How about something like creation_date, installation_date and memorial:date.
The latter one would fit into the ‘memorial:*’ namespace, and the other two align with things like construction_date and start_date.
I don’t like historic:date because the prefix usually refers to this object itself being historic, not to something it refers to. construction_date is used a lot on buildings, but might be confusing here as well.
Memorials do use “historic:” as prefix, so historic:date can be consistent.
At Talk:Tag:memorial=plaque - OpenStreetMap Wiki? commemoration_date is suggested. It has some some uses. commemorated_date could avoid some remaining ambiguity. An issue that can also pop up with memorial:date .
creation_date without a prefix artwork: might restart the issue with start_date.
And some POI with impressively old dates are either lying outright, are using extremely creative accounting or are outright jokes/movie scenes/reconstructions etc.
False dates are probably not an argument against a tagging scheme. After all, one could quibble about whether the restaurant above serves “fine food” if its main fare is fresh salad. But creative accounting is indeed a reality for the “established” date, not only on a shop awning but also potentially on a welcome sign. Should an administrative boundary get a date based on when the place was incorporated or when it was first settled? What if the signs pick one date over the other arbitrarily?
