I would like to motivate a change in the description of the Key:start_date page,
from
start_date=* can be used to indicate the date the feature opened or construction of the feature finished (i.e. started to exist as feature)
towards
start_date=* can be used to indicate the date the feature began to exist most often the date the feature opened or construction of the feature finished.
This date should correspond to the feature as it exists today, neither to previous states nor to its predecessors.
The start_date does not apply only to the main descriptive tag (e.g. highway= or railway=) but to the entire feature, i.e. its geometry, its main tag and all other descriptive tags excluding identifier (as wikidata,wikipedia…) and source tags (i.e. all descriptive tags are valid on this given date, start_date should not conflict with these).
1-2 The first two sentences seems like a detail but the original one may introduce some confusion. In a number of cases this seems to be interpreted as “the main tag started to exist as feature” e.g. it started to exist as a church. However by reading the Good practice I see that we are not supposed to map neither historic features nor objects if they do not exist currently, the date given should therefore be the date of the feature as it exists today. Historical mapping remains possible but falls under dedicated projects such as OpenHistoricalMap.
Here are some examples if I follow the current practice “the main tag started to exist as a feature” vs “the date of the feature as it exists today”:
Mons (Be) train station started to exist as a feature its main element being building=train_station in 1874… however these first two stations no longer exist so the date of the feature as it exists today will be 2024-2025 (it is not finished yet).
Church of Saint-Étienne in Lille (Fr) started to exist as a feature its main elements being amenity=place_of_worship+building=church in the 11th century… however the current church is originally a chapel of a religious congregation built in 1610, destroyed by fire on October 8, 1740 and rebuilt in 1748 in Baroque style and it only became a parish church under its current name in 1796 following the destruction of the first church located 300-400m from there.
In a complex case such as this, we can use a start_date:note or start_date:cause to give details accompanied if possible by a source.
In the case of modified buildings, there is always the possibility of using building:part to date each part of the building but the feature with building= should always include the date it began to exist as it currently stands.
3 For the last sentence, the majority of start_dates do not have a prefix (e.g. name:start_date, ref:start_date) which in itself is not problematic if this start_date is for the date the feature began to exist as it currently stands . Likewise we must be able to assume that at the given start_date all the descriptive tags (excluding sources and identifiers) were true. If I take the example of Charleroi-Central railway station, the start_date is 1843-07-30, however the name “Charleroi-Central” only appeared in 2022 and there is little chance that the station was accessible to wheelchairs in the 19th century just as the SNCB/NMBS operator has only existed since 1926, here the start_date conflicts with the other tags of the feature.
We may include a date for the main tag (this could however be a historic feature and therefore not have its place here) but as this only concerns a single tag it should use the appropriate form main_tag:start_date (e.g. highway:start_date or building:start_date) without causing conflict with the other tags in the feature.
Consequences:
on renderers: none.
for users: no feature modification necessary, this mainly targets objects with a complex history which most of the time do not have a start_date or already have a correct start_date (a simple building=yes with start_date=1750 is not affected by this change).
Given this distinction, shouldn’t OSM’s usage of start_date correspond to whatever a sign says or would say about the feature’s inception? The date on the cornerstone of a thrice-rebuilt church may be from its newest construction or from the original foundation. The “established” date on a restaurant may be based on when the restaurant was founded at a different location. Apparently the start_date of a tourism=artwork indicates when the sculpture was installed (presumably based on the plaque), rather than when the sculptor first took a chisel to the slab of stone.
In all these cases, what matters is what’s observable in person, right? And if nothing is observable, then there’s no start_date to tag. OHM can make finer distinctions because we can map all the different “versions” of the feature there as separate copies and can consult published material to ascertain the dates of each version.
I guess this list of exclusions would need to be a lot longer. For example take a restaurant that opened in 1776 - as soon as we add website, phone or diet:vegan tags we would need to remove the start_date and replace it by a bunch of individual xy:start_date for the amenity, building and so on.
I agree with you that we should make the Wiki a bit more precise. We could e.g. change
(i.e. started to exist as feature)
to
(i.e. started to exist as feature in the current form, with its major properties unchanged)
E.g. if that restaurant added an outdoor seating area later on, start_date=1776 should be allowed to stay, while encouraging to add outdoor_seating:start_date = 1987.
Fun topic, this start_date is a mandatory tag on pharmacies in Italy. If you don’t enter the license effective date, which changes with a new pharmacist operator or if the license changes due some other legal event, than Mr Osmose will poke you to enter a source:start_date=* instead, a bug I suppose as it’s start_date. Anyway the dates the so called ref:msal gets updated or changed is historically maintained in the MSAL register (health ministry), so one has to sort them on a newly mapped POI to find the latest. The tag is hardcoded in my custom preset, hard to miss.
Don’t care who prompts when the tag is missing, Osmose seems to have picked that up somewhere. It’s been tagged on pharmacies here long before my active mapping start_date, same as ref:vatin as if we’re an extension of the tax office :O)))
Even changes of major properties do not always warrant “resetting the start_date”, unless the change is so dramatic that the feature is now perceived as new instead of as an upgraded continuation of the old feature.
It helps to be specific w.r.t. what OSM element start_date is applied to. For example, if a railway station gets a new station building, you can set the new date as start_date for the building element but keep the old date as start_date for the station element.
A case we have been discussing in Belgium was about a railway station.
This station was built in 1843. Until recently, it was named “Charleroi South”. In 2022, the railway company changed its name and it is now “Charleroi Central”.
This is of course the same station, with a new name.
Tagging it as start_date=2022 would give the impression that there was no station here prior to that date; this is an example where we might want to keep start_date with the original date and use tags like name:-2022 to mention the date of the name change.
yes, the start_date is referring to the feature, not necessarily to the name. In this case where just the name changed, I think we can agree that the start_date is in 1843 (it becomes more difficult when the feature is significantly transformed).
Another tagging variant could be:
old_name=Charleroi South
name=Charleroi Central
name:start_date=2022
I wouldn’t use name:-2022, I would use name=Charleroi Central + old_name:-2022=Charleroi South (or old_name:1843-2022=* if that was the name since the opening) + start_date=1843 as documented in Key:old_name - OpenStreetMap Wiki
This is the datespec syntax that was proposed several years ago. It sees some usage in OSM, but I don’t know of any data consumer that consumes it or would even want to consume it. Open-ended syntaxes inside keys, with an infinite number of possible subkeys, are difficult for most data consumers to process.
This is nice, but inevitably someone will want to record multiple old names, each with a different start and end date. So then you’d be looking at either an indexed series of subkeys like name:3name:3:start_date or a parallel set of multiple value lists, like name=Foo;Bar;Bazname:start_date=1900;1950;2000name:end_date=1950;2000;. Either of these approaches would cause non-date-aware data consumers to mistake a historic name for a current one.
Good to know. What does it do with this information, generally speaking? This documentation could benefit from discussion about use cases and existing software adoption, so it doesn’t come across as just a proposal.
That’s the impression I get too, but it would be great to know for sure. I tried rooting around the codebase, but nothing jumped out at me at a glance.
I think the old_name page is not correct, it doesn’t make sense, because it pretends old_name:1922-1932=foo is about a name valid from 1922-1932, but the tag for this would be name:1922-1932. The mentioned old_name tag with years would be about a name that was an old_name from 1922 to 1932 (so doesn’t seem to make a lot of sense).
In your suggestion, old_name:-2022 means the tag was an old name until 2022, but what you would want is old_name:2022-=* so it was an old_name since 2022.
