Am 09.11.2010 17:01, schrieb M∡rtin Koppenhoefer:
2010/11/9 Peter Wendorff:
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
2010/11/9 Peter Wendorff :
> 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 ve
On Nov 9, 2010, at 12:30 AM, Lennard wrote:
>> A stupid but working workaround is to go through the .osm file with sed or
>> something and rename coastline to something else before running osm2pgsql.
>
> And the more logical solution would be to find the single line in the
> osm2pgsql code that d
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 s
2010/11/9 Pieren :
> But when I say that it is something which has to be clarified/confirmed by
> the foundation, is that wrong ?
Yes, IMHO that is wrong, as the scope of the project has to be defined
by the community and not by the foundation.
Cheers,
Martin
___
Lester Caine 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 on
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
Andrew Harvey 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 the object w
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 histor
On 9 November 2010 12:46, Lester Caine 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 changes,
etc. If y
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 Tue, Nov 9, 2010 at 1:23 PM, Tom Hughes 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 as str
Hi,
On 11/09/10 13:03, Egil Hjelmeland wrote:
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=..."
Even so, it will be visible as an unmarked point/line/ar
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 shows and the current state.
Egil Hjelmeland 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 together no
On Tue, Nov 9, 2010 at 11:42 AM, Frederik Ramm wrote:
>
> 3. Our infrastucture might be unduly burdened by all the extra load.
>
>
Altough I agree with the first two points, this one is not valid imho. The
amount of "accurate historical data" will never be so big that it will have
a significant
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 w
It seems to be a new user from Brazil trying to upload a .dwg without much
knowledge. I´ll try to contact him.
On Tue, Nov 9, 2010 at 6:19 AM, Barnett, Phillip
wrote:
> It's located at 0,0 so is obviously incorrect (at least to a first casual
> look) ie, whatever the user was intending to map, he
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
additi
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 hist
At 2010-11-05 09:55, Apollinaris Schoell wrote:
hmm, sorry got the wrong name here, reading from pipermail Alan's name was
highlighted and Anthony's wasn't :(
have to agree on the trolling, and it jsut got confirmed
You guys are tough to keep up with. Now I don't know whether I'm a troll or
n
Hi,
On 11/09/2010 11:57 AM, Lester Caine wrote:
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 change files to be alerted of changes in the objects of interest
to you.
So you are advocating that w
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 cha
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 used
On Tue, Nov 9, 2010 at 9:03 PM, Pieren 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 thought, perhaps
On Tue, Nov 9, 2010 at 7:44 AM, Lester Caine 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 historic
> map info
> A stupid but working workaround is to go through the .osm file with sed or
> something and rename coastline to something else before running osm2pgsql.
And the more logical solution would be to find the single line in the
osm2pgsql code that drops natural=coastline, adapt that, and
recompile/rei
Michal Migurski stamen.com> writes:
>
> Can I ask if it would be possible to include in those shapefiles a processed
coastline that's just the
> outlines, rather than the tiled land area polygon? osm2pgsql doesn't import
natural=coastline (a
> hardcoded exception) and sometimes it's useful to p
It's located at 0,0 so is obviously incorrect (at least to a first casual look)
ie, whatever the user was intending to map, he's accidentally dumped it in the
wrong place.
PHILLIP BARNETT
SERVER MANAGER
200 GRAY'S INN ROAD
LONDON
WC1X 8XZ
UNITED KINGDOM
T +44 (0)20 7430 4474
F
E phillip.barn
30 matches
Mail list logo
