I believe back on the 10th of March Russ said in three seporate emails that
he would upload the data, monitor the changes (dealing with associated
conflicts) and report back here with his findings.
I am fairly certain in another email shortly after he said he's now done it.
Doug
On Mar 18, 2009
On Tue, Mar 17, 2009 at 1:30 AM, Frederik Ramm frede...@remote.org wrote:
Hi,
Lars Aronsson wrote:
Here's an idea: Let's make OpenStreetMap the free wiki world map.
It's never going to work. How can you expect people to trust a map that
can be edited by anyone?
It's all right, when we find
On Mon, Mar 16, 2009 at 5:23 PM, Russ Nelson r...@cloudmade.com wrote:
Okay, taking you somewhat more seriously now, the ideology that Ted is
driving is that everything in OSM should be editable by everyone, and
nobody has any better edits to make than anyone else, and everybody
gets an equal
On Mar 16, 2009, at 6:21 PM, Frederik Ramm wrote:
Rather than somehow
setting up a toolchain that draws OSM data from OSM and immutable
extra
data from other sources, you'd prefer to dump everything into OSM
because it is more convenient for you.
More convenient for everyone. I think
On Mar 16, 2009, at 7:09 PM, Richard Fairhurst wrote:
People can then access it using exactly the same language/currency/
interface
that they're used to with OSM.
This only works if Potlatch, JOSM, Merkaartor, Chris Schmidt's editor,
and however many other editors that exist all add this
On Mar 16, 2009, at 7:39 PM, Lars Aronsson wrote:
Russ Nelson wrote:
As far as I can see, there is no reputation mechanism whereby
experienced editors stand out from the noob editors, and the
latter are reluctant to change the former's edits. And by
definition if I don't know about it, it
On Tue, Mar 17, 2009 at 10:46 PM, Russ Nelson r...@cloudmade.com wrote:
On Mar 16, 2009, at 7:09 PM, Richard Fairhurst wrote:
People can then access it using exactly the same language/currency/
interface
that they're used to with OSM.
This only works if Potlatch, JOSM, Merkaartor, Chris
On Sat, Mar 14, 2009 at 7:33 AM, Jukka Rahkonen
jukka.rahko...@mmmtike.fiwrote:
Why not to store this kind of datasets as own layers in the database? DEC
data
could be on its own, non-editable layer, but if there's something that
people
would like to edit those features could be copied or
If you can't edit it it shouldn't be in the OSM db.
Agreed.
OSM doesn't looks to me like a repository of any map with any conditions of
the world.
What's next ? some layer with copyrighted data, some with geolocalized
photos ? Better make this import available somewhere else as shapefiles,
On Mar 16, 2009, at 12:57 PM, Ted Mielczarek wrote:
If you can't edit it it shouldn't be in the OSM db. It's easy enough
to set up your own map render with any external data you want.
Bzzzr, wrong. There is substantial value to renderers to only have to
work off one API for map data. If
Would it be ok to edit the data without moving it? i.e. add extra tags
to the data.
If so, I think that it makes sense to import it - as there would be no
reason to move a node that is already correct.
If no extra tags can be added and the data can not be edited in any way,
then perhaps this
Ted Mielczarek ted.mielczarek at gmail.com writes:
On Sat, Mar 14, 2009 at 7:33 AM, Jukka Rahkonen wrote:
Why not to store this kind of datasets as own layers in the database? DEC
data
could be on its own, non-editable layer, but if there's something that people
would like to edit those
On Mon, 2009-03-16 at 17:35 +, Andy Deakin wrote:
Would it be ok to edit the data without moving it? i.e. add extra tags
to the data.
Of course it is okay to add tags. It's okay to move it too, like
anything else in OSM. The source = DEC is a source with good tools and
a high opinion of
On Mon, Mar 16, 2009 at 5:24 PM, Russ Nelson r...@cloudmade.com wrote:
On Mar 16, 2009, at 12:57 PM, Ted Mielczarek wrote:
If you can't edit it it shouldn't be in the OSM db. It's easy enough
to set up your own map render with any external data you want.
Bzzzr, wrong. There is substantial
On Mar 16, 2009, at 1:35 PM, Andy Deakin wrote:
Would it be ok to edit the data without moving it? i.e. add extra tags
to the data.
Well, yes, that's why the DEC Lands data has been imported without an
immutable=yes tag. Because, for example, we have metadata for
forest=deciduous and
On Mar 16, 2009, at 2:18 PM, Andy Allan wrote:
No he's not, and plenty of other people are in agreement here. It's a
question of the point of having a community in OSM (vs a large
collection of uneditable datasets), and you're arguing about technical
stuff. Technical comes second, community
On Mar 16, 2009, at 2:45 PM, Gerald A wrote:
Why not just do a trial import, and see how it goes? See what
changes and why, rather then crushing changes with instant reversions?
Maybe I haven't been obvious enough here? It's much more interesting
to see what kinds of edits people would
On Mar 16, 2009, at 3:05 PM, Lars Aronsson wrote:
Russ Nelson wrote:
Sorry, Ted, but you're being driven by ideology here, not by
good programming practise. Ideology is for ideots.
Really? So can we copy coordinates from Google Maps now?
Okay, taking you somewhat more seriously now, the
I exaggerate to make a point, obviously. As far as I can see, there
is no reputation mechanism whereby experienced editors stand out from
the noob editors, and the latter are reluctant to change the former's
edits. And by definition if I don't know about it, it doesn't exist.
In
Hi,
Russ Nelson wrote:
Sorry if I wax too philosophic here, but I'm a combiner, not a
splitter.
I think you are first and foremost lazy ;-). You want un-editable data
in OSM not because it benefits OSM in some way but because you are used
to working with the OSM toolchain and you would
On 16 Mar 2009, at 20:40, Russ Nelson wrote:
On Mar 16, 2009, at 2:18 PM, Andy Allan wrote:
No he's not, and plenty of other people are in agreement here. It's a
question of the point of having a community in OSM (vs a large
collection of uneditable datasets), and you're arguing about
Russ Nelson wrote:
There's a reason why people create generalized interfaces and
standard metadata and a common currency and a shared language
We do have all that, of course. It's called, for OSM-historical reasons, the
Rails port. You can get yourself a server (I can probably think of
Hi,
Richard Fairhurst wrote:
Hell, if you think having to call two URLs is
too much like hard work, you can augment your data with minutely-updated OSM
dumps, and make everything available from that one place.
What id range would he use for nodes, ways, and relations of his
immutable
On Mon, Mar 16, 2009 at 11:22 PM, Frederik Ramm frede...@remote.org wrote:
Richard Fairhurst wrote:
Hell, if you think having to call two URLs is
too much like hard work, you can augment your data with minutely-updated OSM
dumps, and make everything available from that one place.
What id
Russ Nelson wrote:
Okay, taking you somewhat more seriously now, the ideology that
Ted is driving is that everything in OSM should be editable by
everyone,
This part sounds like the very core of the wiki idea, and not at
all extremist.
and nobody has any better edits to make than anyone
Hi,
Lars Aronsson wrote:
Here's an idea: Let's make OpenStreetMap the free wiki world map.
It's never going to work. How can you expect people to trust a map that
can be edited by anyone?
Bye
Frederik
--
Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33
Simon Ward simon at bleah.co.uk writes:
On Mon, Mar 09, 2009 at 02:25:24PM -0400, Russ Nelson wrote:
Earlier, I proposed that certain datasets should be immutable; whether
by policy or mechanism as needed. I propose importing the NYS DEC
Lands as an immutable set of data. If you
On Sat, Mar 14, 2009 at 7:33 PM, Jukka Rahkonen
jukka.rahko...@mmmtike.fiwrote:
Why not to store this kind of datasets as own layers in the database? DEC
data
could be on its own, non-editable layer, but if there's something that
people
would like to edit those features could be copied or
On Thu, Mar 12, 2009 at 9:49 PM, David Lynch djly...@gmail.com wrote:
On Thu, Mar 12, 2009 at 12:36, Russ Nelson r...@cloudmade.com wrote:
No one has been able to refute my claim that if someone would enter it
by hand, it belongs in OSM regardless of its source. And if it comes
from surveyed
At 06:36 PM 12/03/2009, Russ Nelson wrote:
On Mar 12, 2009, at 7:43 AM, Ted Mielczarek wrote:
. However, I reject the idea that there is any data that belongs in
OSM that makes no sense to edit. If you can't edit it, then by
definition it shouldn't be in a wiki-style map.
No one has been
On 09/03/09 18:25, Russ Nelson wrote:
Earlier, I proposed that certain datasets should be immutable; whether
by policy or mechanism as needed. I propose importing the NYS DEC
Lands as an immutable set of data. If you read this exchange with
Robert Morrell, you can see why they feel
On Mon, Mar 09, 2009 at 02:25:24PM -0400, Russ Nelson wrote:
Earlier, I proposed that certain datasets should be immutable; whether
by policy or mechanism as needed. I propose importing the NYS DEC
Lands as an immutable set of data. If you read this exchange with
Robert Morrell, you
On Tue, Mar 10, 2009 at 1:56 PM, Russ Nelson r...@cloudmade.com wrote:
If it's This is what NYS DEC says it manages, then no, it doesn't make
ANY sense
to change it.
Then this data clearly doesn't belong in OSM.
If the data is These are NYS's State Forests, then
there's plenty of
On Thu, Mar 12, 2009 at 5:36 PM, Russ Nelson r...@cloudmade.com wrote:
On Mar 12, 2009, at 7:43 AM, Ted Mielczarek wrote:
. However, I reject the idea that there is any data that belongs in
OSM that makes no sense to edit. If you can't edit it, then by
definition it shouldn't be in a
Russ Nelson wrote:
Sent: 09 March 2009 6:25 PM
To: Talk Openstreetmap
Subject: [OSM-talk] immutable=yes Fwd: DEC Lands
Earlier, I proposed that certain datasets should be immutable; whether
by policy or mechanism as needed. I propose importing the NYS DEC
Lands as an immutable set of data
On Thu, Mar 12, 2009 at 5:36 PM, Russ Nelson r...@cloudmade.com wrote:
On Mar 12, 2009, at 7:43 AM, Ted Mielczarek wrote:
. However, I reject the idea that there is any data that belongs in
OSM that makes no sense to edit. If you can't edit it, then by
definition it shouldn't be in a
On Thu, Mar 12, 2009 at 12:36, Russ Nelson r...@cloudmade.com wrote:
No one has been able to refute my claim that if someone would enter it
by hand, it belongs in OSM regardless of its source. And if it comes
from surveyed data, then it makes no sense to edit its position.
Metadata, perhaps.
Hi, I'll add my 2 cents :-)
Natural Resources Canada (NRCan) admits that YES, their data has 'known' and
'unknown' inaccuracies. So their aim is to create a national dataset of
100% accurate collection of all provincial datasets on a 'regular basis'.
(just as DEC lands Db is only as accurate as
2009/3/10 Russ Nelson r...@cloudmade.com
On Mar 9, 2009, at 4:11 PM, Ulf Lamping wrote:
OSM is about to have a *free* database. Saying your not allowed to
change the data is *not* a free database as I understand it.
For this particular case, it's not that you're not allowed to change
On Mon, Mar 9, 2009 at 10:22 PM, Frederik Ramm frede...@remote.org wrote:
Hi,
Russ Nelson wrote:
On Mar 9, 2009, at 3:07 PM, Matthew Toups wrote:
If we can't change the data, what's the point of having it in OSM?
Having consistent metadata and a consistent single-source API.
That's
I share the discomfort of others about truly non-editable imported data.
I have found a number of errors in MassGIS data, although the vast
majority of it seems very good.
Two approaches come to mind:
1.
a. Have a way to have a separate database with such data.
b. Have a way to have
On Mar 10, 2009, at 1:03 PM, Dirk-Lüder Kreie wrote:
I propose a social solution instead of a technical one.
i.e. please don't change, because... instead of
you cannot change this, period.
I've not proposed a technical solution. The question here is: should
there be data in OSM which it
On Mar 10, 2009, at 10:40 AM, Greg Troxel wrote:
1.
a. Have a way to have a separate database with such data.
The problem with the separate database idea is that if someone was
to enter the data by hand into OSM, everyone agrees that it belongs
there ... but would be incompete and
On Mar 9, 2009, at 6:32 PM, 80n wrote:
The best guideline we have at the moment is to map what is on the
ground.
Surveyed property lines beat GPS tracks pretty much every time. Now,
if you're talking about metadata -- description of what's there rather
than where it is -- then yes, I
Earlier, I proposed that certain datasets should be immutable; whether
by policy or mechanism as needed. I propose importing the NYS DEC
Lands as an immutable set of data. If you read this exchange with
Robert Morrell, you can see why they feel that NO changes AT ALL are
appropriate. I
Hi,
Russ Nelson wrote:
and changes by any OSM editor are not
consistent with the nature of the data.
In that case, the data should not be in OSM but should instead be pulled
in on another level - for example, create transparent tiles to show on
top of OSM tiles, or make a shapefile and
On Mar 9, 2009, at 2:39 PM, Frederik Ramm wrote:
if someone has data that must not be modified
(because of course it is 100% error free...?) then don't put that data
in OSM!
*I* see OSM as an API for all possible geodata: everything that
doesn't move, and a few things that do. There are
In that case, the data should not be in OSM but should instead be pulled
in on another level - for example, create transparent tiles to show on
top of OSM tiles, or make a shapefile and pull that in through Mapnik.
Well, if the data won't be in OSM (neither in dumps or in things
received from
On Mar 9, 2009, at 2:38 PM, Iván Sánchez Ortega wrote:
However, land use *is* mutable... I'd agree on marking this dataset as
immutable *only* *if* the NYS DEC agrees to regularly pass on OSM
any updates
to the dataset. Otherwise, we would end up with obsolete data, which
is a Bad
Russ Nelson wrote:
*I* see OSM as an API for all possible geodata: everything that
doesn't move, and a few things that do. There are arguably many
things currently in OSM which should not be edited. For example,
political boundaries at every level.
Hmmm, political boundaries
Russ Nelson wrote:
Earlier, I proposed that certain datasets should be immutable; whether
by policy or mechanism as needed. I propose importing the NYS DEC
Lands as an immutable set of data. If you read this exchange with
Robert Morrell, you can see why they feel that NO changes AT ALL
On Mon, Mar 9, 2009 at 7:54 PM, Russ Nelson r...@cloudmade.com wrote:
*I* see OSM as an API for all possible geodata: everything that
doesn't move, and a few things that do. There are arguably many
things currently in OSM which should not be edited. For example,
political boundaries at
On Mon, Mar 9, 2009 at 13:54, Russ Nelson r...@cloudmade.com wrote:
On Mar 9, 2009, at 2:39 PM, Frederik Ramm wrote:
if someone has data that must not be modified
(because of course it is 100% error free...?) then don't put that data
in OSM!
*I* see OSM as an API for all possible
On Mar 9, 2009, at 3:07 PM, Matthew Toups wrote:
If we can't change the data, what's the point of having it in OSM?
Having consistent metadata and a consistent single-source API.
On what bases would someone with no formal training, no legal deed
description, or survey map have to determine
Russ Nelson wrote:
On Mar 9, 2009, at 3:07 PM, Matthew Toups wrote:
If we can't change the data, what's the point of having it in OSM?
Having consistent metadata and a consistent single-source API.
Interesting reasons, not exactly what motivates me the most about OSM,
but I can see how that
Russ Nelson schrieb:
On Mar 9, 2009, at 3:07 PM, Matthew Toups wrote:
If we can't change the data, what's the point of having it in OSM?
Having consistent metadata and a consistent single-source API.
On what bases would someone with no formal training, no legal deed
description, or
On Mon, Mar 9, 2009 at 8:11 PM, Ulf Lamping ulf.lamp...@googlemail.comwrote:
Russ Nelson schrieb:
On Mar 9, 2009, at 3:07 PM, Matthew Toups wrote:
If we can't change the data, what's the point of having it in OSM?
Having consistent metadata and a consistent single-source API.
On
Russ Nelson wrote:
How do people feel about me importing this data (with all of
their metadata), adding an immutable=yes tag, with the intent
of tracking their dataset, and deleting --outright-- any changes
made by OSM editors.
If it can't be edited, there's no point sending it to the
El Lunes, 9 de Marzo de 2009, 80n escribió:
What's needed here is not an immutable=yes tag but rather a couple of tags
source=DEC and accuracy=definitive [...]
+1.
Current tools (ITO OSM mapper, for instance) will be able to deal with changes
applied to a set of ways tagged a certain way. I
80n schrieb:
The problem with GPS toting mappers is that they will often believe
their GPS tracks are at least as accurate as those used for all the
other data in OSM, so there's a strong temptation to move things around
a bit based on the information they have to hand - I know, I've done
On Mon, Mar 9, 2009 at 9:24 PM, 80n 80n...@gmail.com wrote:
What's needed here is not an immutable=yes tag but rather a couple of tags
source=DEC and accuracy=definitive which will give GPS toting mappers the
information they need to know that the data in OSM is likely to be more
accurate
Hi,
Russ Nelson wrote:
On Mar 9, 2009, at 3:07 PM, Matthew Toups wrote:
If we can't change the data, what's the point of having it in OSM?
Having consistent metadata and a consistent single-source API.
That's exactly what I said in my first reply:
Once OSM and its tool chain are
On Mar 9, 2009, at 4:11 PM, Ulf Lamping wrote:
OSM is about to have a *free* database. Saying your not allowed to
change the data is *not* a free database as I understand it.
For this particular case, it's not that you're not allowed to change
the data -- it's that it makes no sense to
On Mar 9, 2009, at 4:36 PM, Richard Fairhurst wrote:
ActionScript or Ruby whatever to say get all geodata within this
bbox from
openstreetmap.org, and also freesurveyorsstuff.org, and return it in
one
object, that would fulfil the need - without bending OSM to do
something it
was
On Mon, Mar 9, 2009 at 10:22 PM, Russ Nelson r...@cloudmade.com wrote:
On Mar 9, 2009, at 4:11 PM, Ulf Lamping wrote:
OSM is about to have a *free* database. Saying your not allowed to
change the data is *not* a free database as I understand it.
For this particular case, it's not that
Russ Nelson wrote:
How do people feel about me importing this data (with all of their
metadata), adding an immutable=yes tag, with the intent of tracking
their dataset, and deleting --outright-- any changes made by OSM
editors.
Let me get this straight - this would be the same sort of
Hi,
Russ Nelson wrote:
Obviously the potential
exists for a revert war, but given that I have a reasonable claim for
my authority (e.g. http://rutlandtrail.org/list.cgi), why would
someone else edit data that I am more expert in?
Your mistake, if you allow me to say to bluntly, lies in
Ulf Lamping wrote:
What's needed here is not an immutable=yes tag but rather a couple of
tags source=DEC and accuracy=definitive which will give GPS toting
mappers the information they need to know that the data in OSM is likely
to be more accurate that their GPS. They can then take an
On Mar 9, 2009, at 6:22 PM, Frederik Ramm wrote:
I am absolutely sure that the dataset in question will, like any other
dataset on the planet, contain errors.
I agree. But how to convince someone who doesn't agree? I don't
think words will convince; it will take data. They need to have
69 matches
Mail list logo
