Talk:Key:start date

Use of ISO 8601

Sward 17:30, 14 November 2010 (UTC)

ISO 8601 is used as a basis for the date formats, but various representations supported by it are specified in non‐standard formats. ISO 8601 already supports representing times with reduced precision (omit unnecessary components), and ranges or intervals (<start date>/<end date> is one such format, using ‘/’ as the separator, not ‘..’). It defeats the purpose of a standard to partially use it, then use non‐standard replacements for other parts of it. Non‐standard use will also break ISO 8601 parsers—the formats are designed to be both human and machine‐readable.

I suggest always using ISO 8601 where it provides the desired solution, and for any non‐standard representations, either always using a prefix or suffix that unambiguously says “this is not an ISO 8601 representation” or using another key entirely. In some cases, e.g. Julian calendar, I might suggest using another key anyway, but I haven’t yet formed an opinion on this.

Approximation

ISO 8601’s “reduced accuracy” is not quite as expressive as desired here. It does not say how to precisely indicate the year, but then say there is some error, e.g. ~1855, 1855±2, and also doesn’t cover representation of decades, e.g. 1860s. These will still require alternative representations, but wherever possible, the ISO representations can be used.

Century Approximations

Specify just the century part of the year:

• 18 - 1800 to 1899, not 18th century, or 1701 to 1800
• 04
• 20

As written, the Cyy form is unclear whether C18 means “18th century, that is 1701/1800” or “18-something”. If this form is kept, then this should be specified (I would probably go with nth century).

If you use this syntax for centuries, how would you represent the year 18? Nicolas17 (talk) 04:26, 6 June 2013 (UTC)

Year 18 should be coded as "0018". Any yes, this format will probably create a Y100K problem :-) --Biff (talk) 14:38, 7 July 2013 (UTC)

Date Ranges

(Time intervals in ISO 8601)

Use the solidus (‘/’) to separate a start date and an end date:

• 1914/1918 indicates some time during WW1
• 2008-08-08/2008-08-24 indicates some time during the Beijing Olympics
• 17/18 17xx to 18xx, not 17th century to 18th century

Note that the last example is changed. There is no defined method of representing mid C17..late C17 in ISO 8601, meaning a representation is still required.

I admit using ‘/’ does have a disadvantage of being confused with its wide use in other date formats (e.g. dd/mm/yyyy), but this is a compromise already thought of when developing ISO 8601.

ISO 8601 also covers representation of time intervals using durations (similar to 1955 plus 20 years). I have not covered it because I do not see the need for it here (and it is quite ugly).

BC and AD

I fully sympathise with possible confusion over astronomical year numbering. Keep the BC.

Open Historical Map is starting to work on development of Date/Time Formats that cover our somewhat broader range of needs. We are looking at ISO 8601-02 (the extensions) and at the Library of Congress EDTF formats (EDTF is broadly compatible with ISO 8601). We are also considering non-Gregorian dates. My recommendation would be that absence of prefix indicates Gregorian (including projection of Gregorian back in time from 1532), and using prefixes for non-Gregorian, e.g. something like jl: or julian: for Julian dates, roman: for Roman dates, and so forth. Distinguishing between Gregorian and Julian based on a simple year test (against 1532) isn't correct, because many jurisdictions used Julian well after 1532; Greece did not switch to Gregorian until 1923 for example. Nfgusedautoparts (talk) 01:26, 26 December 2020 (UTC)

Which construction

Adding some start_date's for roads that existed already in the 18th century, it became apparent that the definition needs to be clarified - if not for start_date, for new tags. "Date the construction ended" doesn't say which construction for features that are still the same, but have been changed in minor or major ways. See User:Alv/Tagging issues. Alv 11:35, 16 September 2011 (BST)

Available for use

For some time the definition was altered from "can be used to indicate the date the feature opened or construction of the feature finished" to "can be used to indicate when a feature became available for use". This slight change in wording results in a less useful definition in some cases (e.g. on natural=tree) so this was reverted. --Dieterdreist 09:01, 31 May 2012 (BST)

No problem. Looking at railway lines, which often attract very detailed levels of information from enthusiasts, we may in time wish to be able to distinguish between the following:

Planning permission granted

Start of construction

First freight use

First special use

First passenger service

Completion of all works

Last usage by passenger services

Last use by freight services

Last use by special services

Reopened for special services

Reopened for passenger services

etc

-- PeterIto 22:19, 1 June 2012 (BST)

start_date in WikiMiniAtlas

Displaying OSM building data at high zoom levels using client-side tile rendering. Buildings with the start_date key are highlighted.

I have recently deployed client-side tile rendering at high zoom levels in the WikiMiniAtlas (a Wikipedia plugin that uses OpenStreetMap data). As no tile images are prerendered, but raw map data is transmitted to the client (in JSON format), the map styles can be changed on the fly. In the screenshot I have added a client side style to highlight objects with the start_date tag (dashed red outline). I'm working on adding a GUI control to pan through time and show the state at a given point in time. Again, since the rendering happens on canvas elements in the browser this should be fairly trivial to implement (the only challenge is the parsing of the rather heterogeneous date formats). I'm looking forward to a more widespread use of this tag (and possibly the end_date tag as well!). --Dschwen 00:52, 31 July 2012 (BST)

P.S.: development version is here: http://toolserver.org/~dschwen/wma/index_dev.html (may not always be working)

Would this be suitable for the age of a tree?

-- SwiftFast (talk) 15:02, 23 May 2017 (UTC)

Basically yes. Technically, the tree wasn't a tree at the date when it was planted, but in my opinion it makes no sense to take care of that (instead, things like building=yes / building=construction should be distinguished. The start_date of a building is the date it was completed, in Open Historical Map it would be optional to add another object (building=construction) with the start_date representing the data the first piece of earth was moved and end_date="start_date of building=yes".) --P1230 (talk) 10:33, 4 April 2018 (UTC)

Restored objects - original and copy date?

Couldn't spot a scheme to tag different "start" dates - let's say of a sculpture that was constructed, then destroyed, then a copy created. For now tagged an instance with "start_date:copy". --Richlv (talk) 23:14, 26 December 2020 (UTC)

since they are really different objects, i'd say that start_date applies to the copy and something in note= or description= mentioning the prior entity is probably sufficient. over in OpenHistoricalMap we are working on using relations for this sort of situation, but that seems excessive for current OSM usage. Nfgusedautoparts (talk) 02:53, 27 December 2020 (UTC)

A lot of grey area, though - there are objects which are either partially destroyed and then restored, or so significantly restored/rebuilt, that they are almost like a different object. There's still continuity that belongs in OSM, just need decent tagging to avoid freeform descriptions :) --Richlv (talk) 09:27, 28 December 2020 (UTC)

Simply was:start_date=* until you can sort out the extent of demolished:*=*?

I believe it will be easier to come up with minor clarifications on the lifecycle tags instead of reaching a consensus on all the discussions on how much of restoring/fixing etc requires a fresh start_date and how much must keep the original one :) --Richlv (talk) 14:56, 28 December 2020 (UTC)

start_date=after 1823

The text states that start_date=after 1823 means after 1 January 1823. That feels unlogical to me. After 1823 should mean 1824 or younger thus 1 January 1824 or after. --Kogacarlo (talk) 16:59, 9 July 2021 (UTC)

Don't be bothered by that section. It really needs to be cleaned up, like start_date=before 1855 "during 1854 or before" vs start_date=before 1910-01-20 "before a specific date". The standard that should be used is ISO 8601 2019 update which incorporated Library Of Congress's EDTF. For example "Avoid seasons. For example 'summer 1998' as these vary between the hemispheres. Consider using '1998-05..1998-08' for summer in the northern hemisphere." is not accurate when the >20 special "months" are used for unspecified ("22") and northern/southern hemisphere seasons ("26"/"30") as start_date=1998-22 and start_date=1998-26. ---- Kovposch (talk) 07:39, 10 July 2021 (UTC)

Using start_date on acquired and designated lands and right-of-way (ROWs)

Do I use the start_date= tag on acquired and designated lands and right-of-way (ROWs) even before an infrastructure and structures were built (where I will determine when these lands and ROWs were titled to a particular company or institution thus they are now owned by that institution or company)? Ervin11899 (talk) 22:09, 8 October 2022 (UTC)

No. They would be landuse=greenfield or landuse=brownfield, then landuse=construction, before becoming a landuse=railway or landuse=highway. start_date=* should be when they are opened.--- Kovposch (talk) 09:04, 9 October 2022 (UTC)

Yes. I will only use start_date=* if an infrastructure, structures, or features were completed, not based on land for the structures/infrastructures and right of way (portions of an infrastructure) acquisition and designation where they will be registered or titled in the name of a particular company or institution who acquired or designated them. Thank you. Ervin11899 (talk) 12:18, 9 October 2022 (UTC)

Clarification about objects where some features changed at a later date

Example of a railway station: it opened in 1950 as name=Old name and was renamed in 2024 as name=New name. Some mappers consider we should use start_date=2024 because "New name" only exists since 2024. That would hide the fact that the station existed long before. Could we clarify the rule here? Would a namespace syntax be appropriate to indicate the start date of some features? Bxl-forever (talk) 19:20, 9 January 2024 (UTC)

No, the start_date=* is for the feature, ie railway=station . Proposal:Date namespace was proposed, but it's a bad data format. In OpenHistoricalMap, there would be more development on how this should be treated, but there is still some need in OSM to distinguish the existing status, as your question show.
There are some ~8k name:start_date=* and ref:start_date=* . It's better than the messy name:1950-2024=* to me. It works fine for a single name, well within the limits of not recording too much historical info.
However, the ~100 old_name:start_date=* is not clear on whether it means the start_date=* of that name (1950), or the start_date=* when it becomes the old_name=* (2024). It's no good to use.
In the event there are multiple name changes, a particular hacky solution I can think of here is the inevitability of using for historic evolutions in OHM. I might use a type=public_transport + public_transport=stop_area with the old name=* that has start_date=1950 + end_date=2024 . This will work fine in OHM. While some may object to the public_transport=stop_area seemingly being invalid for continuing to existing after an end_date=* in OSM, this is relevant info.
—— Kovposch (talk) 06:48, 10 January 2024 (UTC)

Hi,

The start_date is for the feature, a feature which is made of geometry and a set of descriptive tags and not simply the main tag. If we only rely on the main tag while ignoring other tags or geometry then the database will present false information :

- an old town hall and an old church are tagged building=apartments+start_date=1800, they were both built in 1800 and were transformed into apartments in 2000. Here we have false information, the feature here is building=yes not building=townhall neither building=church, so there should be start_date=2000+construction_date=1800.

- I make the same observation for the geometry which is often overlooked, a 16th century church was enlarged in 1910 by razing part of the transept and building a bell tower, the current building is larger than the previous one, the bell tower does not have the same architectural style as the rest of the church, however the church including the bell tower was tagged building=church+start_date=C16 once again this is false information, here we need at least two features:

1. building=church+start_date=1910+construction_date=16th century onwards;

2. building:part=yes+man_made=tower+tower:type=bell_tower+start_date=1910+construction_date=1910.

A railway station is an interesting case:

My local railway station building was built in 1842, building=train_station+start_date=1842 within the OSM database it is then? No, because in 1880 it was moved 2km away (geometry) then this new building was bombed in 1944 and only the walls remained (tags), so that calls for four features:

1. one in OHM with building=train_station+start_date=1842+end_date=1879;

2. one in OHM with building=train_station+start_date=1880+end_date=1944;

3. one in OHM with building=ruins+start_date=1944+end_date=1953;

4. one in OSM (the current one) with building=train_station+start_date=1953+construction_date=1880 onwards.

- On the other hand the feature train station as an amenity (not the building) with railway=station has never stopped working since 1842 and was simply moved in 1880 so this calls for only two features:

1. one in OHM with railway=station+start_date=1842+end_date=1879;

2. the other in OSM (the current one) with railway=station+start_date:1880.

And in this example I only take into consideration the railway tag, the other descriptive tags are just as important as the main one.

And if it's a complex case like those voluntarily mentioned here, we can always add a start_date:source or start_date:note or both!

Arflha (talk) 12:26, 27 March 2024 (UTC)

Your premise is definitely false, because every feature with old_name=* surely doesn't have start_date=* as the name=* now. Why should a highway=* road, or railway=rail track, have a new start_date=* simply because it's renamed? building=* has already been discussed that building:start_date=* shouldn't be used, when start_date=* refers to the building=* structure only.
OHM is still in development. There has been motivation towards separating as much attributes as possible.
I don't see what the example has to do with the question. You are only involving the building=* physical structure, which should of course be changed. The railway=station has provided significantly different service at a new location after moving. OHM has type=chronology as well.
—— Kovposch (talk) 20:49, 13 July 2024 (UTC)

Proposal to change the Key:start_date wiki page

Link to the topic on the forum. Arflha (talk) 17:13, 28 March 2024 (UTC)

Discussion in relation to planted_date=* and planted=*

There is an ongoing discussion about this tag in relation to planted_date=* and planted=*. UsefulRabbit (talk) 19:43, 13 July 2024 (UTC)