Proposal talk:4th Dimension/Archive 1

From OpenStreetMap Wiki
Jump to navigation Jump to search

Use for historical features

I think that's something we (in Italy) were waiting: mapping archaeologic cities (such like Pompeii) we need to distinguish modern features (like drinkable fountains in rock) from modern (like normal fountains in rock). A tag more or less like this, but to have a standard should be more clean.

Other, similar concepts

See also

We are also already using railway=disused and railway=abandoned, and some of the values used for Key:historic refer to things that have ceased to exist.

Force all existing tools and renderers to change?

I strongly oppose this proposal in the current, simplisitc form.

I don't mind about the idea of mapping past and future things. But if you just add a few "existed"-tags for this, every editor, every renderer, every tool will need to be changed to evaluate and filter them. If not, your new tags are ignored and all past and future data is intermingled with current information, messing up all maps and databases. In my eyes, this makes this a most incompatible and invasive proposal.

If you want to establish a fourth dimension you would have to move this to the API so that all existing tools receive current data only or you should find a tagging scheme that does not interfere with all existing tool chains. --Nop 09:21, 22 May 2009 (UTC)

I agree with Nop, there must be a extension in API level also, not just a tag. So current apps and renderers just do not see this non-current data by default --Jaakl 14:25, 22 May 2009 (UTC)
If you put it that way, I have to agree as well :-). But I dont know anything about the API, so I hope that the work of getting this integrated will be done (or thought about) by others. --Peter Dörrie 14:59, 22 May 2009 (UTC)
Agree, should definitely be implemented in API. Which is more complicated, but do-able (eventually). Frankie Roberto 16:22, 29 May 2009 (UTC)

I like the idea of being able to only show current objects on the default maps. Mapnik currently shows abandoned railways which I find very annoying - yes they used to exist, yes they sort of exist now but only as a barely distinguishable bump on the landscape, no they are not prominent enough to warrant a place on the general maps. Tag them and show them on a specialist map: OpenOldRailwayMap. Your scheme would mean tagging everything, which is completely absurd. We should only tag the cases of 'not here now', so tag old, abandoned, disused, historic or ancient things in a way that marks them but doesn't display on the contemporary maps. When something becomes 'not here now' simply add the appropriate historical tag and it will disappear from the contemporary map but still be available to the specialists. You can use similar tags for future things like planned roads. Chillly 13:06, 22 May 2009 (UTC)

Why is tagging everything absurd? We are already tagging everything some way or another and enhancing this by a standardized tagging scheme for a timeframe would be very helpful and interesting for a whole range of applications. Just tagging "not here now" is in my view not sufficient, as it does not say anything about when it started to be here and when it ceased to exist. --Peter Dörrie 14:56, 22 May 2009 (UTC)
Because it means adding a large amount of data, (start and possibly end dates dates to everything) yet much of this is unknown. When was the road through the centre of my village created? It was a track (on a somewhat different course) about 1500 years ago. No one knows exactly where it went, or when it was started and when the many times it changed nor how each change occured. We don't even know when it was mettled for the first time and that lies within living memory. I know this because of the research done on the history of the village about which three recent books have been written which I contributed to. This is just one road. I think adding some dates for some significant features (what ever they are) might be useful. Using a tagging scheme that makes abandoned or superceded things cease to be rendered yet leaves the data for specialist uses seems a good idea to me, but I repeat, tagging dates on every object is absurd. Chillly 10:31, 25 May 2009 (UTC)
If you dont know the dates - dont tag them. If you dont like to tag those dates (even if you know them) dont do it. I (usually) dont include park benches in my mapping, because I dont consider them important enough. Same thing with single trees. But I would consider historic informations as very important. If you have other priorities, thats no problem to me. --Peter Dörrie 10:44, 25 May 2009 (UTC)

time/date-zone

I like you're tags because they are simple an clear (apply to everything, just two tags). That's why the third one seems a bit out of logic to me: "If the date is before Christ: existed_since_bc=yes / existed_till_bc=yes". This is no more generic but very specific. I would like to see either dates before christ with "-" (minus), like name=Roma, existed_since=-0753 There could be nevertheless a tag for indicating the used time reference system (where AD / BC is standard and obsolete), e.g. chinese calendar, egyptian, maya, dates before certain calendar reforms, etc. -- Dieterdreist 13:20, 22 May 2009 (UTC)

You are right, the _bc scheme is redundant. I removed it. --Peter Dörrie 15:02, 22 May 2009 (UTC)

4th Dimension extended

I suggest that general time tagging scheme should be made. Just some ideas what time dimension would enable more. Maybe some general pattern will appear.

  • historical objects/maps, like proposed here. Date accuracy should be ok (2 dates/centuries)
  • time-dependent roads (regular closing, one-way changes). Relevant for better routing, but quite rare. Minute accuracy data, regular patterns.
  • POI activity. Opening hours of a business (regular, daily). Festival event dates (e.g. one weekend). Very usual, minute accuracy, regular patterns usually.
  • Natural objects. Shoreline (tides), icebergs. Minute/hour accuracy, could be regular patterns.
  • Dynamic human objects. Real-time location of public transportation. My location traces.
  • Storing data about building (and demolition) dates of normal objects (roads, buildings, anything man-made and sometimes even natural).

So the time tagging scheme should also enable to mark any changes in database: was the road added because it new road, or because it was not in map yet. It is very important difference. Then, after some centuries, OSM would have nice data to generate historical maps.

--Jaakl 14:42, 22 May 2009 (UTC)

You are right, one should use that to introduce a broader time-tagging scheme. Than it may also be easier to justify a change in the API, as proposed by others. I will change the Proposal accordingly and hope that we will get a comprehensive discussion on which existing tags to include into that scheme. --Peter Dörrie 15:07, 22 May 2009 (UTC)

4th dimension must go into 2nd database

... there is just no space for crossings with current and historic roads. --Lulu-Ann 16:59, 22 May 2009 (UTC)

No space in the sense of no disk space? Please clarify I don't exactly understand this (which is likely due to my incomplete technical knowledge ;-) --Peter Dörrie 18:40, 22 May 2009 (UTC)
Not disk space. No space for historic roads that cross current roads. Mappers will just get confused. --Lulu-Ann 21:23, 22 May 2009 (UTC)
This is why we should find a way so that this type of data is not shown in editors by default--Peter Dörrie 07:40, 23 May 2009 (UTC)

I think that the discussion about having separate databases for some material has already been had, and the idea dropped? All the data should be available in the core database, but secondary databases may provide faster access to some sub-set of it. There are several layers of 'history' that are not currently being managed well, but they form an important part of the information being stored. The VIEW of the rendered maps is not a problem, and someone providing 'historic' rendrings is probably a secondary 'database' but reading raw data should either return ALL data, or filtered to a date. The problem I'm seeing is that 'abandoned' and 'disused' relate to structures that may physically still exist - like the railway line at the bottom of my garden - but only the track has been lifted, and I expect to see that replaced before I die. 'end_date' should identify when a feature actually ceased to exist physically and can therfore be filtered from the data set? Lsces 07:14, 23 May 2009 (UTC)

The important part is in the last sentence. It is not enough that they can be filtered, past and future events should be filtered by default. Including them is the special case and should only occur upon special request. --Nop 09:25, 23 May 2009 (UTC)
I agree, all data should be in one database. Subsets dont make sense to a project like openstreetmap (I think so at least). --Peter Dörrie 07:41, 23 May 2009 (UTC)
If you force 100 existing applications to filter out data only you want to add, you will gain 100 votes against you from the 100 programmers. --Lulu-Ann 09:51, 23 May 2009 (UTC)
Exactly. +1 --Nop 11:34, 25 May 2009 (UTC)
The problem with that statement is that it requires a 'delete' policy to be defined on how information currently contained in the existing database will be removed if people fell it is no longer appropriate! Something that has - up until now - been avoided. If a feature is going to cease to exist at some point in the future - how do you plan to handle it? Lsces 07:10, 25 May 2009 (UTC)
This is not about features, this is about objects. If a house no longer exists, it will be removed from the database. I don't see the problem.
If historic data shall be recorded, then I would like to see as an example how Betlehem looks, with lots of churches build over another.
And if any object will be disconstructed in the future, then the construction tag can be used with an extended date key. --Lulu-Ann 09:58, 25 May 2009 (UTC)
Well I dont like the idea that just because a house does not physically exist any longer, we are deleting it without comment from the map. Maps have always been a very valuable source of historic information. There are a lot of very important geographic theories, that wouldnt have been possible without historic map data. I dont say that the proposal is perfect (it is not even complete yet), but I think that OSM needs something like this. After all, we didnt burn our paper maps, just because they werent up to date any longer...
Concerning the Betlehem question: well for the normal end-user and mapper it should obviously look the same as it does today. But it should be possible to download all objects, that got demolished before 2000. I really dont see how something like this should be a problem.
Well and about all this "all applications will have to change": As far as I know (please correct me if I am wrong) all applications have to change with every API upgrade anyway. I cant see any developers voting against API upgrades because of that. --Peter Dörrie 10:57, 25 May 2009 (UTC)
That is completely wrong. Only those tools that down/upload directly with the API need to change. All other tools working from planetfiles, databases etc. remain the same. And the change is only syntactical for the API access, the change is never about parsing, evaluating and filtering all data. --Nop 11:34, 25 May 2009 (UTC)
Ok, thanks for the clarification.Than this would be a problem obviously. But I would still really like to have this. So how could we do it without disturbing the developers? --Peter Dörrie 16:54, 25 May 2009 (UTC)
Use another database and add your information as overlay to the OSM map if needed. --Lulu-Ann 08:22, 26 May 2009 (UTC)

Separate Project?

The concept is noble, but there are problems with this approach. Automatically "archiving" any feature any user wants to delete or alter is a logistics nightmare to get the editors to do proper bookkeeping. And then either the API has to be changed to return only current data (or data for a specified time), or every application has to be further changed to filter the data individually. It's also flawed semantically; when an editor deletes an object, is it because the object no longer exists, or because it was wrong? (TIGER data sometimes contains roads that never existed. It also regularly contains poorly drawn roads that have to be fixed, but that change does not represent change in the actual road.) Old planet dumps are archived somewhere, right? Well that's just as good as keeping old paper maps. Having a 4-dimensional map would be cool, but it would have to be built manually (not from routine changes to the "now" map) and I don't see how it would fit into the OSM project.

The good news is, if enough people are dedicated to this, a separate project can be started. And this separate project can re-use data and technology from the main OSM project. Someone could work on some relatively-streamlined (but not entirely automated) process for using OSM planet dumps and diffs to find genuine recent changes in the world. People who know historical details about stuff can help build up the "backstory" of the world. (Perhaps some of the micro-mapping features from OSM should be omitted in this hypothetical 4D map, for storage and other logistics concerns.) Vid the Kid 02:22, 10 August 2009 (UTC)

Poll for opionion

  • I don't like this proposal. --Lulu-Ann 09:51, 23 May 2009 (UTC)
  • I like this proposal. But I think it should be worked on, so that it does work out in the right way. --Peter Dörrie 10:29, 23 May 2009 (UTC)
  • I don't like this proposal. and I think end_date should be removed as it has the same problems. --Nop 11:19, 24 May 2009 (UTC)
  • I inappropriate this proposal. This is not the right time or place for THIS poll. A decision on whether ANY historic data should be recorded needs to be discussed first? Lsces 07:14, 25 May 2009 (UTC)
What is a decision pro historic data good for, if there is no good proposal how to store the data? It's easier to reject all ridiculous tries. --Lulu-Ann 09:53, 25 May 2009 (UTC)
  • I don't like this proposal. This is just bonkers --TomH 07:53, 25 May 2009 (UTC)
  • I like this proposal. to the idea of mapping temporal data. Obviously needs a lot more thought and discussion first though. (And I'm not sure what this poll is for at this early stage).
  • I don't like this proposal. The concept is noble, but there are problems with this approach. Further details in another section. Vid the Kid 02:14, 10 August 2009 (UTC)

Great Idea

I don't know anything about any of the technical/programming elements to this but it would be very interesting, and no doubt valuable, to create a map whereby a date could be selected and the map would render how the area would have looked then, e.g. selecting 1800 and the renderer showing what existed then. Of course this would require a huge amount of work with regards mapping, so perhaps it would be best only to start with small areas where the history is well documented, such as city centres or areas with a long history of mapping. One of the best ways, it appears, to cut the workload down is to have dates of existence for various things, as is proposed on this page.

I strongly support this proposal.

Maybe you want to work with the Historical OSM people? They have an active mailing list, too. --Tordanik 19:20, 8 February 2013 (UTC)
Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=Proposal_talk:4th_Dimension/Archive_1&oldid=2511514"