Talk:Proposed features/Date namespace

From OpenStreetMap Wiki
Jump to: navigation, search

Range separator

For range, wiki say:
When only ranges of years are specified (no month or other details) a single hyphen may be used where the standard excepts a double hyphen.

But ISO 8601 say:
Of these, the first three require two values separated by an interval designator which is usually a solidus or forward slash "/".

--Pyrog (talk) 12:08, 20 December 2014 (UTC)

ISO 8601 has "/" or "--" alternatively (according to wikipedia). Prevalent usage in Openstreetmap is something like "name:1994-2001"
Hence the current "compromise". Because it is part of key-name I am thinking that "/" in date ranges would be awkward and as few as possible special chars should be used. In particular we should resist something like the syntax mess off key:start_date.
  • single hyphen for "year-year" style ranges (because of our own backward compatibility)
  • double hyphen for "yyyy-mm-dd--yyyy-mm-dd" style ranges
RicoZ (talk) 12:45, 20 December 2014 (UTC)

Disadvantages and interpretation

Copying the section that needs clarification bellow so it can be discussed - article page is not meant for discussion.

  • it is impossible to link multiple properties with same period in time without losing consistency
name:1800-1900 = School 1
amenity:1800-1900 = school
Now your software need to check if date ranges are same. What should they do if rages are different?
  1. name:1800-1900 (1a) = School 1 (2a) + amenity:1800-1900 (3a) = school (4a)
  2. name:1799-1900 (1b) = School 1 (2b) + amenity:1800-1900 (3b) = school (4b)
  3. name:1799-1899 (1c) = School 1 (2c) + amenity:1800-1900 (3c) = school (4c)
  4. name:1796-1850 (1d) = School 1 (2d) + amenity:1800-1900 (3d) = school (4d)
How data consumers should use this data?
Should they treat (1) as different values?
Which values in (1) are same? Some? None?
How to use values (3) with respect to (1)? Somehow? Nohow?
What software should think if name timerange (1) is outside main tag timerange (3)? Is there name (2) for other feature for the period (1) or do they undefined or do they unnamed?
If example above is not clear for you, try to repeat your answers for datas with granularity of a day instead of year. Answers will be less obvious. Please define rules in proposal or somewhere at wiki.
  • this namespace schema is only about metadata. It is impossible to say what geometry of object was at moment X. OSM history shows history in OSM, not history of real object.
name:1796-1850 = School will tell you only about name, not type of object or position/geometry over time
amenity:1800-1900 = school will tell you class of the object, not position/geometry over time

Can you please expand the example with verbose values instead of "(1a)" or "(3d)" and clearly separate key/values from example numbering? I mean why you would tag "amenity:1800-1900 (3a) = school (4a)"? It is "amenity:1800-1900 = school".

  • as of linking (logically associating) multiple tags with periods of time/dateranges:
    • if the dates are exactly the same and on the same OSM object you may assume that they are logically linked.
This is wild guess. You cannot say anything even if date ranges are equal. Granularity of dates is always unknown for you.
ok, point taken. For many apps this won't matter - if you want a rendering what something looked like in January 1813 just apply all tags which are valid in January 1813. If you need to prove that some features existed over identical timespans you need something else. RicoZ (talk) 13:36, 23 January 2015 (UTC)
    • if mappers use 1799/1800 inconsistently - bad luck. The various properties of a single object do not always change at the same time so this flexibility may be good or bad.
You cannot say anything about data at all. if there name:1796-1850=ZYX, how you can say if there was name for it at 1795? How can you say if it was unnamed? What does it mean if object have amenity:1800-1900 = school, but name:1796-1850. What you should do about name during 1796-1800? What you should do about 1850-1900?
Lack of data or erroneous tagging is not an inherent problem of this data model. You may assume erroneous tagging and not display anything or incomplete data and render usable data for points in history where sufficient data does exist. RicoZ (talk) 13:36, 23 January 2015 (UTC)
  • geometry: it is possible to have different geometries over time. Draw the geometry of a "building:1929-1964=house" and another geometry tagged with "building:1965-=house", and in principle you can record every detail of the location as it changed over time. It is more difficult in the case that the geometry remains the same and only a part (like garage) of the building is added - the same overlapping geometries which are generally a problem in OSM. For objects with geometry changing over time I would prefer actually drawing overlapping geometries instead of any kind of multipolygon - because that makes it much easier to split/store/recombine objects between historic and main databases.
So? Where it was stated that you should use different geometries?
Might add it, though this is not a guide on historical mapping. RicoZ (talk) 13:36, 23 January 2015 (UTC)

One idea that was crossing my head was to use

  1. "tagname:period:daterange" or
  2. "tagname:period:period_identificator111"+"period:period_identificator111=daterange"

- instead of current "tagname:daterange". It would be much easier to search for ":period:" in tagnames and the use of period_identificators would make it easier to link features together - if indeed mappers would use it consistently. Not sure if I should push this - (1) is just syntactic sugar and (2) might be more appropriately modeled by relations. RicoZ (talk) 13:04, 22 January 2015 (UTC)

It should be clearly stated that without explicit indicator information about equal timeranges cannot be restored only based at "equal" time ranges. Time is continuous, you can only specify it up to some precision. Xxzme (talk) 06:36, 23 January 2015 (UTC)

This is a proposal

This a proposal and should be treated as such. I don't see a healthy discussion about implementation and tagging. The concept was added in 2009 as far as a I can see. Perhaps getting a statistic (one try) would get a better overview. I propose to add a Template:Proposal_Page Template.--Jojo4u (talk) 20:00, 4 August 2015 (UTC)

I tried to get an estimate of usage by doing an overpass query and post processing the results, there seems to be in the order of a few hundred uses - do not recall the details anymore. It is quite hard to get more precise results because often multiple tags with several date namespace suffixes apply to one object. Also did not find any really good way to do the query.
Don't think adding a proposal page at this point makes much sense, it will never be used widely unless historical mapping adopts it for their database and then it is their stuff. Otoh some examples like Adolf Hitler Straße or Istambul exist which are prominent enough and changed names many times to warrant existence and documentation of this. RicoZ (talk) 09:26, 5 August 2015 (UTC)
A good reason to move this to the proposal namespace (not add a separate proposal page) would be to prevent the impression that this is somehow recommended tagging. --Tordanik 11:11, 14 August 2015 (UTC)
There is so much else purely tentative content in the "main namespace" that has never been approved or recommended that overcrowding the proposal namespace with things which aren't even proposed may be worse. RicoZ (talk) 15:38, 17 August 2015 (UTC)
This should not hinder the movement of this page. We can hunt them down one by one.--Jojo4u (talk) 23:18, 22 May 2016 (UTC)
done--Jojo4u (talk) 23:23, 22 May 2016 (UTC)


There should be no key for which statistics via overpass or via taginfo are not possible. Perhaps it would be best to be more verbose. E.g. name:date(1965--1971-12-18) = schoolor name:date[1965--1971-12-18] = school. Taginfo has some key character statistics to play with: --Jojo4u (talk) 13:41, 22 October 2016 (UTC)

The []-brackets are also used by traffic_sign=* in the value: Where the traffic sign requires a value, you can supply it after the ID using brackets [value]. The value may contain a dot . as decimal separator and a minus - for negative values.--Jojo4u (talk) 13:41, 22 October 2016 (UTC)

Historical routes

Would this way: 6676219 mapping of historical (train) routes (on existed and visable signs) be correct?