Proposal to change the Key:start_date wiki page

General talk Tagging general discussion
1

Hi,

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).
2

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.

2 Likes
3

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?

I support “whatever a sign would say”, let’s put this.

2 Likes
4

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.

5

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.

6

Osmose bug is not making this tag mandatory, it may be omitted when mapping pharmancy

if Osmose claims it is mandatory then Osmose should be fixed

7

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)))

image
image394Ă—801 11.3 KB

(date format needs help)

8

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.

3 Likes