[OSM-talk] Historic Mapping needs help Now!

[Joseph Reeves]

I'll happily donate the openpastmap.org domain towards an attempt at
this. Will *possibly* be able to get a VM or two, plus some bandwidth,
through my employer, if we ask very nicely... ;-)

Cheers, Joseph



2009/8/18 John McKerrell <john at mckerrell.net>:
> I also believe that historic data should be stored in the database. I tend
> to think that it should just go in the end_date & start_date fields and
> someone "simply" needs to modify osmosis or whatever is used to feed .osm
> data into postgres these days so that it filters out anything that doesn't
> fit the current date. I've heard various people say they basically want
> something like this since SOTM so I think people should just go ahead and do
> it. Make the action happen by default in osmosis (and/or other tools) and
> people will soon fix any broken tags. I suppose the issue then is when you
> want something to appear even though it's not really there currently, I
> think that would be best done with another tag e.g.
> "not_a_valid_date_but_please_render_anyway_please=yes" (but with a sensible
> name) Perhaps things labelled with that would have opacity 50% by default.
>
> John
>
> On 18 Aug 2009, at 15:39, Joseph Reeves wrote:
>
>> I imagined a system whereby the default rendered map page looked much
>> the same as the current Mapnik example, the only difference being the
>> addition of a second slide-bar that changed the temporal view. By
>> default you'd look at the map of the present day, but by pulling the
>> slide down (or across...) you'd go back in time and features would
>> disappear / appear accordingly.
>>
>> The Burning Man example would show the current state of things as they
>> exist on the ground today, pull the slider back and you'll change to
>> last years... Likewise for any country / area you'll be able to do the
>> same.
>>
>> The technicalities of adding this data to the database could be tricky
>> - perhaps a similar slider should be added to whatever interfaces
>> people use (would be an issue for features that no longer exist
>> cluttering the view), but or stuff that is on the ground today, it
>> should be possible to just add a start_date tag.
>>
>> As for old versions of the OSM database, these would be very
>> interesting for charting the growth of the map and for adding a
>> historical dimension to a study of OSM, but the historical data should
>> all be stored in the current database. We should look into adding
>> chronological data to the data we already have. Adding this to the
>> database shouldn't be too hard, I can find out when the office
>> building I'm sat in at the moment was built, for example, but
>> rendering the temporal element could cause headaches...
>>
>> More than willing to work on such an endeavour, however...
>>
>> Cheers, Joseph
>>
>>
>>
>> 2009/8/18  <simon at mungewell.org>:
>>>>>
>>>>> Ideally there would
>>>>> be a start_date and end_date tag also that defines the period when the
>>>>> object was present.
>>>>
>>>> +1
>>>>
>>>
>>> So, I think that the question is related to whether you want something in
>>> the current dataset to represent the things that were 'here' at a
>>> previous
>>> time or have a way of entering 'new' historical data.
>>>
>>> Taking the burning man festival example - could you add an area tagged
>>> with snapshot date (rather than tagging individual items), which
>>> indicates
>>> that this portion of the map requires the renderer to 'find' historical
>>> OSM data from that date?
>>>
>>> This would remove the need to tag a lot individual items, but does not
>>> prevent a scheme where it would be possible to add 'new' historical data
>>> into the OSM data with start/stop dates.
>>>
>>> As for rendering, would this area be given a sepia tone? :-)
>>>
>>> For someone like flickr I would imagine that they would always want to
>>> render the historic portions, so would likely keep the 'old' snapshots of
>>> OSM data to hand.
>>>
>>> Cheers,
>>> Mungewell.
>>>
>>>
>>
>> _______________________________________________
>> talk mailing list
>> talk at openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk
>
>