2010/11/15 Russ Nelson nel...@crynwr.com:
Laurence Penney writes:
In principle, historic data is an orthogonal project.
Except when it leaves traces that can be found on the ground.
I completely agree, and like to add, that those traces in most cases
will be in some form or another there
Laurence Penney writes:
In principle, historic data is an orthogonal project.
Except when it leaves traces that can be found on the ground. For
example, the New York, Westchester Boston railroad is gone north of
the city, but you can find buildings with odd shapes. They're odd
because the
2010/11/12 Peter Wendorff wendo...@uni-paderborn.de:
start_date, as you see in this example, is a generic tag, like e.g. width
is.
Refinements like start_date:construction, start_date:usage;
start_date:planning; start_date:disusage; start_date:abandonment are
possible - but start_date should
2010/11/12 Andrew Zaborowski balr...@gmail.com:
Actually the Sagrada Familia is a good example of the problem with
modifier tags like width: it's not clear which feature they apply to
if one node or way or relation represents more than one feature. The
IMHO width on a node is problematic in
Martin Koppenhoefer wrote:
I think this has to be done, and it can be done. We could invent a way
to flag stuff that we remove because it ceased to exist as such, and
The solution that works right now, even if it is a bit laborous
sometimes: first prepend all keys with was: or past:
(for
Andrew Errington wrote:
It would be more logical to have the date construction started be
start_date, and the date construction completed be completed_date.
Having the completion date tagged as start_date doesn't make sense.
I agree. We have this 'opportunity' in Korea to record the start
2010/11/11 Laurence Penney l...@lorp.org:
On 11 Nov 2010, at 20:30, M∡rtin Koppenhoefer dieterdre...@gmail.com wrote:
IMHO the wiki is clear here: start_date is the date the construction
of feature finished. It is not about the construction being
commissioned or started.
The wiki may be
2010/11/11 j...@jfeldredge.com:
It would be more logical to have the date construction started be start_date,
and the date construction completed be completed_date. Having the completion
date tagged as start_date doesn't make sense.
I disagree, because start_date is the beginning of the
2010/11/12 Andrew Errington a.erring...@lancaster.ac.uk:
At the moment there is are 'temporary' tags to record this:
construction_start_date=2003-05-09
construction_end_date=2004-12-09
IMHO those are fine. If you use them regularly might be worth to
document them as feature in the wiki so
On 12 Nov 2010, at 11:57, M∡rtin Koppenhoefer wrote:
2010/11/11 Laurence Penney l...@lorp.org:
On 11 Nov 2010, at 20:30, M∡rtin Koppenhoefer dieterdre...@gmail.com wrote:
IMHO the wiki is clear here: start_date is the date the construction
of feature finished. It is not about the construction
Am 12.11.2010 12:00, schrieb M∡rtin Koppenhoefer:
2010/11/11j...@jfeldredge.com:
It would be more logical to have the date construction started be start_date,
and the date construction completed be completed_date. Having the completion
date tagged as start_date doesn't make sense.
I
On 12 November 2010 12:28, Peter Wendorff wendo...@uni-paderborn.de wrote:
start_date, as you see in this example, is a generic tag, like e.g. width is.
Refinements like start_date:construction, start_date:usage;
start_date:planning; start_date:disusage; start_date:abandonment are possible
-
The problem is, and therefore it's not possible to get a good solution
without changing the database layout: history information apply to
attributes, not to objects, but tags only apply to to objects as a whole.
That's also a problem at some other issues discussed repeatingly, e.g.
different
On Wed, 10 Nov 2010 22:25:19 +0100
Laurence Penney l...@lorp.org wrote:
For the record, I'm 100% against OSM becoming a place for general
historical data unless, at the very least, it's been proved that this
kind of historical geodata can work well in a parallel database, and
shows no sign of
2010/11/11 Lester Caine les...@lsces.co.uk:
Perhaps what is actually wrong IS differentiating between version history
and 'changes to reality'.
I think this has to be done, and it can be done. We could invent a way
to flag stuff that we remove because it ceased to exist as such, and
could
2010/11/10 Richard Weait rich...@weait.com:
On Wed, Nov 10, 2010 at 2:51 PM, Laurence Penney l...@lorp.org wrote:
By comparison, start_date, may well be used to note the construction
date or commissioning date of a bridge, but might also define the
seasonal hours of a tourist attraction only
On 11 Nov 2010, at 20:30, M∡rtin Koppenhoefer dieterdre...@gmail.com wrote:
IMHO the wiki is clear here: start_date is the date the construction
of feature finished. It is not about the construction being
commissioned or started.
The wiki may be clear but that doesn't mean it's any good.
M?rtin Koppenhoefer dieterdre...@gmail.com wrote:
Perhaps what is actually wrong IS differentiating between version history
and 'changes to reality'.
I think this has to be done, and it can be done. We could invent a way
to flag stuff that we remove because it ceased to exist as such,
It would be more logical to have the date construction started be start_date,
and the date construction completed be completed_date. Having the completion
date tagged as start_date doesn't make sense.
---Original Email---
Subject :Re: [OSM-talk] Historical Data in OSM database
From
On Fri, November 12, 2010 06:46, j...@jfeldredge.com wrote:
It would be more logical to have the date construction started be
start_date, and the date construction completed be completed_date.
Having the completion date tagged as start_date doesn't make sense.
I agree. We have this
Lester Caine lester at lsces.co.uk writes:
As I said ... adding the dates on which the new roads appeared around the
Olypmic village, or a new motorway spur or residential road was opened will be
history in 100 years time but costs nothing to add today?
When something exists today, it would be
Ed Avis wrote:
As I said ... adding the dates on which the new roads appeared around the
Olypmic village, or a new motorway spur or residential road was opened will be
history in 100 years time but costs nothing to add today?
When something exists today, it would be nice to add the date it was
Ed Avis e...@waniasset.com wrote:
As I said ... adding the dates on which the new roads appeared around the
Olypmic village, or a new motorway spur or residential road was opened
will be history in 100 years time but costs nothing to add today?
When something exists today, it would be nice
Dear list,
Many thanks for all the responses. I'll try to summarise them as I
understand them:
o At the moment storing the information in the main database would/may
cause problems for some OSM tools, so would be best to keep it
separate for this reason alone.
o
It would be good to have consistency in the start_date value. Taginfo reports
18313 usages (2814 distinct), of which these are examples of values other than
simple 4-digit years[1]:
1986-08-21 29/09/2006 05/01/2005 2002-12-31 03/12/2004 2001-07-12 20101012
Nov␣2007 1.1.2012 1966␣restauriert
On Wed, Nov 10, 2010 at 2:51 PM, Laurence Penney l...@lorp.org wrote:
It would be good to have consistency in the start_date value. Taginfo reports
18313 usages (2814 distinct), of which these are examples of values other
than simple 4-digit years[1]:
[ ... ]
So it's clear there's a demand
For the record, I'm 100% against OSM becoming a place for general historical
data unless, at the very least, it's been proved that this kind of historical
geodata can work well in a parallel database, and shows no sign of interfering
with the task of mapping the world as it is. In my first
On Wed, 2010-11-10 at 22:25 +0100, Laurence Penney wrote:
For the record, I'm 100% against OSM becoming a place for general
historical data ...
Just out of interest, are you 100% against OSM keeping recent history
data? If a building is demolished, do you believe that deleting the way
should
On Wed, Nov 10, 2010 at 5:31 PM, David Murn da...@incanberra.com.au wrote:
On Wed, 2010-11-10 at 22:25 +0100, Laurence Penney wrote:
For the record, I'm 100% against OSM becoming a place for general
historical data ...
Just out of interest, are you 100% against OSM keeping recent history
On 10 Nov 2010, at 23:31, David Murn wrote:
Just out of interest, are you 100% against OSM keeping recent history
data? If a building is demolished, do you believe that deleting the way
should remove any trace of that from OSM, or do you believe that OSM
should retain a history?
Of course
Hi,
David Murn wrote:
OSM, by its nature, is excellent for retaining historic data, for
example if a road is realigned, you have a history that shows how it was
realigned, or if a road changes name, there exists a history of previous
names.
I think that you, just as almost everyone else in
Laurence Penney wrote:
On 10 Nov 2010, at 23:31, David Murn wrote:
Just out of interest, are you 100% against OSM keeping recent history
data? If a building is demolished, do you believe that deleting the way
should remove any trace of that from OSM, or do you believe that OSM
should
On 11 Nov 2010, at 01:08, Nathan Edgars II wrote:
Laurence Penney wrote:
Of course the history trace is a very valuable thing about OSM. By
contrast, adding things which don't exist any more - mapping the past -
is, as Richard Weait says, orthogonal to OSM.
Not necessarily; historic roads
On 11 November 2010 00:45, Frederik Ramm frede...@remote.org wrote:
David Murn wrote:
OSM, by its nature, is excellent for retaining historic data, for
example if a road is realigned, you have a history that shows how it was
realigned, or if a road changes name, there exists a history of
On Thu, 2010-11-11 at 00:45 +0100, Frederik Ramm wrote:
Hi,
David Murn wrote:
OSM, by its nature, is excellent for retaining historic data, for
example if a road is realigned, you have a history that shows how it was
realigned, or if a road changes name, there exists a history of
David Murn wrote:
I think that you, just as almost everyone else in this discussion, are
wrongly mixing OSM's revision history and true on-the-ground history.
I understand the difference, but what Im saying is on the small scheme
of things, with only a couple of years data, that is the
On Tue, Nov 9, 2010 at 7:44 AM, Lester Caine les...@lsces.co.uk wrote:
The main reason that I am wanting mapping information is exactly because I
am looking at genealogical data and this most definitely requires that start
and end dates are accurately recorded. In many areas of the world
On Tue, Nov 9, 2010 at 9:03 PM, Pieren pier...@gmail.com wrote:
And without going back to the ancient Rome, every day some OSM data become
obsolete (shops dissapearing, builings/roads destroyed, etc) and the average
contributor will just delete them and not just add a tag 'end_date'.
Just a
Richard,
On 11/09/2010 01:23 AM, Richard Palmer wrote:
I can continue to do this using a standalone copy of the OSM database
but would prefer it to be made available for other people to
improve and add to.
There are three reasons not to do this:
1. Mappers are not
Frederik Ramm wrote:
All these things could be fixed with time if there was sufficient
interest but it will require a lot of work and perseverance.
For now, I suggest that you keep your separate database. You can link
your objects to OSM objects by their ID if you want, and process the
daily
If you prefix tag keys of historic elements with past:, it will not
interfere with extisting SW conserned with rendering the present state.
Examples: past:building=y, past:highway=... At the same time it
should be easy to render historic maps based on existing styles.
I doubt that
We (EntropyFree) made a tentative start towards this a year or two ago at
OpenHistoricalMap.org - but although the resources needed for it didn't come
through, there was an incredible amount of interest in it. Essentially it
was planned to be a customised SM server instance with some backend
On 09/11/10 12:03, Egil Hjelmeland wrote:
I doubt that historical mapping will add significantly to the OSM
database size on the global scale. But if I am wrong, it will certainly
add value to OSM, IMHO.
How can adding an extra dimension not add significantly to the size?
The only way it
Egil Hjelmeland privat at egil-hjelmeland.no writes:
If you prefix tag keys of historic elements with past:, it will not
interfere with extisting SW conserned with rendering the present state.
Agreed. But as Frederik pointed out, it will confuse people using editors.
People often snap
were replaced in 1950.
So, unless you have full documentation of all of the changes, the dates are
likely to be speculative at best.
---Original Email---
Subject :Re: [OSM-talk] Historical Data in OSM database
From :mailto:ke...@kevinpeat.com
Date :Tue Nov 09 07:07:21 America/Chicago
On Tue, Nov 9, 2010 at 1:23 PM, Tom Hughes t...@compton.nu wrote:
For the record I think this is completely outside the scope of OSM and
should not be done.
Tom
The best definition of scope of OSM I found is on the wiki main page:
OpenStreetMap creates and provides free geographic data such
Tom Hughes wrote:
I doubt that historical mapping will add significantly to the OSM
database size on the global scale. But if I am wrong, it will certainly
add value to OSM, IMHO.
How can adding an extra dimension not add significantly to the size?
The only way it won't add significantly
On 9 November 2010 12:46, Lester Caine les...@lsces.co.uk wrote:
historic ways that have been overlaid with a new road structure are not
very common.
I don't think that is true at all. Everytime a new housing estate is built
there are changes to existing highways, new roundabouts, junction
Lester Caine lester at lsces.co.uk writes:
In the past we have been told If you want it - Add it - other people do not
have to use it. I just think this is another case of that which we need to
agree methods for since at least a few people DO want to share the
information.
If I'm mapping
Am 09.11.2010 13:46, schrieb Lester Caine:
As I have already said, simply adding a starT_date to a way is all
that is needed for probably 99% of historic mapping
If it would be as simple
I fear, it is not.
Historic data is often targeted to single properties of an entity: A
track
Peter Wendorff wrote:
As I have already said, simply adding a starT_date to a way is all
that is needed for probably 99% of historic mapping
If it would be as simple
I fear, it is not.
Historic data is often targeted to single properties of an entity: A
track being paved at a certain
As I mentioned elsewhere in another mailing list, you'd also have
problems with plate tectonics. For example, the big earthquake this
year in Chile displaced parts of that country by several feet. How do
you represent the current location of objects with past data? Someone
suggested to place
Andrew Harvey andrew.harvey4 at gmail.com writes:
Just a thought, perhaps for the time being one could add a changeset
tag which says, this feature is being deleted because it is no longer
there, but it was once there, to all changesets of deleation of
historic features. Otherwise no one knows if
j...@jfeldredge.com wrote:
One issue is that, if you are mapping a historic road that is located
differently from the current-day road, unless you have a series of maps showing
each successive change, you can't be sure whether there were additional change
steps between what your historic map
2010/11/9 Peter Wendorff wendo...@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
Am 09.11.2010 17:01, schrieb M∡rtin Koppenhoefer:
2010/11/9 Peter Wendorffwendo...@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
Dear list,
I posted this query to the talk-gb list a while ago and it was
suggested I post it here for further discussion.
I'm interested in adding historical information to the OSM database
so a timeline can be added to a map to show changes in an area. I've
On Mon, Nov 8, 2010 at 7:23 PM, Richard Palmer
richard.d.pal...@kcl.ac.uk wrote:
Dear list,
I posted this query to the talk-gb list a while ago and it was
suggested I post it here for further discussion.
I'm interested in adding historical information to the OSM database
On 9 November 2010 11:47, Serge Wroclawski emac...@gmail.com wrote:
The main database includes the historical data, there's just not a
programmatic way to access it via the current API.
He isn't the first, and I'm sure he won't be the last to ask for
changes to the API to accommodate historical
On 9 Nov 2010, at 02:47, Serge Wroclawski wrote:
On Mon, Nov 8, 2010 at 7:23 PM, Richard Palmer
I'm interested in adding historical information to the OSM database ...It's
been pointed out to me that there was a similiar proposal put by Frankie
Roberto some time ago; I wondered if any
On 9 November 2010 12:44, Laurence Penney l...@lorp.org wrote:
Using start_date and end_date tags on two way IDs (one for the Palace in its
first position, another for its second) might be a reasonable way to map the
Crystal Palace.
One way to handle this would be to update the API to
On Nov 8, 2010, at 6:53 PM, John Smith wrote:
On 9 November 2010 12:44, Laurence Penney l...@lorp.org wrote:
Using start_date and end_date tags on two way IDs (one for the Palace in its
first position, another for its second) might be a reasonable way to map the
Crystal Palace.
One way
On 9 November 2010 15:24, Michal Migurski m...@stamen.com wrote:
Would this apply to the planet, as well?
I would suggest that the main planet dump would keep the status quo,
that is default to current objects only.
___
talk mailing list
John Smith wrote:
On 9 November 2010 15:24, Michal Migurskim...@stamen.com wrote:
Would this apply to the planet, as well?
I would suggest that the main planet dump would keep the status quo,
that is default to current objects only.
At some point the planet dump will have to be made a
64 matches
Mail list logo
