[OSM-talk] Historical Data in OSM database

[Peter Wendorff]

Am 09.11.2010 17:01, schrieb M∡rtin Koppenhoefer:
> 2010/11/9 Peter Wendorff<wendorff at uni-paderborn.de>:
>> If it would be as simple....
>> I fear, it is not.
>
> +1
>> often jewish synagogues especially in Germany burned
>> down by the Nazis, too few of them rebuild - like the one in Berlin
>> Oranienburger Straße[1]).
> that's actually a special case because it is one of the very few that
> actually wasn't burnt down
yes, but it's destroyed by bomb attacks to Berlin later - so it remains 
a rebuild synagogue ;) .
>> Big churches are often build over a time of several hundred years, changing
>> shape and importance, even name - not to mention denomination or more than
>> that religion) - think about Notre Dame in Paris [2] with a build time of
>> nearly 200 years.
> think of the cathedral at Cologne, built for over 600 years...
> These are not exceptions, almost every house dating back to the
> middleages and remaining till today was continuously transformed
> through the ages. Most of this is not suitable for out database,
> because it would require a much higher level of detail and probably
> 3D-geometry.
>> That in mind as examples - far from complete - neither start_date nor
>> start_date and end_date are enough to describe historical data in a good way
>> to be useful.
> depends how you apply it, but yes, it is not sufficient for a higher
> level of detail.
>
> I think that historic mapping is less interesting/possible/feasible
> for the past, but it is very interesting for the future: as someone
> mentioned above, currently we have no way (besides textual changeset
> comments) to denote if a feature is changed or deleted because it was
> bad (wrong) or because the actual feature has changed. If you look in
> well mapped areas like big parts of Germany, we are about to come to a
> certain point of "completeness". In these areas it would be quite
> interesting (given that our project will endure ;-) ) to actually tag
> things that change or get destructed with appropriate
> (changeset-)tags/attributes. This way we could make better use of the
> history information already existing in our db and have "historical"
> mapping from now to the future.
+2

regards
Peter