Proposal talk:4th Dimension

From OpenStreetMap Wiki
Jump to navigation Jump to search

API feature

The fourth dimension should be implemented server side.

  • Default behaviour should be to only retrieve objects that are valid at the current date and to reject any changes to the time values to avoid accidental changes.
  • There should be an API call to retrieve objects valid at a given date. No changes to time values possible in this mode.
  • There should be an API call to retrieve all objects regardless of time values. Changes to time values should only be possible in this mode where you see all entries in order to avoid mistakes and duplicates. --Nop 10:16, 5 June 2009 (UTC)

deprecate time tags

As we found in the previous discussion, simply using start/end tags disrupts all existing tools that are only interested in current data and would need to evaluate all of these tags for all objects. Therefore the existing tags like start_date and end_date should be explicitly deprecated and replaced by whatever mechanism comes out of this proposal. --Nop 10:16, 5 June 2009 (UTC)

I agree that they should be deprecated, if we can move their functionality into the core API itself. However, for the time being, start_date=* should be allowable, as this doesn't disrupt any existing tools. Plus, we can migrate the dates from this tag to the API methods if/when this is available. Frankie Roberto 18:27, 24 June 2009 (UTC)
I wasn't a part of the previous discussion, so please excuse my ignorance. Is it possible to use start_date and end_date, but avoid the need for existing tools to "evaluate all of these tags for all objects", but using the API to act as a filter on these tags? Is there a need for the "mechanism" you refer to to be something other than a tag? I like tags...what else is there? --Waldo000000 03:01, 19 August 2009 (UTC)
Only a very small part of people is interested in historic dates, so why should the API do so much work filtering it at each request? It is more sensible to add a small amount of data from a second database when needed in this seldom usecase. --Lulu-Ann 12:15, 19 August 2009 (UTC)
This is a valid question to ask. Clearly, writing the required API changes and making sure they don't have a detrimental performance effect is a significant amount of work. However, I don't this the proposers of this concept are demanding that other people do this work. It's up to us to argue the case, and to demonstrate the proposal with some working code. That will take time, but then, there's no particular hurry. In the mean time, adding start_date=* tags to features which currently exist has no negative impact on existing tools, and so I don't see any reason why these should be in a separate database. Frankie Roberto 10:32, 20 August 2009 (UTC)
If the object no longer exists, the object shall not be in the standard database, if it has a known start date or not. And I still got no answers to my question how a historic site like Bethlehem with churches built over churches shall be mapped at all. There is no concept, I am afraid. --Lulu-Ann 20:49, 20 August 2009 (UTC)
Shouldn't it be possible to set start_date=* and end_date=* to tell the API in what time-frame the object should be intended? For example, if I know the opening of a road is on the 1st of January, than I would set end_date to highway=construction+construction=motorway and start_date highway=motorway to January 1st so that it comes into the database correctly. That will also be the only sane solution for adding historic objects. But you are absolutely correct about the API taking care of start and end dates, relieving us from using them as complicating filters for any normal map rendering. When I download current data to generate a map, than I am not interested in seeing loads of past objects with end_date=* several years before I was born. --Skippern 22:46, 19 December 2009 (UTC)

ways to do it

Just to see the ways to do it, here's a list of the possible ways to mark features that can't be found on the ground right now, but will or might be built later or have been removed. Let's keep the list clear of discussion (discuss below it) but add your solution if it isn't there. Alv 17:13, 6 June 2009 (UTC)

  1. add any of start_date=* end_date=* abandoned_since=* disused_since=* (or others) to indicate features not currently existing, but being planned or having existed. "rejected"
    • An application must know all of those tags for all features to check if the feature exists now
  2. use tags like disused=yes construction=yes archaeological=yes planned=yes dismantled=yes
    • see case 1
    • except for some disused physical features; they're still there. Disused amenities are no longer amenities.
  3. use a set of prefixes for the key:
    • a former supermarket is tagged as was:amenity=supermarket
    • a planned park is tagged as planned:leisure=park
    • a runway under construction would be planned:aeroway=runway landuse=construction
    • then combined with completion_date=* or end_date=* (or other) they can be checked for completed construction or the user gets to know when their existence started/ended
    • software should discard any keys it doesn't know - a planned park won't be shown
      • should then all tags be changed, for example name=* -> was:name=* as it would likely still be shown without the feature?
    • possibly lots of "old" features make editing difficult as they occupy the same space as the features built later
      • Could be supported by the API, as in not to normally return features for which all the tag keys begin by 'was:' or 'planned:'. The API developers are, for a reason, adversely reluctant to include any special handling for any keys or values; the API doesn't care what the data is.
  4. use a set of values for indicating past or future features
  5. add removed (or planned or... ) features to a relation with lifecycle=removed (or similar)
    • software must always check the relation and the tags for every feature. See case 1.
  6. Make more changes to API
    • Api would hold for all features the dates when they existed
    • Api would be modified to return only objects of a specified, or current time
    • Restrictions on updating "not-current" objects would require much changes in editors, too, as they would have to make a distinction between the current objects and the "restricted objects" so that they could return them with appropriate information ("yes, I had all the historical data") so that the Api would allow the updates.
-- Erm shouldn't software that is displaying this information decide when information should and shouldn't be displayer, rather than the API? -- Delta foxtrot2 12:10, 18 December 2009 (UTC)
This would mean that everyone would download unwanted decades of data whenever current data is managed. --Lulu-Ann 20:56, 19 December 2009 (UTC)
Software can decide the timeframe it is interested in by altering the API call, the filtering of the data MUST be in the API, as downloading the entire history when you want only a narrow timeframe is a waste of resources such as server bandwith, user bandwidth, user storage space, software memory usage and not to forget time. --Skippern 22:49, 19 December 2009 (UTC)
I don't agree. Leave the api alone, add the historic data whenever needed. This method causes the least work and no change in OSM. --Lulu-Ann 14:21, 20 December 2009 (UTC)
You're right, this is rather the job for an extended API, not the main API. Whether or not it is in the main database or an "historic" database is not relevant as adding a simple filter for boolean historic in the main API is simple and will not change the way it works. How to solve this practical should not be the job for the main API/Protocol/OSMF work groups, but rather a special 4th dimension work group, and any implementation to OSM should not occure until they have done satisfactory tests on a development server. There should be no changes in the main API in the way it works for the users and the software most of us uses. --Skippern 17:51, 20 December 2009 (UTC)

7. Add a second Database for Features, which are not currently existing, so, that all Features belonging to the 4th Dimension Project would be added to this second Database. Editors could then let the Mapper the Choice which Database to use for Downloads and Uploads, having OSM be the Default Database. Editors should be able to move a Feature from the OSM Database to the 4th Dimension Database or vice versa, if and when current Existence of the edited Feature changes from current to abandoned/removed or from planned to current, respectively. The 4th Dimension Database could either be stored on the same Servers as the OSM Database or on other Servers. (Using "# " to start this next Entry as Number 7 somehow didn't seem to work. As this is my first Entry to the Wiki, please excuse me and if You can, change it, so, that it works.) --MarcusWerthmann (talk) 01:20, 24 October 2015 (UTC)

Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=Proposal_talk:4th_Dimension&oldid=2511508"