Talk:Key:start date

From OpenStreetMap Wiki
Jump to navigation Jump to search

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)