Re: [OSM-talk] Zero tolerance on imports

[yvecai]

On 06. 03. 11 19:38, Frederik Ramm wrote:


(The name ClosedStreetMap probably tripped you, Fabio; Russ didn't 
mean closed data, he meant data that is open but doesn't make sense to 
edit in OSM. And by almost any definition, data that cannot sensibly 
be edited by OSMers should not be in OSM.)
I must admit that I overlook this idea a little, I thought that 
ClosedStreetMap was ironic. Maybe PublicDatasourceStreetMap could help 
for this idea to develop?

Yves


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Zero tolerance on imports

[Kevin Peat]

Russ,

You are spot on with this. I don't think UK contributors would currently be
madly tracing OS data into OSM if it was easy to produce a complete UK map
from OSM surveyed data with the missing bits filled in from the OS dataset.
Until better tools are available people are going to keep importing stuff
regardless of the ultimate benefit to the project.

Kevin


On 6 March 2011 17:39, Russ Nelson  wrote:

>
> That's because nobody is talking about the REAL
> solution. OpenStreetMap is the place for user-edited volunteered
> geographic information. It's NOT the place for importing information
> which would be nonsensical if a user edited it. 
>
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Zero tolerance on imports

[Frederik Ramm]

Hi,

Fabio Alessandro Locati wrote:

Have you considered that the goal of OSM is creating a free (as
speach) map of the whole world... I think your view is not so close to
the project goal..


It is certainly not the project goal to import every last scrap of free 
data no matter how irrelevant it is to editors. I think Russ is right; 
although I'd like to think maybe we don't need a "ClosedStreetMap.org" 
but just an easier way for people to add stuf from third-party sources 
to the maps they produce.


(The name ClosedStreetMap probably tripped you, Fabio; Russ didn't mean 
closed data, he meant data that is open but doesn't make sense to edit 
in OSM. And by almost any definition, data that cannot sensibly be 
edited by OSMers should not be in OSM.)


Bye
Frederik



2011/3/6, Russ Nelson :

Peter Budny writes:
 > I find this discussion very distasteful.

That's because nobody is talking about the REAL
solution. OpenStreetMap is the place for user-edited volunteered
geographic information. It's NOT the place for importing information
which would be nonsensical if a user edited it.

The REAL solution is to have a ClosedStreetMap.org, which publishes
data in the same format under the same license using the same tag set
using the same API as OpenStreetMap, only it publishes read-only data.
Some of the imports that I've done (NYC bike racks, NYS DEC lands, and
NYS State Parks, which I'm currently working on), the data is
maintained elsewhere. It useful to have for OpenStreetMap users, but
not for OpenStreetMap editors. Why? Because for at least the last two,
the boundaries are off in the middle of sometimes very dense woods,
are not necessarily marked by signs, if signs are present they are not
authoritative, and the original source of the data is a legal
description, and no hand editing can change that.

So take all these data sets, and their transformative programs, create
.osm files out of them, and throw them into a database. When you get
updates, rebuild the database.

There's a few problems with the idea, e.g. what if somebody adds
something to OSM that's already in CSM? Or, what if the data, although
published from an authoritative source, is dirty? How does OSM
override data in CSM?

But I think there are fewer problems than the current system of one
person dumping in megabytes for which there is no practical means of
updating with another import.

--
--my blog is athttp://blog.russnelson.com
Crynwr supports open source software
521 Pleasant Valley Rd. | +1 315-600-8815
Potsdam, NY 13676-3213  | Sheepdog

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk





--
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Zero tolerance on imports

[Fabio Alessandro Locati]

Have you considered that the goal of OSM is creating a free (as
speach) map of the whole world... I think your view is not so close to
the project goal..

2011/3/6, Russ Nelson :
> Peter Budny writes:
>  > I find this discussion very distasteful.
>
> That's because nobody is talking about the REAL
> solution. OpenStreetMap is the place for user-edited volunteered
> geographic information. It's NOT the place for importing information
> which would be nonsensical if a user edited it.
>
> The REAL solution is to have a ClosedStreetMap.org, which publishes
> data in the same format under the same license using the same tag set
> using the same API as OpenStreetMap, only it publishes read-only data.
> Some of the imports that I've done (NYC bike racks, NYS DEC lands, and
> NYS State Parks, which I'm currently working on), the data is
> maintained elsewhere. It useful to have for OpenStreetMap users, but
> not for OpenStreetMap editors. Why? Because for at least the last two,
> the boundaries are off in the middle of sometimes very dense woods,
> are not necessarily marked by signs, if signs are present they are not
> authoritative, and the original source of the data is a legal
> description, and no hand editing can change that.
>
> So take all these data sets, and their transformative programs, create
> .osm files out of them, and throw them into a database. When you get
> updates, rebuild the database.
>
> There's a few problems with the idea, e.g. what if somebody adds
> something to OSM that's already in CSM? Or, what if the data, although
> published from an authoritative source, is dirty? How does OSM
> override data in CSM?
>
> But I think there are fewer problems than the current system of one
> person dumping in megabytes for which there is no practical means of
> updating with another import.
>
> --
> --my blog is athttp://blog.russnelson.com
> Crynwr supports open source software
> 521 Pleasant Valley Rd. | +1 315-600-8815
> Potsdam, NY 13676-3213  | Sheepdog
>
> ___
> talk mailing list
> talk@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk
>

-- 
Inviato dal mio dispositivo mobile

Fabio Alessandro Locati

Home: Segrate, Milan, Italy (GMT +1)
Phone: +39-328-3799681
MSN/Jabber/E-Mail: fabioloc...@gmail.com

PGP Fingerprint: 5525 8555 213C 19EB 25F2  A047 2AD2 BE67 0F01 CA61

Involved in: KDE, OpenStreetMap, Ubuntu, Wikimedia

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Zero tolerance on imports

[Russ Nelson]

Peter Budny writes:
 > I find this discussion very distasteful.

That's because nobody is talking about the REAL
solution. OpenStreetMap is the place for user-edited volunteered
geographic information. It's NOT the place for importing information
which would be nonsensical if a user edited it.

The REAL solution is to have a ClosedStreetMap.org, which publishes
data in the same format under the same license using the same tag set
using the same API as OpenStreetMap, only it publishes read-only data.
Some of the imports that I've done (NYC bike racks, NYS DEC lands, and
NYS State Parks, which I'm currently working on), the data is
maintained elsewhere. It useful to have for OpenStreetMap users, but
not for OpenStreetMap editors. Why? Because for at least the last two,
the boundaries are off in the middle of sometimes very dense woods,
are not necessarily marked by signs, if signs are present they are not
authoritative, and the original source of the data is a legal
description, and no hand editing can change that.

So take all these data sets, and their transformative programs, create
.osm files out of them, and throw them into a database. When you get
updates, rebuild the database.

There's a few problems with the idea, e.g. what if somebody adds
something to OSM that's already in CSM? Or, what if the data, although
published from an authoritative source, is dirty? How does OSM
override data in CSM?

But I think there are fewer problems than the current system of one
person dumping in megabytes for which there is no practical means of
updating with another import.

-- 
--my blog is athttp://blog.russnelson.com
Crynwr supports open source software
521 Pleasant Valley Rd. | +1 315-600-8815
Potsdam, NY 13676-3213  | Sheepdog   

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Zero tolerance on imports

[Peter Wendorff]

Contact Mail is written at the bottom of the page:
Contact: as(a t)nitegate(d o t)de, Made by Multimedia und IT 
 - betaplace.emaitie.de 
 - Data by OpenStreetMap 


=> a...@nitegate.de
regards
Peter

Am 22.02.2011 17:06, schrieb Peter Budny:

Peter Wendorff  writes:


Am 22.02.2011 00:10, schrieb Peter Budny:

Here's another issue that ought to be much easier to solve, but hasn't
been: the relation analyzer.
http://ra.osmsurround.org/analyze.jsp?relationId=36947
That particular relation follows the "correct" practice of using
role=(blank)/forward/backward, but even this isn't recognized by the
analyzer.  What it ought to show is just two chunks: from point A to B,
and from point B to A.  With the current display, how is one supposed to
figure out if relation is completed or not?

+1
Should not be very difficult to solve - but anyone has to do it.

As far as I know, the sourcecode is not available, and I couldn't find a
user or e-mail address to contact.  Does anyone know differently?


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Zero tolerance on imports

[M∡rtin Koppenhoefer]

2011/2/22 Peter Budny :
> Anders Arnholm  writes:
> On the contrary... the bigger the database, the more we need tools to
> help us understand and manipulate the data.  When there are only 100
> POI nodes in a city, I can easily check them all by hand.  When there
> are 10, that's when automated or semi-automated tools are necessary.


to do what? Why would you want to check all the POIs? If I come over
something that is missing I add it, if there is something that is not
there in reality and I am aware I delete it (or more often move it to
the right position). The more the data gets used, the more the errors
get found. OSM is a project with tens of thousands of contributors but
we will need millions of users and possibly a back channel to maintain
all the data. No bot on earth can tell you if a POI is at the right
position, is well described or is there at all (in the real world).


> Sorry, I avoided your question.  As for imports: the bigger OSM gets,
> the harder it is to ensure coverage.  If I got the supposed McDonald's
> POI dataset, how would we know whether OSM already has 100% of them, or
> only 98%?


ask McDonald's or even better, let them check ;-) Who cares if we have
all McDonald's if not they themselves? Besides that your question is
very simple: count them.


> This discussion has somehow conflated robots and tools with imports, and
> that may be partially my fault.  But if we had better tools for
> performing imports, it might be easier to stitch them together with
> existing hand-edited data, and imports wouldn't be such a destructive
> process.


While I am not generally against imports I began to be more and more
against them in past few years. The benefit of publicly available data
imported in our database is very little in respect to a parallel crowd
sourced dataset (e.g. you could also compare them one against the
other to find problems in either one). I don't know about the quality
of the publicly available data in the US (I guess TIGER was a
super-neat and up-to-date dataset, but my knowledge is based on people
admiring it here on the ML) but so-called "official" data which I have
seen is often worse than what people think about it. Nobody can
actually afford to spend so much time on the data like we do ;-).

cheers,
Martin

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Zero tolerance on imports

[Peter Budny]

Anders Arnholm  writes:

> 2011-02-21 16:03, Peter Budny skrev:
>
>> Those of you who think all automated or semi-automated data
>> contributions are harmful to OSM are dooming this project to never be
>> able to grow to become a leading source of mapping data.
>
> The bigger the data base, the less useful automates imports, or I'm i
> missing something?

On the contrary... the bigger the database, the more we need tools to
help us understand and manipulate the data.  When there are only 100
POI nodes in a city, I can easily check them all by hand.  When there
are 10, that's when automated or semi-automated tools are necessary.

Sorry, I avoided your question.  As for imports: the bigger OSM gets,
the harder it is to ensure coverage.  If I got the supposed McDonald's
POI dataset, how would we know whether OSM already has 100% of them, or
only 98%?  That's a lot of McDonald's to check... what if we miss one?
So even if the data isn't "imported", it's still valuable.

This discussion has somehow conflated robots and tools with imports, and
that may be partially my fault.  But if we had better tools for
performing imports, it might be easier to stitch them together with
existing hand-edited data, and imports wouldn't be such a destructive
process.
-- 
Peter Budny  \
Georgia Tech  \
CS MS student  \

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Zero tolerance on imports

[Peter Budny]

Peter Wendorff  writes:

> Am 22.02.2011 00:10, schrieb Peter Budny:
>> Here's another issue that ought to be much easier to solve, but hasn't
>> been: the relation analyzer.
>> http://ra.osmsurround.org/analyze.jsp?relationId=36947
>> That particular relation follows the "correct" practice of using
>> role=(blank)/forward/backward, but even this isn't recognized by the
>> analyzer.  What it ought to show is just two chunks: from point A to B,
>> and from point B to A.  With the current display, how is one supposed to
>> figure out if relation is completed or not?
> +1
> Should not be very difficult to solve - but anyone has to do it.

As far as I know, the sourcecode is not available, and I couldn't find a
user or e-mail address to contact.  Does anyone know differently?
-- 
Peter Budny  \
Georgia Tech  \
CS MS student  \

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Zero tolerance on imports

[Ed Avis]

NopMap  gmx.de> writes:

>There is a considerable difference between an import into a mostly empty
>area - which is rather easy to achieve and mostly helpful - and an import
>into an already basically mapped area, which is hard to integrate and where
>existing data may be damaged.

Absolutely right.

I'd hope it would go without saying that an 'import' in an area where the map
is not empty should not be trashing the existing data and replacing it, nor
blindly adding new objects over the top of what's there.  It must involve
checking and reconciling the two data sets and making a common-sense choice
about how to resolve conflicts in order to best match what is on the ground.

Indeed, I would avoid the use of the word 'import' at all; it should be
a synthesis of the existing OSM map with the new data.

>There appears to be a common misconception that arial imagery and imported
>data is somehow "better by default" than the hand-drawn traces.

I haven't come across anyone with that misconception, but it is one.
I hope that nobody presumes that hand-drawn GPS traces are 'better by default'
than good-quality aerial photos, however; in urban canyons where GPS accuracy
is low, they are not.

>So, personally, I believe that drawing the first roads on an empty map is
>much more fun and motivation than fixing mistakes in someone else's imported
>data. If the actuality, accuracy and quality of data is less than excellent,
>I would rather not import it at all.

I would say that what matters is not the absolute quality of the imported data
(even an excellent quality map would not be worth importing into Oxford or
Friedrichshain, since the OSM data is also excellent there) but its relative
quality to what OSM currently has.  If the existing OSM data is very poor,
perhaps because it in turn came from an earlier poor-quality import (or was
traced from blurry aerial photos), then even a moderately good data set can
add value to the map if used with care.  Often third-party data sets lack
detail in some areas compared to OSM, but have much better completeness over
a wide area while OSM has holes.

-- 
Ed Avis 



___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Zero tolerance on imports

[Ed Avis]

Steve Coast  asklater.com> writes:

>mapnik etc could render only objects with version 2 or higher. Not only 
>does that block out imports, but now we're at the point of completing 
>various areas, it will make people go back and check them.

Not a bad idea - or you could develop various quality heuristics: number of
different users who have edited the object, how many different sources have been
used (whether tagged explicitly as source=x or mentioned in the changeset) etc.

I think this extra-fussy Mapnik style should be an option, not the default:
a lot of mapping work is of good enough quality, even though only done as a
single pass (for example building shapes traced from Bing) and certainly better
than a blank canvas for most uses.  But that can be a choice the user makes.

Any quality (or 'kwalitee') metric cannot be perfect but it could help people
with different philosophies about imports or survey methods co-operate on the
same map.

-- 
Ed Avis 


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Zero tolerance on imports

[Jean-Marc Liotier]

Peter Budny wrote:

suppose I somehow get a database of every McDonald's location in the
world, complete with addresses, phone numbers, etc.


This one is of particular interest to me - I am working on a project 
outside OpenStreetMap in which we are struggling with such an issue : we 
are merging two databases with a few thousand objects representing 
various types of nodes in a fiber optics network... On the one side we 
have cable extremities and on the other we have splice boxes. We are 
supposed to connect the cables to the boxes - which would be easy if the 
extremities were positioned exactly on the boxes... They aren't. So we 
have a problem similar to the management of a POI import over existing 
points... We have found no magic way to do it : for each cable extremity 
we query the nearest splice box. If they are less than a few meters 
away, we connect them automatically - otherwise we have to review them 
manually. So not only are we taking a risk of error in high-density 
neighborhoods were some splice boxes are packed together, but there is 
still significant tedious manual work involved. For now, a POI import in 
OpenStreetMap is just like that and I fail to imagine a more efficient 
way... Though I would love someone to point out my lack of imagination !



___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Zero tolerance on imports

[Peter Wendorff]

Am 22.02.2011 00:10, schrieb Peter Budny:

I would be naive to think that I have all the answers, or even some of
them.  It's a lot easier to point out problems than to solve them.
However, you were kind enough to ask, so let me try to do some
brainstorming:

[..]



Here's another issue that ought to be much easier to solve, but hasn't
been: the relation analyzer.
http://ra.osmsurround.org/analyze.jsp?relationId=36947
That particular relation follows the "correct" practice of using
role=(blank)/forward/backward, but even this isn't recognized by the
analyzer.  What it ought to show is just two chunks: from point A to B,
and from point B to A.  With the current display, how is one supposed to
figure out if relation is completed or not?

+1
Should not be very difficult to solve - but anyone has to do it.

What about GPS tracks... how does one deal with those?  The only
interface I know is to click on "GPS Traces" from the slippy map, but
that just gives me a list, and shows every trace in the whole world.  I
only want to see traces for the region I'm looking at, like "show me
every GPS track within 100m of this highway".

+2
Support of GPS tracks in OSM is very basic, I think.
Selecting GPS tracks by a set of tags is not possible, too, I think.
There even is no set of tags to apply as a "standard". That leads to a 
situation where it's not possible to say "give me traces recorded by 
car/cycling/walking".

I see there's a wiki page on change monitoring, but it doesn't look like
there's anything very sophisticated.  Perusing the history when there
are so many edits that are -180 to 180 is a big turn-off.  If mappers
are supposed to watch their hometown for changes, shouldn't they be
given tools to do that with?

Try OWL for that: http://matt.dev.openstreetmap.org/owl_viewer/
It's a tile-based RSS-Feed-Generator. You can subscribe for a set of 
predefined tiles and get every changeset inside that area(s) as RSS-Feed.

Like I said, this is just brainstorming.  I'm sure other users also have
ideas for tools that would make the editing process a lot less tedious,
without even touching on the topic of automated edits.  Tools like these
can benefit everyone (unlike a discussion on how to tag lumber yards or
hotdog carts or whatever the question du jour is).

You are completely right.
The problem is: We miss developers with enough time and motivation to 
create these tools, and that's a problem not possible to solve by 
writing an email.


Don't miss the point here: It's a good first step to identify what kind 
of tools are missing; but there is no automatic-tool-creator.


Feel free to learn programming, to find people who want to do some of 
these tools. Or feel free to wait if anyone starts himself after reading 
your mail.


regards
Peter

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Zero tolerance on imports

[Anders Arnholm]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

2011-02-21 16:03, Peter Budny skrev:

> it's capable of capturing; OSM's model is much better IMO.  BUT, Waze
> has captured traces of a much larger portion of the US than OSM has.
> Waze has both average and real-time speed data, whereas OSM has no
> provision for this whatsoever.

In sweden Waze have pickes over all up a much smaller part, and have
much more error, extra parallel roads. Waze is a really usefull tool, i
would love them to co-operate with OSM,

> Those of you who think all automated or semi-automated data
> contributions are harmful to OSM are dooming this project to never be
> able to grow to become a leading source of mapping data.

The bigger the data base, the less useful automates imports, or I'm i
missing something?



-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk1jXPcACgkQtbR3SXmySreH/wCeJlqqvDvRWusRV/01tc/GFdKA
OeAAnjW51C+m6nPFgBCIRv+Yr3HGxCqF
=jyFC
-END PGP SIGNATURE-

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Zero tolerance on imports

[Robert Kaiser]

Peter Budny schrieb:

The thing is, whether the work is done by humans or robots, how are you
going to know if it's right?


Now here's the actual argument why automated imports are often a bad 
thing: A lot of data is being added to the database *without being 
checked by anyone* for its quality. You might have seen the Example of 
plan.at in Austria in this thread, we had and have significant problems 
with the data imported from there because some of it is very bad quality 
and has been automatically connected with ways from existing surveyed 
and checked data, so often you can't even easily delete the wrong data 
again without doing harm.


The most important reason why we need actual people to do work on the 
data is because they can check the quality by e.g. going there 
themselves, looking at multiple satellite images, etc. - of course 
including one of the most important items where OSM wins against a lot 
of other map material: local knowledge of the editors.


Robert Kaiser


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Zero tolerance on imports

[Steve Coast]

I prefer this idea:

mapnik etc could render only objects with version 2 or higher. Not only 
does that block out imports, but now we're at the point of completing 
various areas, it will make people go back and check them.


But they will just go and make tiny changes to increment the 
version without checking


yea yeah


On 2/19/2011 5:04 PM, Andrew Errington wrote:

On Sun, 20 Feb 2011 09:40:03 Frederik Ramm wrote:

Finally, all these warnings must sound hollow to someone who lives in a
place where 90% of data around him is imported. You will have a hard
time telling him that imports are bad.

I live in a place where 90% of the data is imported.  Imports are bad.  It's
bad because I discover errors and start to think 'How many more errors must
there be?'.  It's mainly bad for two reasons.  Firstly, the data is old, and
there has been a significant road-building program going on here for a while.
Secondly, things don't join up because the import processing didn't process
road junctions properly, so routing doesn't work (until mappers go around and
join them up).

IMHO imports should exist as 'ghost objects' or 'pencil lines'.  They should
never render on Mapnik etc. and never be used for routing, but a mapper with
local knowledge should be able to verify the objects and change them to a
real object (i.e. 'ink them in').

Of course, if we had one million mappers here they could all take a quick look
at their local area and fix the mistakes in a couple of days...

Best wishes,

Andrew

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk



___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Zero tolerance on imports

[Peter Budny]

Serge Wroclawski  writes:

> On Mon, Feb 21, 2011 at 3:58 PM, Peter Budny  wrote:
>
>> If automated edits are problematic, it's not because the robot
>> apocalypse is coming.  It's because automated edits are hacked together
>> due to a lack of tools and support in OSM for doing anything other than
>> manual editing.  This isn't a problem with automated edits; it's a
>> problem with OSM.
>
> Peter, you've done an excellent job of identifying problems with OSM.
> Do you have any suggestions on how to resolve these issues?

I would be naive to think that I have all the answers, or even some of
them.  It's a lot easier to point out problems than to solve them.
However, you were kind enough to ask, so let me try to do some
brainstorming:

One big issue is that there's no way to combine two disparate sets of
data any way but manually.  Suppose TIGER 2015 data comes out and has
centimeter-accurate centerlines, but still has all the typos and other
nasty things that come with TIGER data.  It would be great to use the
centerlines but keep OSM's edited data for everything else.  Or suppose
I somehow get a database of every McDonald's location in the world,
complete with addresses, phone numbers, etc.

Rather than asking editors to pore over the whole map manually, it would
be better if there were some kind of merge toolkit that can select
portions of multiple data sets and combine them intelligently,
automating the process when there are no conflicts (like a CVS merge).
Of course the process needs to be guided by humans, but they shouldn't
have to select or trace every single road.

Here's another issue that ought to be much easier to solve, but hasn't
been: the relation analyzer.
http://ra.osmsurround.org/analyze.jsp?relationId=36947
That particular relation follows the "correct" practice of using
role=(blank)/forward/backward, but even this isn't recognized by the
analyzer.  What it ought to show is just two chunks: from point A to B,
and from point B to A.  With the current display, how is one supposed to
figure out if relation is completed or not?

What about GPS tracks... how does one deal with those?  The only
interface I know is to click on "GPS Traces" from the slippy map, but
that just gives me a list, and shows every trace in the whole world.  I
only want to see traces for the region I'm looking at, like "show me
every GPS track within 100m of this highway".

I see there's a wiki page on change monitoring, but it doesn't look like
there's anything very sophisticated.  Perusing the history when there
are so many edits that are -180 to 180 is a big turn-off.  If mappers
are supposed to watch their hometown for changes, shouldn't they be
given tools to do that with?


Like I said, this is just brainstorming.  I'm sure other users also have
ideas for tools that would make the editing process a lot less tedious,
without even touching on the topic of automated edits.  Tools like these
can benefit everyone (unlike a discussion on how to tag lumber yards or
hotdog carts or whatever the question du jour is).
-- 
Peter Budny  \
Georgia Tech  \
CS MS student  \

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Zero tolerance on imports

[Serge Wroclawski]

On Mon, Feb 21, 2011 at 3:58 PM, Peter Budny  wrote:

> The thing is, whether the work is done by humans or robots, how are you
> going to know if it's right?

By going to it and checking.

> But anyway... how do you know if the data is right?  OSM doesn't have
> many tools for assisting humans in much of anything, whether it's
> creating new data, or augmenting data with new data sources or with
> information gleaned from examining metadata, or verifying data to make
> sure it's actually accurate.

That's because the assumption of OSM is that data is entered by ground
surveying and therefore things like "This road has N lanes" is assumed
to be true.

> If automated edits are problematic, it's not because the robot
> apocalypse is coming.  It's because automated edits are hacked together
> due to a lack of tools and support in OSM for doing anything other than
> manual editing.  This isn't a problem with automated edits; it's a
> problem with OSM.

Peter, you've done an excellent job of identifying problems with OSM.
Do you have any suggestions on how to resolve these issues?

- Serge

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Zero tolerance on imports

[Tobias Knerr]

On 21.02.2011 21:43, Nathan Edgars II wrote:
> Tordanik wrote:
>>
>> The best way to achieve this, IMO, is to only execute mass edits and
>> imports in collaboration with a local community. This makes sure that
>> there is a sufficiently developed community of mappers "on the ground",
>> allows them to evaluate the data's quality beforehand, and makes it
>> likely that the data will be well integrated into the OSM database soon
>> after the import.
>>
> Would you say the same about mapping in an area you're in on vacation? Or is
> it OK to dump incomplete data on an area with no local community as long as
> it's not an import?

The potential negative effects of manual edits by a foreign mapper are
nowhere close to those of imports. That's because ...

a) ... a visitor will use similar tools as future local mappers. Imports
are, in many ways, different from manual mapping.

b) ... the amount of data that a human will collect during the short
timespan of a vacation will usually not be beyond a future local
community's maintenance capability. Imports are able to generate a lot
more data than that.

Tobias Knerr

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Zero tolerance on imports

[Peter Budny]

Nathan Edgars II  writes:

> Peter Budny wrote:
>> 
>> I really don't mind whether it's route relations or ref tags.  The
>> problem is that NEITHER is finished.  To get to my house, I have to get
>> on State Route 1966, then 1267.  Neither of these are marked as such on
>> the map, and I'm certainly not going to do it by hand when I could write
>> a tool that will fix those AND all the rest of the U.S. at the same
>> time.
>> 
> The big problem with your proposal to auto-generate relations from the TIGER
> tags is that, while TIGER in many/most areas is pretty good for alignment
> and street names, it's pretty horrible for routings of numbered routes in
> built-up areas and with being up-to-date on route changes. I suggest going
> county-by-county through the official listings at
> http://transportation.ky.gov/planning/reports/SPRS_listings/SPRS_listings.asp
> and marking ref tags on each by hand (rather simple after downloading a xapi
> query into JOSM), with FIXME tags where the routing is unclear. Then you can
> auto-generate relations from the ref tags. (Just remember that some routes,
> I think those numbered 6000+, are not signed.)

That's hardly the only problem with it.  There are lots of roads that
are single-carriageway when they should be dual-carriageway, or vice
verse.  Not all dual-carriageway ways are marked oneway=yes.  And yes,
TIGER doesn't always have the route on the correct roads (although I
would argue it's probably a minority of the cases).

The thing is, whether the work is done by humans or robots, how are you
going to know if it's right?  There are a couple tools for it, and
personally I would consider it easier to have the robot do all the
roads, then I compare them to the documents you linked and correct the
ones that are wrong.  If it's correct, it would probably be a lot less
effort to verify that than to create the route relation in the first
place.

But anyway... how do you know if the data is right?  OSM doesn't have
many tools for assisting humans in much of anything, whether it's
creating new data, or augmenting data with new data sources or with
information gleaned from examining metadata, or verifying data to make
sure it's actually accurate.

If automated edits are problematic, it's not because the robot
apocalypse is coming.  It's because automated edits are hacked together
due to a lack of tools and support in OSM for doing anything other than
manual editing.  This isn't a problem with automated edits; it's a
problem with OSM.
-- 
Peter Budny  \
Georgia Tech  \
CS MS student  \

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Zero tolerance on imports

[Nathan Edgars II]

Tordanik wrote:
> 
> The best way to achieve this, IMO, is to only execute mass edits and
> imports in collaboration with a local community. This makes sure that
> there is a sufficiently developed community of mappers "on the ground",
> allows them to evaluate the data's quality beforehand, and makes it
> likely that the data will be well integrated into the OSM database soon
> after the import.
> 
Would you say the same about mapping in an area you're in on vacation? Or is
it OK to dump incomplete data on an area with no local community as long as
it's not an import?
-- 
View this message in context: 
http://gis.638310.n2.nabble.com/Zero-tolerance-on-imports-tp6044534p6050056.html
Sent from the General Discussion mailing list archive at Nabble.com.

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Zero tolerance on imports

[Nathan Edgars II]

Peter Budny wrote:
> 
> I really don't mind whether it's route relations or ref tags.  The
> problem is that NEITHER is finished.  To get to my house, I have to get
> on State Route 1966, then 1267.  Neither of these are marked as such on
> the map, and I'm certainly not going to do it by hand when I could write
> a tool that will fix those AND all the rest of the U.S. at the same
> time.
> 
The big problem with your proposal to auto-generate relations from the TIGER
tags is that, while TIGER in many/most areas is pretty good for alignment
and street names, it's pretty horrible for routings of numbered routes in
built-up areas and with being up-to-date on route changes. I suggest going
county-by-county through the official listings at
http://transportation.ky.gov/planning/reports/SPRS_listings/SPRS_listings.asp
and marking ref tags on each by hand (rather simple after downloading a xapi
query into JOSM), with FIXME tags where the routing is unclear. Then you can
auto-generate relations from the ref tags. (Just remember that some routes,
I think those numbered 6000+, are not signed.)
-- 
View this message in context: 
http://gis.638310.n2.nabble.com/Zero-tolerance-on-imports-tp6044534p6050032.html
Sent from the General Discussion mailing list archive at Nabble.com.

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Zero tolerance on imports

[Tobias Knerr]

On 21.02.2011 19:18, Peter Budny wrote:
> Let me try to elaborate as concisely as possible.
> 
> OSM right now has very little tools to support editing.

Without imports, data creation is performed by the same community, and
with the same tools, as the editing and maintenance that follow data
creation. It is therefore likely that the speed and direction of the
database's development will correspond to community growth and tool
improvements, and will never be overwhelming.

With imports, this isn't guaranteed. It is unfortunately very easy to
move too fast or in the wrong direction with imports, because you are
not using the same tools that you will have to use when you want to
improve the data with local knowledge, or update it when reality changes.

Manual edits are the most important class of contributions to OSM. But
manual edits are performed with a different set of tools than imports,
and by different people. So we need to make sure that our imports do not
create data that cannot (due to amount or complexity) be handled easily
by existing local communities with the available tools for manual editing.

The best way to achieve this, IMO, is to only execute mass edits and
imports in collaboration with a local community. This makes sure that
there is a sufficiently developed community of mappers "on the ground",
allows them to evaluate the data's quality beforehand, and makes it
likely that the data will be well integrated into the OSM database soon
after the import.

Tobias Knerr

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Zero tolerance on imports

[Peter Budny]

SomeoneElse  writes:

> On 21/02/2011 18:03, Peter Budny wrote:
>> Okay, even if we accept that -- and many OSM mappers do not,
> They've clearly not heard the posh woman inside my satnav then - she
> has no problems pronouncing "name" and "ref" information on roads (she
> can't pronounce "Huthwaite", but that's another problem).
>
> The UK road numbering rules are different from the US in that one road
> can be part of more than one route (in the UK if routes A1234 and
> A2345 joined for a bit and then separated the joint bit would be
> labelled A1234 or A2345, but not both) so I guess that that's why
> you're keen to create lots of route relations.  The problem is,
> changes like these are not actually getting unmapped stuff mapped or
> capturing extra detail.

I really don't mind whether it's route relations or ref tags.  The
problem is that NEITHER is finished.  To get to my house, I have to get
on State Route 1966, then 1267.  Neither of these are marked as such on
the map, and I'm certainly not going to do it by hand when I could write
a tool that will fix those AND all the rest of the U.S. at the same
time.
-- 
Peter Budny  \
Georgia Tech  \
CS MS student  \

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Zero tolerance on imports

[Peter Budny]

Jean-Marc Liotier  writes:

> Peter Budny wrote:
>> OSM right now has very little tools to support editing.  Compare this to
>> text processing  [..]
>
> This thread certainly has something to do with advanced version
> control for geographic data. That said, a discussion that happened a
> few months ago here
> (http://www.mail-archive.com/talk@openstreetmap.org/msg33788.html) did
> not conclude positively about branching and merging being capable of
> solving the import management conundrum.

That's good to hear (I admit to not being on the lists much the last few
months).

I'm not surprised that people couldn't get behind a branch-merge system;
it works well enough for source code and text, usually, but that doesn't
mean it's perfect for an entirely different type of data.

All that says to me, is that OSM should look at OTHER techniques for
handling data.

For instance, how might one merge three sets of data... let's say, TIGER
has good coverage but bad alignment and bad name tags, another data set
may have good centerlines but no tags, and a third may have good name
tags but poor coverage.  Surely there is a way to integrate all of these
(and merge them with existing OSM data) other than to just open it all
in JOSM and do it by hand?
-- 
Peter Budny  \
Georgia Tech  \
CS MS student  \

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Zero tolerance on imports

[Kevin Peat]

Peter,

I have nothing against automated edits in general as long as they are
useful, are tested properly and don't overwrite other people's efforts
without agreement. As I mentioned earlier in this thread I think the
difficulty in contacting contributors in an area makes that hard to do.

I am not interested in contributing to Waze but I have skimmed their forums
out of curiosity and they don't seem to have any answers to these problems
as far as I can see. They may have traction in the US but the Waze map of
the UK looks like it was drawn by a five year-old.

In the case of Josh Doe's centreline data if he can't do it himself he
should try to team up with someone who can produce a tool to compare the
highway geometries in the two data-sets and take it from there. Maybe you
could give him a hand with that or know someone who might help?

Kevin




On 21 February 2011 18:03, Peter Budny  wrote:

> Okay, even if we accept that -- and many OSM mappers do not, which is
> why there are tens of thousands of route relations in the database --
> who is going to add all those ref tags?
>
> You haven't addressed the original problem, which is that there is a lot
> of editing to be done, some of which is tedious and easily performed by
> computers.
>
> ~ Peter Budny
>
> Kevin Peat  writes:
>
> > You don't need a route relation to do that just a ref tag.
> >
> > Kevin
> >
> > On 21 February 2011 17:40, Jean-Marc Liotier  wrote:
> >
> > Navigation, for starters : turn-by-turn indications are improved by
> being
> > able to mention "turn left on route 35".
> >
> > Besides, it is static geographic data which fits OpenStreetMap's
> basic
> > purpose, so as long as it does not step on anyone's toes it is
> relevant
> > even if there is only one user.
> >
> > ___
> > talk mailing list
> > talk@openstreetmap.org
> > http://lists.openstreetmap.org/listinfo/talk
> >
> > ___
> > talk mailing list
> > talk@openstreetmap.org
> > http://lists.openstreetmap.org/listinfo/talk
>
> --
> Peter Budny  \
> Georgia Tech  \
> CS MS student  \
>
> ___
> talk mailing list
> talk@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Zero tolerance on imports

[SomeoneElse]

On 21/02/2011 18:03, Peter Budny wrote:

Okay, even if we accept that -- and many OSM mappers do not,
They've clearly not heard the posh woman inside my satnav then - she has 
no problems pronouncing "name" and "ref" information on roads (she can't 
pronounce "Huthwaite", but that's another problem).


The UK road numbering rules are different from the US in that one road 
can be part of more than one route (in the UK if routes A1234 and A2345 
joined for a bit and then separated the joint bit would be labelled 
A1234 or A2345, but not both) so I guess that that's why you're keen to 
create lots of route relations.  The problem is, changes like these are 
not actually getting unmapped stuff mapped or capturing extra detail.



You haven't addressed the original problem, which is that there is a lot
of editing to be done, some of which is tedious and easily performed by
computers.

Actually, I'm really not convinced that there's a lot of EDITING to be 
done.  In some cases there is a bit of tidying (such as "someone drew 
some roads that didn't quite join, whereas in the real world they do") 
but in most cases it's ADDING that's needed.  There might be a lot of 
editing needs doing where crap has been imported, but that's a different 
issue.


What there are are lots of blank spaces on the map.  For example, I 
spent Sunday afternoon here:

http://www.openstreetmap.org/?lat=52.7692&lon=-0.6682&zoom=13&layers=M

A couple of bits could count as "editing" but most of it was adding new 
stuff that (a) hadn't been added to OSM before and (b) isn't actually 
freely accessible anywhere else (or isn't recorded anywhere at all), and 
that you can only find out by Actually Going There.  Unfortunately 
there's no Big Goverment Dataset that says that there's a stile here, or 
that Path X is blocked by a barbed wire fence, or that you have to climb 
over a wall to get to Y.


As "http://weait.com/content/how-well-can-you-map"; says: "A mapper on 
every block.  That's what we want. Tell your friends. "


Cheers,
Andy


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Zero tolerance on imports

[Jean-Marc Liotier]

Peter Budny wrote:

OSM right now has very little tools to support editing.  Compare this to
text processing  [..]


This thread certainly has something to do with advanced version control 
for geographic data. That said, a discussion that happened a few months 
ago here 
(http://www.mail-archive.com/talk@openstreetmap.org/msg33788.html) did 
not conclude positively about branching and merging being capable of 
solving the import management conundrum.


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Zero tolerance on imports

[Josh Doe]

I believe imports can be great, but of course can be dangerous. Better
tools are needed, and maybe someday I'll have the skills and know-how
to help with them.

There's one thing that hasn't explicitly been mentioned. Some say we
don't want to import because it will demotivate people to start
contributing in that area. I can understand that, however, if we
_KNOW_ the data is good, and we're careful to maintain the
contributions already in existence, I'd much rather import the entire
road network for an area, and have interested contributors not just
FIX the data, but actually improve OSM by adding additional tags, map
nearby paths, add intersections, etc.

It is a terrible waste of human effort to reproduce verified
high-quality data that is available and properly licensed. Their time
is much better spent adding value to the map by improving the tags,
adding unmapped paths, etc. The big problem with imports now is the
lack of good tools, though I'm not complaining because I know they
take a lot of effort to design and create.

Regards,
-Josh

On Mon, Feb 21, 2011 at 10:03 AM, Peter Budny  wrote:
> I find this discussion very distasteful.
>
> I really like OSM's goals: a complete map of the Earth with more-or-less
> unlimited detail.  But I don't understand why people think that this
> 500+ GIGABYTE map should be managed using 19th-century methods,
> i.e. manual labor.
>
> Waze is a much newer project than OSM.  I don't really care for its data
> model, because I think it's much too limited in the amount of detail
> it's capable of capturing; OSM's model is much better IMO.  BUT, Waze
> has captured traces of a much larger portion of the US than OSM has.
> Waze has both average and real-time speed data, whereas OSM has no
> provision for this whatsoever.
>
> At some point, OSM will reach a size -- either size of database, or
> number of users/contributors -- where it will become totally infeasible
> to manage with the tools we have (or rather, the tools we don't have).
>
> Those of you who think all automated or semi-automated data
> contributions are harmful to OSM are dooming this project to never be
> able to grow to become a leading source of mapping data.
>
> Do you think that when MapQuest started using OSM data to generate their
> maps, they performed all the necessary data transformations BY HAND?
>
> Last year, as part of a school project, I built a robot that will
> automatically create route relations for all the state highways in the
> US, being careful not to change or duplicate existing data.  I haven't
> shared it with the community because a handful of users were so
> terrified of the prospect of automated edits, they insisted I do a
> large-scale trial run on a local copy of the database, and I haven't had
> the time to compile the results of those trial runs for review.  The
> code would be in use already if not for a few people running around
> panicking about my devil-robot and its witchcraft.
>
>
> ... I don't even know how to end this e-mail.  I'm so distressed by what
> I'm reading that it makes me want to just walk away from the whole
> project.
> --
> Peter Budny  \
> Georgia Tech  \
> CS MS student  \
>
> ___
> talk mailing list
> talk@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk
>

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Zero tolerance on imports

[Peter Budny]

Serge Wroclawski  writes:

> On Mon, Feb 21, 2011 at 10:03 AM, Peter Budny  wrote:
>> I find this discussion very distasteful.
>
> Peter,
>
> I'm sorry that you feel that way. Can you tell us what specifically
> you find distasteful? Is it the issue of automated edits or is there
> something else?

Let me try to elaborate as concisely as possible.

OSM right now has very little tools to support editing.  Compare this to
text processing, where we have diff, patch, CVS and Subversion, etc.
The tools can't handle every case, but they do the tedious work and help
support higher-level functionality.  Wikipedia extended this to support
crowd-sourced editing, and has support for, e.g. detecting a reverting
vandalism.

Right now OSM lacks tools like that.  When a user like Josh Doe has a
data source with hyper-accurate road centerlines, the only way to
integrate that into OSM is manually.  When someone else destroys some
existing data, either accidentally or maliciously, we have to post to
the newsgroups to get an admin to fix things manually.

There is a whole realm of tools and techniques to support computerized
mapping that are waiting to be developed.  No doubt other groups like
Google, Bing, and even MapQuest are already working on them.

I really don't understand how certain individuals propose to manage a
large database with many contributors WITHOUT the aid of tools to make
the humans' jobs easier.

>> I really like OSM's goals: a complete map of the Earth with more-or-less
>> unlimited detail.  But I don't understand why people think that this
>> 500+ GIGABYTE map should be managed using 19th-century methods,
>> i.e. manual labor.
>
> I the issue, which Wikipedia also faces, is that automated edits have
> a history of being problematic for the project.
>
> A very small number of people in the community are against all
> automated edits, but a majority of us are concerned that current
> automated edits have been so problematic as to turn away users and
> contributors.
>
> What we're discussing is how to get good automated edits while still
> allowing for 20th century methods of input, which include on the
> ground surveying.

See above.  I generally agree with this goal.

>> Waze is a much newer project than OSM.  I don't really care for its data
>> model, because I think it's much too limited in the amount of detail
>> it's capable of capturing; OSM's model is much better IMO.
>
> Waze is proprietary. Is that right?

My point, as below, was that Waze is another crowd-sourced map which has
much better tools and support for semi-automated editing than OSM does.
What difference does the license make?

>> BUT, Waze has captured traces of a much larger portion of the US than
>> OSM has.  Waze has both average and real-time speed data, whereas OSM
>> has no provision for this whatsoever.
-- 
Peter Budny  \
Georgia Tech  \
CS MS student  \

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Zero tolerance on imports

[M∡rtin Koppenhoefer]

2011/2/21 Kevin Peat :
> You don't need a route relation to do that just a ref tag.


+1

you need the relation if there is more than one route using the same
street (because ref=23;42 is ugly). The relation might also be
convenient for mappers to download a longer and in great detail (split
ways) mapped road.

Cheers,
Martin

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Zero tolerance on imports

[Peter Budny]

Okay, even if we accept that -- and many OSM mappers do not, which is
why there are tens of thousands of route relations in the database --
who is going to add all those ref tags?

You haven't addressed the original problem, which is that there is a lot
of editing to be done, some of which is tedious and easily performed by
computers.

~ Peter Budny

Kevin Peat  writes:

> You don't need a route relation to do that just a ref tag.
>
> Kevin
>
> On 21 February 2011 17:40, Jean-Marc Liotier  wrote:
>
> Navigation, for starters : turn-by-turn indications are improved by being
> able to mention "turn left on route 35".
>
> Besides, it is static geographic data which fits OpenStreetMap's basic
> purpose, so as long as it does not step on anyone's toes it is relevant
> even if there is only one user.
>
> ___
> talk mailing list
> talk@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk
>
> ___
> talk mailing list
> talk@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk

-- 
Peter Budny  \
Georgia Tech  \
CS MS student  \

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Zero tolerance on imports

[Alex Mauer]

On 02/21/2011 11:26 AM, Kevin Peat wrote:

The point isn't whether or not your tool will create correct route relations
but what the point of doing that would be. I can understand creating route
relations for long distance cycling/hiking paths that people actually want
to navigate and historic routes (Route 66 comes to mind as a non-American)
but what is the point of creating a route relation for every highway?


Getting highway shields to render, for one.


No-one gets up in the morning and decides to navigate "State Highway 483"
from one end to the other and even if they did a decent routing engine could
create the route on the fly, so adding it to OSM is a waste of time and
would just add pointless complexity to the data-set.


No one?  Really?  Pretty sure that some people do in fact do this sort 
of thing…


—Alex Mauer “hawke”


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Zero tolerance on imports

[Kevin Peat]

You don't need a route relation to do that just a ref tag.

Kevin


On 21 February 2011 17:40, Jean-Marc Liotier  wrote:

>
> Navigation, for starters : turn-by-turn indications are improved by being
> able to mention "turn left on route 35".
>
> Besides, it is static geographic data which fits OpenStreetMap's basic
> purpose, so as long as it does not step on anyone's toes it is relevant even
> if there is only one user.
>
>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Zero tolerance on imports

[Jean-Marc Liotier]

Kevin Peat wrote:


The point isn't whether or not your tool will create correct route 
relations but what the point of doing that would be. I can understand 
creating route relations for long distance cycling/hiking paths that 
people actually want to navigate and historic routes (Route 66 comes to 
mind as a non-American) but what is the point of creating a route 
relation for every highway?


Navigation, for starters : turn-by-turn indications are improved by 
being able to mention "turn left on route 35".


Besides, it is static geographic data which fits OpenStreetMap's basic 
purpose, so as long as it does not step on anyone's toes it is relevant 
even if there is only one user.



___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Zero tolerance on imports

[Kevin Peat]

Peter,

The point isn't whether or not your tool will create correct route relations
but what the point of doing that would be. I can understand creating route
relations for long distance cycling/hiking paths that people actually want
to navigate and historic routes (Route 66 comes to mind as a non-American)
but what is the point of creating a route relation for every highway?

No-one gets up in the morning and decides to navigate "State Highway 483"
from one end to the other and even if they did a decent routing engine could
create the route on the fly, so adding it to OSM is a waste of time and
would just add pointless complexity to the data-set.

Kevin




On 21 February 2011 16:58, Peter Budny  wrote:

> Frederik Ramm  writes:
>
> > Hi,
> >
> > On 02/21/2011 04:03 PM, Peter Budny wrote:
> >> Those of you who think all automated or semi-automated data
> >> contributions are harmful to OSM are dooming this project to never be
> >> able to grow to become a leading source of mapping data.
> >
> > It is a common fallacy to believe that good map data could somehow,
> > magically, be produced from computers that evaluate GPS tracks, camera
> > recordings, or aerial imagery.
> >
> > If this were possible, then Google et al. would be 10 times as good at
> > doing it as we are.
>
> Google, like Waze, has both historic and real-time traffic data
> automatically generated by millions people with mobile phones.  So in at
> least some ways, they ARE 10 times better than OSM.
>
> > The strength of OSM is the people on the ground. If you try to
> > eliminate them from the equation
>
> Whoa, who said anything about eliminating people?  What I'm saying is
> that we should find ways to integrate human editors with automated or
> semi-automated tools, so that humans can delegate the tedious work to
> computers and spend more time doing things that can't be handled by
> computers.
>
> >> Last year, as part of a school project, I built a robot that will
> >> automatically create route relations for all the state highways in the
> >> US, being careful not to change or duplicate existing data.
> >
> > [...]
> >
> >> The code would be in use already if not for a few people running around
> >> panicking about my devil-robot and its witchcraft.
> >
> > Maybe you haven't been able to demonstrate the added value your
> > mechanical edit would bring to the database?
>
> The value is that
> http://wiki.openstreetmap.org/wiki/Kentucky#State_routes would show
> route relations for all 6000+ state routes in Kentucky, instead of
> 7... and then I could use the same code to finish the other 49 states in
> the US.  And then with minor modifications, I could use the same code in
> other countries.
>
> As an analogy, we store OSM's source code in Subversion and Git, and let
> those tools compare files when we make a change.  Could this be done by
> hand?  Of course.  But why would you want to?  You would produce the
> same result (actually, you're more likely to make a mistake than the
> computer).  Yes, sometimes the tools come upon situations they can't
> handle, and have to let a human intervene, but they relieve us of the
> tedious bits.
>
> Some people look at OSM and say, "It needs more tools."  Some people
> say, "It needs less tools."  Consider me firmly in the first camp.
>
> > I mean, if it can be
> > determined by a robot, then surely it would be redundant to have it in
> > the data again?
>
> First, your reasoning is specious.  Consider a shopping receipt: what's
> the "added value" to listing a subtotal and total, when these could be
> trivially computed by summing the items purchased and subtracting the
> amount paid?
>
> Second, the robot's contributions would not be perfect... but then
> again, neither are mine.  I've never drive down Kentucky State Highway
> 483, so any edits I make to it are merely the best I can do given what's
> already in OSM.  But if I see tiger:name_base="State Highway 483", I'm
> going to put it in a relation with the other ways that match it.  A
> robot can do exactly the same thing, only a lot more efficiently than I
> can.
>
> And before you counter... no, I don't think it's pointless or wrong to
> edit a part of the map I've never been to.  If I (or anyone else) ever
> DOES go there, it would be nice to have already improved the map as much
> as possible, rather than letting it remain a completely unedited jumble
> or void.
> --
> Peter Budny  \
> Georgia Tech  \
> CS MS student  \
>
> ___
> talk mailing list
> talk@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Zero tolerance on imports

[Peter Budny]

Frederik Ramm  writes:

> Hi,
>
> On 02/21/2011 04:03 PM, Peter Budny wrote:
>> Those of you who think all automated or semi-automated data
>> contributions are harmful to OSM are dooming this project to never be
>> able to grow to become a leading source of mapping data.
>
> It is a common fallacy to believe that good map data could somehow,
> magically, be produced from computers that evaluate GPS tracks, camera
> recordings, or aerial imagery.
>
> If this were possible, then Google et al. would be 10 times as good at
> doing it as we are.

Google, like Waze, has both historic and real-time traffic data
automatically generated by millions people with mobile phones.  So in at
least some ways, they ARE 10 times better than OSM.

> The strength of OSM is the people on the ground. If you try to
> eliminate them from the equation

Whoa, who said anything about eliminating people?  What I'm saying is
that we should find ways to integrate human editors with automated or
semi-automated tools, so that humans can delegate the tedious work to
computers and spend more time doing things that can't be handled by
computers.

>> Last year, as part of a school project, I built a robot that will
>> automatically create route relations for all the state highways in the
>> US, being careful not to change or duplicate existing data.
>
> [...]
>
>> The code would be in use already if not for a few people running around
>> panicking about my devil-robot and its witchcraft.
>
> Maybe you haven't been able to demonstrate the added value your
> mechanical edit would bring to the database?

The value is that
http://wiki.openstreetmap.org/wiki/Kentucky#State_routes would show
route relations for all 6000+ state routes in Kentucky, instead of
7... and then I could use the same code to finish the other 49 states in
the US.  And then with minor modifications, I could use the same code in
other countries.

As an analogy, we store OSM's source code in Subversion and Git, and let
those tools compare files when we make a change.  Could this be done by
hand?  Of course.  But why would you want to?  You would produce the
same result (actually, you're more likely to make a mistake than the
computer).  Yes, sometimes the tools come upon situations they can't
handle, and have to let a human intervene, but they relieve us of the
tedious bits.

Some people look at OSM and say, "It needs more tools."  Some people
say, "It needs less tools."  Consider me firmly in the first camp.

> I mean, if it can be
> determined by a robot, then surely it would be redundant to have it in
> the data again?

First, your reasoning is specious.  Consider a shopping receipt: what's
the "added value" to listing a subtotal and total, when these could be
trivially computed by summing the items purchased and subtracting the
amount paid?

Second, the robot's contributions would not be perfect... but then
again, neither are mine.  I've never drive down Kentucky State Highway
483, so any edits I make to it are merely the best I can do given what's
already in OSM.  But if I see tiger:name_base="State Highway 483", I'm
going to put it in a relation with the other ways that match it.  A
robot can do exactly the same thing, only a lot more efficiently than I
can.

And before you counter... no, I don't think it's pointless or wrong to
edit a part of the map I've never been to.  If I (or anyone else) ever
DOES go there, it would be nice to have already improved the map as much
as possible, rather than letting it remain a completely unedited jumble
or void.
-- 
Peter Budny  \
Georgia Tech  \
CS MS student  \

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Zero tolerance on imports

[Frederik Ramm]

Hi,

On 02/21/2011 04:03 PM, Peter Budny wrote:

Those of you who think all automated or semi-automated data
contributions are harmful to OSM are dooming this project to never be
able to grow to become a leading source of mapping data.


It is a common fallacy to believe that good map data could somehow, 
magically, be produced from computers that evaluate GPS tracks, camera 
recordings, or aerial imagery.


If this were possible, then Google et al. would be 10 times as good at 
doing it as we are.


The strength of OSM is the people on the ground. If you try to eliminate 
them from the equation you're left with an average quality, patchy map - 
and not the great map of the future that you seem to envisage. We want 
to make the map of the people, where everyone participates and feels 
responsible for his part in the work. This is not the Great Government 
Data Dump.



Last year, as part of a school project, I built a robot that will
automatically create route relations for all the state highways in the
US, being careful not to change or duplicate existing data.


[...]


The code would be in use already if not for a few people running around
panicking about my devil-robot and its witchcraft.


Maybe you haven't been able to demonstrate the added value your 
mechanical edit would bring to the database? I mean, if it can be 
determined by a robot, then surely it would be redundant to have it in 
the data again?


Bye
Frederik

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Zero tolerance on imports

[Thomas Davie]

> 
> Do you think that when MapQuest started using OSM data to generate their
> maps, they performed all the necessary data transformations BY HAND?

Do you think that MapQuest would be using OSM data at all if it was no more 
accurate than the data they could automatically import themselves?

Bob
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Zero tolerance on imports

[Serge Wroclawski]

On Mon, Feb 21, 2011 at 10:03 AM, Peter Budny  wrote:
> I find this discussion very distasteful.

Peter,

I'm sorry that you feel that way. Can you tell us what specifically
you find distasteful? Is it the issue of automated edits or is there
something else?

>
> I really like OSM's goals: a complete map of the Earth with more-or-less
> unlimited detail.  But I don't understand why people think that this
> 500+ GIGABYTE map should be managed using 19th-century methods,
> i.e. manual labor.

I the issue, which Wikipedia also faces, is that automated edits have
a history of being problematic for the project.

A very small number of people in the community are against all
automated edits, but a majority of us are concerned that current
automated edits have been so problematic as to turn away users and
contributors.

What we're discussing is how to get good automated edits while still
allowing for 20th century methods of input, which include on the
ground surveying.

> Waze is a much newer project than OSM.  I don't really care for its data
> model, because I think it's much too limited in the amount of detail
> it's capable of capturing; OSM's model is much better IMO.

Waze is proprietary. Is that right?

>  BUT, Waze
> has captured traces of a much larger portion of the US than OSM has.
> Waze has both average and real-time speed data, whereas OSM has no
> provision for this whatsoever.

That's true. I think some of this data could have come in through
Transiki, but that project appears permanently on hold.

Maybe y0u can be one of the people to revive it?

> At some point, OSM will reach a size -- either size of database, or
> number of users/contributors -- where it will become totally infeasible
> to manage with the tools we have (or rather, the tools we don't have).

That's the issue we're discussing, and await your suggestions on ways
to move forward with better tools.

> Those of you who think all automated or semi-automated data
> contributions are harmful to OSM are dooming this project to never be
> able to grow to become a leading source of mapping data.

Peter, how does this mail help move the conversation for better tools forward?

> Do you think that when MapQuest started using OSM data to generate their
> maps, they performed all the necessary data transformations BY HAND?

They didn't make many changes to OSM AFAICT. According to the talk
they gave, they did indeed find many problems by hand, and had to make
manual fixes.

> Last year, as part of a school project, I built a robot that will
> automatically create route relations for all the state highways in the
> US, being careful not to change or duplicate existing data.  I haven't
> shared it with the community because a handful of users were so
> terrified of the prospect of automated edits, they insisted I do a
> large-scale trial run on a local copy of the database, and I haven't had
> the time to compile the results of those trial runs for review.  The
> code would be in use already if not for a few people running around
> panicking about my devil-robot and its witchcraft.

How could those user's concerns be addressed while still making things
easy for you to do?

- Serge

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Zero tolerance on imports

[Peter Budny]

I find this discussion very distasteful.

I really like OSM's goals: a complete map of the Earth with more-or-less
unlimited detail.  But I don't understand why people think that this
500+ GIGABYTE map should be managed using 19th-century methods,
i.e. manual labor.

Waze is a much newer project than OSM.  I don't really care for its data
model, because I think it's much too limited in the amount of detail
it's capable of capturing; OSM's model is much better IMO.  BUT, Waze
has captured traces of a much larger portion of the US than OSM has.
Waze has both average and real-time speed data, whereas OSM has no
provision for this whatsoever.

At some point, OSM will reach a size -- either size of database, or
number of users/contributors -- where it will become totally infeasible
to manage with the tools we have (or rather, the tools we don't have).

Those of you who think all automated or semi-automated data
contributions are harmful to OSM are dooming this project to never be
able to grow to become a leading source of mapping data.

Do you think that when MapQuest started using OSM data to generate their
maps, they performed all the necessary data transformations BY HAND?

Last year, as part of a school project, I built a robot that will
automatically create route relations for all the state highways in the
US, being careful not to change or duplicate existing data.  I haven't
shared it with the community because a handful of users were so
terrified of the prospect of automated edits, they insisted I do a
large-scale trial run on a local copy of the database, and I haven't had
the time to compile the results of those trial runs for review.  The
code would be in use already if not for a few people running around
panicking about my devil-robot and its witchcraft.


... I don't even know how to end this e-mail.  I'm so distressed by what
I'm reading that it makes me want to just walk away from the whole
project.
-- 
Peter Budny  \
Georgia Tech  \
CS MS student  \

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Zero tolerance on imports

[Mike N]

On 2/21/2011 5:44 AM, Peter Wendorff wrote:

And finally we should work on reduction of the fear to make things
wrong, as I think, that fear is growing with growing complexity of
existant data.


I consider myself fairly comfortable with the editing tools, but 
recently while attempting to enter data from survey obtained during 
travel, I was completely intimidated by the cluster of landuse + admin 
boundary + "Communications infrastructure" imports.   I believe other 
tools place these on separate layers to avoid information overload.


  Next time I travel to that region again, I won't bother to survey; 
it's too much hassle to try to enter information in the tangled jumble 
of lines.


  I agree with those who have experienced mixed results after importing 
land use data - think 3 times before bringing it into your area, if at 
all.   If you just want 'colored maps' for your region, it should be 
possible to combine these at render time.


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Zero tolerance on imports

[NopMap]

Hi!

There is a considerable difference between an import into a mostly empty
area - which is rather easy to achieve and mostly helpful - and an import
into an already basically mapped area, which is hard to integrate and where
existing data may be damaged. I believe that this should not happen,
existing survey results should always have precendence over arial imagery or
imported data. I believe that that a proper integration into existing data
is hard to achieve, therefore it should not be done by beginners and it
should be coordinated.

There appears to be a common misconception that arial imagery and imported
data is somehow "better by default" than the hand-drawn traces. Imports
should not duplicate existing data and should not overwrite it. Badly
executed imports can cripple the whole data in an area, replace current
information by obsolete data and badly tagged imports can mess up whole
tagging schemes by suddenly pushing the bad tagging as the majority use.

To make a long story short, I believe that imports should be restricted or
checked very tightly, except for "first" imports into a mostly empty area.

When it comes to motivation, I was very happy to find that my chief area of
interest was mostly empty, with just one major road and the motorway. This
appealed to my sense as an "explorer" who could make a visible difference to
the map. I happily spent a few weekends driving around and mapping all the
secondary roads. When it became available, I appreciated arial imagery as a
help to trace rivers and forests, which are hard to grasp otherwise, but
stopped using it for roads and paths as in later surveys I found that the
impression about the nature of the way derived from the picture was
frequently wrong. A year later the map was mostly complete and it got
boring. So I mapped the routes that I came along anyway, but I did no longer
feel like going out of my way to map a neighboring area - it was already
there, it was usable - why bother?

So, personally, I believe that drawing the first roads on an empty map is
much more fun and motivation than fixing mistakes in someone else's imported
data. If the actuality, accuracy and quality of data is less than excellent,
I would rather not import it at all. Motivated mappers can do better.

bye
   Nop

-- 
View this message in context: 
http://gis.638310.n2.nabble.com/Zero-tolerance-on-imports-tp6044534p6048406.html
Sent from the General Discussion mailing list archive at Nabble.com.

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Zero tolerance on imports

[Peter Wendorff]

Hi.

Why we discuss the goodness or badness of imports here with the argument 
of a complete map?


Of course that argument is a good one - but if we look towards the 
future there will be a time - partly that's already in the present, 
where an area is mapped already with high detail by mappers not active 
any more.


A new mapper, I believe, will not distinct between a (relatively good) 
import and years of manpower of ground-survey-mapping done in the 
previous two decades etc.


We see a growing complexity in many tagging schemes, use of more and 
more sophisticated relations to model facts, and the discussion is only 
about "ban imports".


I agree, that imports should not lead to automatic or semi-automatic 
deletion of mappers work.
I agree that imports have to be done carefully and with inclusion of the 
local community/s.


But I think, we need mechanism to generally cope with the "problem" of 
existing data.
We should put more effort in developing mechanisms to check, proofe and 
control existing data - not caring about import or "simply old" data.
And finally we should work on reduction of the fear to make things 
wrong, as I think, that fear is growing with growing complexity of 
existant data.


Banning import is a easy mantra to push out today as it avoids the 
bigger problem - but in future we will have the same problem with a bad 
connotation: in future the existent "old" mappers are human parts of the 
community, whose data probably has to be deleted whereas today we speak 
about technical data and single importers.
These importers are often people who want to discuss and work on their 
imports.

We should take this as a chance, not as an affront.

regards
Peter

Am 21.02.2011 01:03, schrieb Felix Hartmann:



On 21.02.2011 00:47, Daniel Sabo wrote:

On Feb 20, 2011, at 3:16 PM, Felix Hartmann wrote:

Couldn't agree more to it. Imports kill community and scare novices 
away.

...
Most important things for OSM are good aerial photos coupled with 
large community. Worst are imports. The United States are so bad, I 
don't think OSM will ever become important there. The biggest thing 
to remember is that "creating" something is much more fun than 
correcting it. Imports make OSM a chore and no fun.
As a former novice I completely disagree with you here. If the TIGER 
import hadn't happened I would have had zero interest in OSM, a vast 
empty map is not very inspiring.


But really, no one here has hard data, whenever we say "it destroys 
the community" or "it helps the community"  we're just throwing 
anecdotes at each other. What we need are better tools to build a 
community like Serge and Kevin are talking about, a dozen of us 
arguing on a mailing list about what 360k people "really want" isn't 
going to accomplish much.


- Daniel

Well we have no hard data, but evidence. Basically no users and 
editors in the US but loads in Europe. And loads of countries without 
imports flourishing as communities start to grow (like Slovakia, Czech 
Republic, Italy, Switzerland, Germany, Denmark) but less involvement 
in countries with imports. A vast empty map is no fun, but neither is 
a complete map. The worst is a seemingly complete map, with crap data 
(like plan.at data in Austria, that was in general off by around 
20-100m).


Just show me some neighboring countries where the one with imports 
some time ago (minimum 1 year) are doing better than neighboring 
countries/regions where no imports took place.


I think imports are good for stuff we cannot easily record ourselves 
(like borders) - but no good for stuff we can get ourselves.
And if you see tracing from aerial imagery as a chore, you're making a 
mistake. I think we should wait till local people do it. That way it 
gets better quality and is not much work for anyone. We should not 
strive to be complete, but offer more or different data than 
commercial map providers, because that's where we are good at. 
Striving to get a map with best use for carnavigation will not happen 
- our structure and means are really inferior here. Getting speciality 
maps noone can compete with large communities.


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk




___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Zero tolerance on imports

[Tanveer Singh]

On Mon, Feb 21, 2011 at 2:29 PM, Thomas Davie  wrote:

>
> On 21 Feb 2011, at 07:09, yvecai wrote:
>
> > IMO, 'imports' should be simply considered as datasources, not data.
> > We lack tools to properly use this data. Having great tools like for
> imagery or GPS tracks in the various editors, maybe with a copy/paste
> feature to import data semi-manually would be very valuable.
> > Then the 'import' job could just be to make the datasource easy to use to
> contributors.
> > A server to centralize this datasets could help for visibility.
>
> Just to throw another anecdote out there – I did look at OSM many years
> ago.  At the time I thought "pt, they haven't even got my country on the
> map, let alone the little town I'm in, there's no way this'll get anywhere".
>  A few years later I became a contributer because there was at least *some*
> data available that made the map useful – all I had to do was make it *more*
> useful.
>
> What I'm saying is that to me, no data was more of a turn off than some
> data.
>
> I'd suggest that instead of simply banning imports we need better tools for
> monitoring map quality and for showing users what our monitoring tool thinks
> of their area.  If we tell new users "hey, look at this bug list/source/date
> of origin overlay and see what you can add/change/delete/fix/..." rather
> than simply presenting them with a map that may or may not be correct we
> might get more communities spring up.
>
> Essentially – tell people what they can do to help more clearly!
>
> Bob
> ___
> talk mailing list
> talk@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk
>
India had very low coverage, and even now many areas lack coverage.
whenever I go to a new area and try mapping it, I see lot of roads where
there are no roads, infact there cannot be roads.
Just some junk data imported.
Its such a big mess, and often I have to do bulk deletes in remove areas.
Infact sometimes I refrain, because I cannot tell the actual good data from
junk data due to poor quality of satellite imagery.
I would not advocate "banning" imports, but restricting them is a very good
idea.
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Zero tolerance on imports

[Thomas Davie]

On 21 Feb 2011, at 07:09, yvecai wrote:

> IMO, 'imports' should be simply considered as datasources, not data.
> We lack tools to properly use this data. Having great tools like for imagery 
> or GPS tracks in the various editors, maybe with a copy/paste feature to 
> import data semi-manually would be very valuable.
> Then the 'import' job could just be to make the datasource easy to use to 
> contributors.
> A server to centralize this datasets could help for visibility.

Just to throw another anecdote out there – I did look at OSM many years ago.  
At the time I thought "pt, they haven't even got my country on the map, let 
alone the little town I'm in, there's no way this'll get anywhere".  A few 
years later I became a contributer because there was at least *some* data 
available that made the map useful – all I had to do was make it *more* useful.

What I'm saying is that to me, no data was more of a turn off than some data.

I'd suggest that instead of simply banning imports we need better tools for 
monitoring map quality and for showing users what our monitoring tool thinks of 
their area.  If we tell new users "hey, look at this bug list/source/date of 
origin overlay and see what you can add/change/delete/fix/..." rather than 
simply presenting them with a map that may or may not be correct we might get 
more communities spring up.

Essentially – tell people what they can do to help more clearly!

Bob
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Zero tolerance on imports

[yvecai]

IMO, 'imports' should be simply considered as datasources, not data.
We lack tools to properly use this data. Having great tools like for 
imagery or GPS tracks in the various editors, maybe with a copy/paste 
feature to import data semi-manually would be very valuable.
Then the 'import' job could just be to make the datasource easy to use 
to contributors.

A server to centralize this datasets could help for visibility.

Yves

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Zero tolerance on imports

[Julio Costa Zambelli]

On 20 February 2011 21:03, Felix Hartmann  wrote:

>
> Just show me some neighboring countries where the one with imports some
> time ago (minimum 1 year) are doing better than neighboring
> countries/regions where no imports took place.
>
>
Dear Felix,

Take a look at Argentina, Bolivia, Chile and Peru. As long as I know, the
Argentinians, Bolivians, and Peruvians haven't done any massive importation
processes, here in Chile we have done the aforementioned imports, including
all the suburban highways, from the dataset liberated by the Government a
couple of years ago (Late 2008).

Buenos Aires, Argentina (pop. ~13,300,000): http://osm.org/go/Mnx6Foy-
La Paz, Bolivia (pop. ~2,300,000): http://osm.org/go/NOrAkUe
Santiago, Chile (pop. ~6,000,000): http://osm.org/go/MaK0TCh--
Lima, Peru (pop. ~8,000,000): http://osm.org/go/NNZb1om--
--
Cordoba, Argentina (pop. ~1,300,000): http://osm.org/go/Mw0zkmc--
San Cruz de la Sierra, Bolivia (pop. ~1,800,000): http://osm.org/go/Nh5HGa1
Gran Valparaíso, Chile (pop. ~900,000): http://osm.org/go/MaMIW4o--
Arequipa, Peru (pop. ~750,000): http://osm.org/go/NOJMR7ao-
-
San Luis, Argentina (pop. ~153,000): http://osm.org/go/MwDmIDt
Sucre, Bolivia (pop. ~225,000): http://osm.org/go/NhLWxEgE-
Chillan, Chile (pop. ~170,000): http://osm.org/go/MOXe09B
Huancayo, Peru (pop. ~323,000): http://osm.org/go/NNzRJz5A-

It is difficult to compare cities in terms of size, since the population
numbers for the four countries are so different (40,000,000 people;
11,000,000 people; 17,000,000 people; and 30,000,000 people respectively),
and the same applies to their cities, but I have tried to put cities of
similar importance in each section. One thing is clear, until now, bigger
populations (at city or country level) do not necessarily mean better
mapping and/or coverage, at least in the southern half of South America.

In my opinion quality and coverage totally depend in a combination of
variables, including compromise of the current and future mappers, economic
elements (money/free_time/etc.), geographic elements (shape of the country,
distribution of highways, topography, etc.), climatic elements (snow, ice,
tropical or seasonal rains, the driest desert in the world, etc.),
_and_ public datasets availability.

Until now I have not taken into consideration for this comparison the
suburban highways (by far our biggest import process). But just take a look
into this area of southern Chile: http://osm.org/go/MOB8D1 and compare it
with any suburban area of the surrounding countries. This is, at least in
part, thanks to the massive import process that we did years ago, it was the
kick start for many towns and cities (at the beginning, in many places, we
only had the suburban highways around them and a blank space to fill and
connect), and not only for those towns and cities, but for the improvement
and completion of the same suburban highways (they didn't include any kind
of "elaborate" highway interchange with the mayor motorways, and we have
been investing time adding and perfecting those during these years).

Cheers,

Julio Costa Zambelli
OpenStreetMap Chile

julio.co...@openstreetmap.cl

http://www.openstreetmap.cl/
Cel: +56(9)89981083
Postal: Casilla 9002, Correo 3, Viña del Mar, Chile
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Zero tolerance on imports

[Steve Bennett]

On Mon, Feb 21, 2011 at 11:17 AM, Daniel Sabo  wrote:
> Well, if you can furnish me with an army of bed ridden mappers to trace all 
> the highways in
>the United States I'd concede the point. But I don't think there are nearly 
>enough people of
>your mindset to get the job done, and not having an OSM that's usable as a 
>street map
>detracts from my enjoyment of mapping as much as having an imported road 
>network
>detracts from yours.

I think it's clear that there are different types of people who enjoy
contributing for different reasons, and are "inspired" or otherwise by
different levels of completeness. I had a friend who enthusiastically
spent evenings riding around the city with a GPS, taking photos, in
order to map them. At that stage, the map was too incomplete to even
interest me.

Later, when aerial imagery became available and the map was reaching a
decent level of usefulness, I became more interested in doing tracing,
and a little surveying.

I would hypothesise that there many more people interested in (and
capablo of) filling in details in a fairly complete map, than in GPS
surveying for a blank map.  But that's just a hypothesis.

Steve

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Zero tolerance on imports

[Katie Filbert]

On Sun, Feb 20, 2011 at 8:48 PM, Hillsman, Edward wrote:

> On Sun, 20 Feb 2011 15:47:29, Daniel Sabo wrote:
>
> And if someone has figured out a safe and efficient way to map by car or
> bike without stopping all the time, I'd be interested in hearing about it.
> Helmet cams on bike helmets can be useful for recording features of the
> road, but it's not safe to be moving and at the same time staring at
> something beside the road.
>

If you had someone else to drive, then you could jot notes (could be written
and/or audio), etc.

I'm usually on my own mapping, though, and might once in a while just pull
off into some parking lots and observe what I can see from there.  Over
time, do this enough (w/ other people doing it too), suburbia begins to fill
in. (+ tracing from imagery) It's really not that exciting though, compared
to mapping parks or the city.

Cheers,
Katie



>
> Ed Hillsman
>
> ___
> talk mailing list
> talk@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Zero tolerance on imports

[Hillsman, Edward]

On Sun, 20 Feb 2011 15:47:29, Daniel Sabo wrote:

>As a former novice I completely disagree with you here. If the TIGER import 
>hadn't happened I would have had zero interest in OSM, a vast empty map >is 
>not very inspiring.
>
>But really, no one here has hard data, whenever we say "it destroys the 
>community" or "it helps the community"  we're just throwing anecdotes at >each 
>other. What we need are better tools to build a community like Serge and Kevin 
>are talking about, a dozen of us arguing on a mailing list about >what 360k 
>people "really want" isn't going to accomplish much.
>
>- Daniel

I agree (and also with Nathan Edgars II that tracing endless subdivisions from 
aerials is a chore). I've been mapping for two years now, using a mix of 
tracing and field mapping. I generally do the first in an area, and then go out 
to field check it and to add details that cannot be mapped from imagery (retail 
shops, addresses, curb cuts for wheelchairs, bike parking, &c. The fine detail 
that makes a place a place).

I'd like to suggest one other possible explanation for why mapping in the lag 
in U.S. lags (and also why I consider the TIGER import, with all its flaws, 
invaluable). This is, simply, that except for tracing a path using a GPS 
device, it is unsafe and impractical to map in the field by car or even by 
bicycle without making a lot of stops to make notes/photos/video--in short, to 
observe. So I will drive or bike to an area, then get out and do a lot of 
walking, then line up my photo information with the aerial images and TIGER. 
Unfortunately, an awful lot of our built environment, especially here in 
Florida, is not very supportive of walking. A lot is downright dangerous 
because of design and aggressive driving (while mapping I've come close to 
getting hit twice while crossing with a walk signal at marked crosswalks and 
paying attention, by drivers who did not yield to a pedestrian in the 
crosswalk).

My impression is that in most US cities, the places where a lot of POIs have 
been mapped from field work are in the older, gridded, more pedestrian-friendly 
parts of the area. This could be because there are more interesting things 
there, or that people who live there tend to be more likely to have 
personalities that lead them to get involved in OSM, but it also could be that 
it is just easier and safer to map there. I recall seeing a piece of research 
noting that areas with high crime rates tend not to get mapped in OSM, so these 
would be exceptions to the older-area trend, but support for the hypothesis 
that walkability matters a lot (high crime means not safe means no mapping on 
foot). I'd be interested in observations on this by others. If we think it is 
part of the problem, then we need to factor that into whatever we do to build a 
community here.

And if someone has figured out a safe and efficient way to map by car or bike 
without stopping all the time, I'd be interested in hearing about it. Helmet 
cams on bike helmets can be useful for recording features of the road, but it's 
not safe to be moving and at the same time staring at something beside the road.

Ed Hillsman

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Zero tolerance on imports

[Nathan Edgars II]

Richard Weait wrote:
> 
> Mike N, you must have missed the first x-years of the project.
> Neither aerial imagery, nor imports were available.  ;-)  Of course,
> renderers were missing too.  Not only subdivisions, but cities, lakes
> and oceans were missing.
> 
I took a look at the project some years ago when that was true. Since I
didn't have a GPS device that could record tracks and transfer them to the
computer, I didn't return until the end of 2009 (by which time we had the
TIGER import and Yahoo aerials).
-- 
View this message in context: 
http://gis.638310.n2.nabble.com/Zero-tolerance-on-imports-tp6044534p6047164.html
Sent from the General Discussion mailing list archive at Nabble.com.

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Zero tolerance on imports

[Nathan Edgars II]

On 2/20/2011 6:58 PM, David Murn wrote:

On Sun, 2011-02-20 at 15:35 -0800, Nathan Edgars II wrote:


I find tracing endless residential subdivisions from aerials to be a chore
and no fun.


I know many who disagree, fortunately.  Last year I was laid up in bed
for around 3 months after surgery, just after hi-res aerial imagery
became available for my area.  I spent many many hours tracing unmapped
areas, or even tracing paths and other data of value.


Paths are fine. Mixed-use is fine. What I dislike, and am thankful to 
the TIGER import for including, is suburbs full of miles upon miles of 
curving residential streets.


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Zero tolerance on imports

[Richard Weait]

On Sun, Feb 20, 2011 at 7:27 PM, Mike N  wrote:
> On 2/20/2011 6:47 PM, Daniel Sabo wrote:
>>
>> If the TIGER import hadn't happened I would have had zero interest in OSM,
>> a vast empty map is not very inspiring.
>
> Not only that, but I've never seen someone pop up to add their own
> subdivision streets in the empty area.

Mike N, you must have missed the first x-years of the project.
Neither aerial imagery, nor imports were available.  ;-)  Of course,
renderers were missing too.  Not only subdivisions, but cities, lakes
and oceans were missing.

Daniel says above that the vast empty map would be uninspiring to him,
but clearly it inspired some of our pioneers.

This isn't to say that new contributors aren't welcome.  You sure are.
 This also isn't to say that "things should stay the way they were in
the old days."  I think we all love Minutely Mapnik and many of the
other innovations of recent years.

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Zero tolerance on imports

[Daniel Sabo]

On Feb 20, 2011, at 4:03 PM, Felix Hartmann wrote:

> 
> 
> On 21.02.2011 00:47, Daniel Sabo wrote:
>> On Feb 20, 2011, at 3:16 PM, Felix Hartmann wrote:
>> 
>>> Couldn't agree more to it. Imports kill community and scare novices away.
>>> ...
>>> Most important things for OSM are good aerial photos coupled with large 
>>> community. Worst are imports. The United States are so bad, I don't think 
>>> OSM will ever become important there. The biggest thing to remember is that 
>>> "creating" something is much more fun than correcting it. Imports make OSM 
>>> a chore and no fun.
>> As a former novice I completely disagree with you here. If the TIGER import 
>> hadn't happened I would have had zero interest in OSM, a vast empty map is 
>> not very inspiring.
>> 
>> But really, no one here has hard data, whenever we say "it destroys the 
>> community" or "it helps the community"  we're just throwing anecdotes at 
>> each other. What we need are better tools to build a community like Serge 
>> and Kevin are talking about, a dozen of us arguing on a mailing list about 
>> what 360k people "really want" isn't going to accomplish much.
>> 
>> - Daniel
>> 
> Well we have no hard data, but evidence. Basically no users and editors in 
> the US but loads in Europe. And loads of countries without imports 
> flourishing as communities start to grow (like Slovakia, Czech Republic, 
> Italy, Switzerland, Germany, Denmark) but less involvement in countries with 
> imports. A vast empty map is no fun, but neither is a complete map. The worst 
> is a seemingly complete map, with crap data (like plan.at data in Austria, 
> that was in general off by around 20-100m).
> 
> Just show me some neighboring countries where the one with imports some time 
> ago (minimum 1 year) are doing better than neighboring countries/regions 
> where no imports took place.
> 
> I think imports are good for stuff we cannot easily record ourselves (like 
> borders) - but no good for stuff we can get ourselves.
> And if you see tracing from aerial imagery as a chore, you're making a 
> mistake. I think we should wait till local people do it. That way it gets 
> better quality and is not much work for anyone. We should not strive to be 
> complete, but offer more or different data than commercial map providers, 
> because that's where we are good at. Striving to get a map with best use for 
> carnavigation will not happen - our structure and means are really inferior 
> here. Getting speciality maps noone can compete with large communities.

I disagree with your logic. The reason OSM took off in Europe and not the US 
isn't because TIGER got imported, but simply that TIGER existed. The UK had no 
free source of maps, so people had to make their own in OSM. If OSM hadn't 
imported TIGER everyone who needed a US road map would still be using the raw 
TIGER data instead because as weak as it often is it would be infinitely more 
complete than OSM.

OSM is great for specialty maps, but that doesn't need to conflict with 
building a great alternative to commercial map sources too.

With regards to the "seemingly complete map", if the data is that bad, we 
should probably discuss just deleting it. But I suspect the majority of data it 
isn't actually that bad, and we're better off just letting people delete it as 
they have time to replace it (at least that's my experience with funky imports 
in the US).

- Daniel
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Zero tolerance on imports

[Mike N]

On 2/20/2011 6:47 PM, Daniel Sabo wrote:

If the TIGER import hadn't happened I would have had zero interest in OSM, a 
vast empty map is not very inspiring.


Not only that, but I've never seen someone pop up to add their own 
subdivision streets in the empty area.



___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Zero tolerance on imports

[Katie Filbert]

On Sun, Feb 20, 2011 at 7:03 PM, Felix Hartmann wrote:

> Well we have no hard data, but evidence. Basically no users and editors in
> the US but loads in Europe.


We do have users and editors in the US, but not near as many as Germany.  I
see healthy amount of editing in the Washington DC area, and expect we will
do more mapping parties once the weather gets warm.

One issue is that the US is so large, users so spread apart that it's more
difficult for communities to form, outside of places like DC and Denver.  On
Wikipedia, we have the same problem, that the only really active meetup
groups or chapters are in DC, NYC, somewhat in SF, and a few pockets
elsewhere.



> And loads of countries without imports flourishing as communities start to
> grow (like Slovakia, Czech Republic, Italy, Switzerland, Germany, Denmark)
> but less involvement in countries with imports. A vast empty map is no fun,
> but neither is a complete map.


I wouldn't have been happy to be tracing those endless subdivisions,
especially knowing we have TIGER data that could be used.  Unlikely I ever
would have joined OSM without TIGER as a starting point.

It's certainly best that imports are done with a huge amount of care, in
small batches and with tools like JOSM where the data can be checked and
manually merged with existing data.  It's also important to discuss the
import with the local (or national) community, make sure there is consensus,
etc.

Cheers,
Katie


> The worst is a seemingly complete map, with crap data (like plan.at data
> in Austria, that was in general off by around 20-100m).
>
> Just show me some neighboring countries where the one with imports some
> time ago (minimum 1 year) are doing better than neighboring
> countries/regions where no imports took place.
>
> I think imports are good for stuff we cannot easily record ourselves (like
> borders) - but no good for stuff we can get ourselves.
> And if you see tracing from aerial imagery as a chore, you're making a
> mistake. I think we should wait till local people do it. That way it gets
> better quality and is not much work for anyone. We should not strive to be
> complete, but offer more or different data than commercial map providers,
> because that's where we are good at. Striving to get a map with best use for
> carnavigation will not happen - our structure and means are really inferior
> here. Getting speciality maps noone can compete with large communities.
>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Zero tolerance on imports

[Daniel Sabo]

On Feb 20, 2011, at 3:58 PM, David Murn wrote:

> On Sun, 2011-02-20 at 15:35 -0800, Nathan Edgars II wrote:
>> 
>> I find tracing endless residential subdivisions from aerials to be a chore
>> and no fun.
> 
> I know many who disagree, fortunately.  Last year I was laid up in bed
> for around 3 months after surgery, just after hi-res aerial imagery
> became available for my area.  I spent many many hours tracing unmapped
> areas, or even tracing paths and other data of value.
> 
> Some people like to get out on-the-ground and map, but from my own
> experience, if you want to contribute to the project you'll do it
> however you can, whether that is tracing, walking tracks or driving
> around streets.

Well, if you can furnish me with an army of bed ridden mappers to trace all the 
highways in the United States I'd concede the point. But I don't think there 
are nearly enough people of your mindset to get the job done, and not having an 
OSM that's usable as a street map detracts from my enjoyment of mapping as much 
as having an imported road network detracts from yours.

-Daniel
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Zero tolerance on imports

[Felix Hartmann]

On 21.02.2011 00:47, Daniel Sabo wrote:

On Feb 20, 2011, at 3:16 PM, Felix Hartmann wrote:


Couldn't agree more to it. Imports kill community and scare novices away.
...
Most important things for OSM are good aerial photos coupled with large community. Worst 
are imports. The United States are so bad, I don't think OSM will ever become important 
there. The biggest thing to remember is that "creating" something is much more 
fun than correcting it. Imports make OSM a chore and no fun.

As a former novice I completely disagree with you here. If the TIGER import 
hadn't happened I would have had zero interest in OSM, a vast empty map is not 
very inspiring.

But really, no one here has hard data, whenever we say "it destroys the community" or "it 
helps the community"  we're just throwing anecdotes at each other. What we need are better tools to 
build a community like Serge and Kevin are talking about, a dozen of us arguing on a mailing list about what 
360k people "really want" isn't going to accomplish much.

- Daniel

Well we have no hard data, but evidence. Basically no users and editors 
in the US but loads in Europe. And loads of countries without imports 
flourishing as communities start to grow (like Slovakia, Czech Republic, 
Italy, Switzerland, Germany, Denmark) but less involvement in countries 
with imports. A vast empty map is no fun, but neither is a complete map. 
The worst is a seemingly complete map, with crap data (like plan.at data 
in Austria, that was in general off by around 20-100m).


Just show me some neighboring countries where the one with imports some 
time ago (minimum 1 year) are doing better than neighboring 
countries/regions where no imports took place.


I think imports are good for stuff we cannot easily record ourselves 
(like borders) - but no good for stuff we can get ourselves.
And if you see tracing from aerial imagery as a chore, you're making a 
mistake. I think we should wait till local people do it. That way it 
gets better quality and is not much work for anyone. We should not 
strive to be complete, but offer more or different data than commercial 
map providers, because that's where we are good at. Striving to get a 
map with best use for carnavigation will not happen - our structure and 
means are really inferior here. Getting speciality maps noone can 
compete with large communities.


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Zero tolerance on imports

[David Murn]

On Sun, 2011-02-20 at 15:35 -0800, Nathan Edgars II wrote:
>  
> I find tracing endless residential subdivisions from aerials to be a chore
> and no fun.

I know many who disagree, fortunately.  Last year I was laid up in bed
for around 3 months after surgery, just after hi-res aerial imagery
became available for my area.  I spent many many hours tracing unmapped
areas, or even tracing paths and other data of value.

Some people like to get out on-the-ground and map, but from my own
experience, if you want to contribute to the project you'll do it
however you can, whether that is tracing, walking tracks or driving
around streets.

David


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Zero tolerance on imports

[Daniel Sabo]

On Feb 20, 2011, at 3:16 PM, Felix Hartmann wrote:

> Couldn't agree more to it. Imports kill community and scare novices away.
> ...
> Most important things for OSM are good aerial photos coupled with large 
> community. Worst are imports. The United States are so bad, I don't think OSM 
> will ever become important there. The biggest thing to remember is that 
> "creating" something is much more fun than correcting it. Imports make OSM a 
> chore and no fun.

As a former novice I completely disagree with you here. If the TIGER import 
hadn't happened I would have had zero interest in OSM, a vast empty map is not 
very inspiring.

But really, no one here has hard data, whenever we say "it destroys the 
community" or "it helps the community"  we're just throwing anecdotes at each 
other. What we need are better tools to build a community like Serge and Kevin 
are talking about, a dozen of us arguing on a mailing list about what 360k 
people "really want" isn't going to accomplish much.

- Daniel
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Zero tolerance on imports

[Nathan Edgars II]

Felix Hartmann-2 wrote:
> 
> Most important things for OSM are good aerial photos coupled with large 
> community. Worst are imports. The United States are so bad, I don't 
> think OSM will ever become important there. The biggest thing to 
> remember is that "creating" something is much more fun than correcting 
> it. Imports make OSM a chore and no fun.
> 
I find tracing endless residential subdivisions from aerials to be a chore
and no fun.
-- 
View this message in context: 
http://gis.638310.n2.nabble.com/Zero-tolerance-on-imports-tp6044534p6046937.html
Sent from the General Discussion mailing list archive at Nabble.com.

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Zero tolerance on imports

[Felix Hartmann]

Couldn't agree more to it. Imports kill community and scare novices away.

Austria two years ago was actually one of the best mapped countries for 
the density of population. Much better in general than Germany or other 
countries. Since we began importing plan.at community stopped to grow 
and many many got pissed of. Also value of imports is not good. 
Switzerland 2 years ago nowhere as well covered as Austria, on the other 
hand had no imports, but largely good aerial imagery. By now Northern 
Switzerland map data quality and attributes are absolutely stunning. In 
Austria as soon as you move 20km away from Vienna, average quality is no 
good


I also think that in the Netherlands the imports destroyed what OSM can 
do. In the Netherlands street and landuse data are really complete, but 
quality is just as bad as normal maps. There are far fewer attributes 
than in Germany and if you take pedestrian or bicycle navigation as a 
goal, even though data is really complete, what you can get out of the 
data is crap compared to the bordering parts of west Germany 
(North-Westphalia).


Most important things for OSM are good aerial photos coupled with large 
community. Worst are imports. The United States are so bad, I don't 
think OSM will ever become important there. The biggest thing to 
remember is that "creating" something is much more fun than correcting 
it. Imports make OSM a chore and no fun.

On 20.02.2011 13:00, Jaak Laineste wrote:

  Without knowing local situation I cannot comment this particular
case, but I can tell about mass-imports what I have done myself, spent
each time many man-days for conversions, improving scripts,
discussions with community etc

  1. second largest city of our country full data (streets,buildings
etc) import. The city had a few streets before, and person who had
added most of them, agreed to replace them. It created positive buzz
about "good quality OSM database", but killed local community.
  2. Corine Land Cover, nation-wide import. Today I would do it much
more carefully, or not at all. It has made more mess and troubles, the
only advantage is that medium-zoom rendering looks nicer with a lot of
green forests; but high-zoom is terrible and it is very hard to fix it
now.
  3. National administrative borders (from state source), all levels.
This was the only good import so far you could not get the data with
field survey.
  4. I have also prepared quite good water info - decided NOT import
it, keep for manual copy
  5. In the pipeline is national address database (should have all
addresses/buildings as points).  I have permission from source,
accept/comments from the community, reject from local post agency
regarding including post codes (surprise-surprise).

  So out of 5 imports maybe 1 or 2 were really "good" ones, if you look
it this way. So imports are very-very dangerous and should be done
only if there really is no other alternative. My own optimism of
re-using existing souces (as anyone with strong background in
GIS/geodata would have) to improve OSM has reduced dramatically.

  But I like the idea that there should be separate shared import-data
layer in OSM database (API and editing tools) itself, similar to GPS
files. Right now I have several new datasets just as bunch of OSM
files somewhere in our HTTP, and URLs are posted to local talk-list,
but this is not a good solution, I actually dont recall myself where
they were.

Jaak from Estonia

2011/2/20 Frank Steggink:

On 11-02-20 11:54 AM, SomeoneElse wrote:





___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Zero tolerance on imports

[Milo van der Linden]

In my opinion Julio shows an important thing: if imports are guided by
a strong active group of people with local knowledge, they can be
extremely usefull. This is the key of succes. Unguided, unsupported
one man imports should therefor be avoided.

Op zondag 20 februari 2011 schreef Julio Costa Zambelli
(julio.co...@openstreetmap.cl) het volgende:
> Dear Richard and everyone else,
> We have a totally different experience here. We have done some import 
> processes here in Chile, probably not more than four or five till now, I 
> talked about the suburban highways import process in my "State of Chile" 
> presentation in Amsterdam, and after that we added: all the schools and Town 
> Halls in Santiago; all the Hospitals and municipal/provincial borders in the 
> Maule Region after the earthquake. This mostly from datasets liberated by 
> different government agencies, and they have been a total successes (In a 
> couple of days I will pick-up an external hard drive with more than 150GB of 
> data liberated by SECTRA, the Government Secretary of Transportation, 
> including aerial imagery for many of Chiles biggest cities).
>
>
> Actually right now we are discussing, in the talk-cl mailing list, the import 
> process of all the bus stops of Transantiago (the transportation system of 
> Santiago). There are more than 10,000 bus stops in this dataset (we have 
> manually/randomly tested some of them and the accuracy of the geolocation is 
> pretty much the same that we get from our "on the ground survey", the nodes 
> also have the two codes used to identify each stop something we do not have 
> right now, probably because one of those codes is a 10~12 characters 
> alphanumeric string). The contributor that did the request of authorisation 
> for the dataset with the transportation authority also researched how many 
> bus stops we have added all over the country, and he told me that there are 
> no more than 700.
>
>
> So this is not a very difficult decision (700 all over the country versus 
> more than 10,000 just for Santiago), we have talked 
> (http://lists.openstreetmap.org/pipermail/talk-cl/2011-February/000927.html) 
> about preserving the already surveyed stops, but since the data per bus stop 
> in the dataset is so complete it doesn't make too much sense to keep 
> duplicated nodes (in my particular case I probably have added "not included" 
> data tags like "shelter" or "towards" just to ~10% of my surveyed stops).
>
>
> What I am trying to say is that not all the import processes are bad, and the 
> ones well planned, well executed, and broadly discussed in mailing list and 
> other channels of communication are really good tools for expanding our 
> coverage _and_ improving the quality of our data.
>
>
> Cheers,
> Julio Costa ZambelliOpenStreetMap Chile
> julio.co...@openstreetmap.cl
>
>
> http://www.openstreetmap.cl/Cel: +56(9)89981083Postal: Casilla 9002, Correo 
> 3, Viña del Mar, Chile
>
>
> On 19 February 2011 21:03, Richard Fairhurst  wrote:
>
>
> This is getting crazy.
>
> Exhibit 1:
> http://twitter.com/#!/maproomblog/status/39053538692698112
>
> "Whoever imported CanVec in Aylmer, Quebec obliterated hours of work and 
> introduced hundreds of errors. #osm #openstreetmap #whybother"
>
> Once again, some keyboard jockey has decided that his l337 import skills are 
> better than the knowledge and hours of work by a local mapper. The offender 
> appears to be user 'sammuell' by the look of it - 
> http://www.openstreetmap.org/user/sammuell - though he hasn't posted anything 
> about his activities on the user page, the wiki, or indeed anywhere.
>
> This is killing OSM. We are not here to provide a free API to government 
> geodata that can be obtained trivially elsewhere. OSM is all about "added 
> value"; by deleting genuine surveyed data in favour of mindless duplication 
> of other, poorer quality datasets, we are _destroying_ value.
>
> From what I can tell (talk-ca postings etc.) 'sammuell' is a fairly 
> inexperienced OSMer who presumably thinks "this is how things are done". It 
> isn't. How do we stop this impression taking hold? How do we explain that 
> imports are _not_ welcome except as a last resort, and if you do them, you 
> _must_ follow a very, very rigorous set of guidelines?
>
> cheers
> Richard
>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk
>
>

-- 
Milo van der Linden
Open Source Geospatial consultant

do go digi - *Geospatial solutions*

Beukenlaan 2
5261LE  Vught
+31616598808

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Zero tolerance on imports

[Milo van der Linden]

In my opinion Julio shows an important thing: if imports are guided by
a strong active group of people with local knowledge, they can be
extremely usefull. This is the key of succes. Unguided, unsupported
one man imports should therefor be avoided.

Op zondag 20 februari 2011 schreef Julio Costa Zambelli
(julio.co...@openstreetmap.cl) het volgende:
> Dear Richard and everyone else,
> We have a totally different experience here. We have done some import 
> processes here in Chile, probably not more than four or five till now, I 
> talked about the suburban highways import process in my "State of Chile" 
> presentation in Amsterdam, and after that we added: all the schools and Town 
> Halls in Santiago; all the Hospitals and municipal/provincial borders in the 
> Maule Region after the earthquake. This mostly from datasets liberated by 
> different government agencies, and they have been a total successes (In a 
> couple of days I will pick-up an external hard drive with more than 150GB of 
> data liberated by SECTRA, the Government Secretary of Transportation, 
> including aerial imagery for many of Chiles biggest cities).
>
>
> Actually right now we are discussing, in the talk-cl mailing list, the import 
> process of all the bus stops of Transantiago (the transportation system of 
> Santiago). There are more than 10,000 bus stops in this dataset (we have 
> manually/randomly tested some of them and the accuracy of the geolocation is 
> pretty much the same that we get from our "on the ground survey", the nodes 
> also have the two codes used to identify each stop something we do not have 
> right now, probably because one of those codes is a 10~12 characters 
> alphanumeric string). The contributor that did the request of authorisation 
> for the dataset with the transportation authority also researched how many 
> bus stops we have added all over the country, and he told me that there are 
> no more than 700.
>
>
> So this is not a very difficult decision (700 all over the country versus 
> more than 10,000 just for Santiago), we have talked 
> (http://lists.openstreetmap.org/pipermail/talk-cl/2011-February/000927.html) 
> about preserving the already surveyed stops, but since the data per bus stop 
> in the dataset is so complete it doesn't make too much sense to keep 
> duplicated nodes (in my particular case I probably have added "not included" 
> data tags like "shelter" or "towards" just to ~10% of my surveyed stops).
>
>
> What I am trying to say is that not all the import processes are bad, and the 
> ones well planned, well executed, and broadly discussed in mailing list and 
> other channels of communication are really good tools for expanding our 
> coverage _and_ improving the quality of our data.
>
>
> Cheers,
> Julio Costa ZambelliOpenStreetMap Chile
> julio.co...@openstreetmap.cl
>
>
> http://www.openstreetmap.cl/Cel: +56(9)89981083Postal: Casilla 9002, Correo 
> 3, Viña del Mar, Chile
>
>
> On 19 February 2011 21:03, Richard Fairhurst  wrote:
>
>
> This is getting crazy.
>
> Exhibit 1:
> http://twitter.com/#!/maproomblog/status/39053538692698112
>
> "Whoever imported CanVec in Aylmer, Quebec obliterated hours of work and 
> introduced hundreds of errors. #osm #openstreetmap #whybother"
>
> Once again, some keyboard jockey has decided that his l337 import skills are 
> better than the knowledge and hours of work by a local mapper. The offender 
> appears to be user 'sammuell' by the look of it - 
> http://www.openstreetmap.org/user/sammuell - though he hasn't posted anything 
> about his activities on the user page, the wiki, or indeed anywhere.
>
> This is killing OSM. We are not here to provide a free API to government 
> geodata that can be obtained trivially elsewhere. OSM is all about "added 
> value"; by deleting genuine surveyed data in favour of mindless duplication 
> of other, poorer quality datasets, we are _destroying_ value.
>
> From what I can tell (talk-ca postings etc.) 'sammuell' is a fairly 
> inexperienced OSMer who presumably thinks "this is how things are done". It 
> isn't. How do we stop this impression taking hold? How do we explain that 
> imports are _not_ welcome except as a last resort, and if you do them, you 
> _must_ follow a very, very rigorous set of guidelines?
>
> cheers
> Richard
>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk
>
>

-- 
Milo van der Linden
Open Source Geospatial consultant

do go digi - *Geospatial solutions*

Beukenlaan 2
5261LE  Vught
+31616598808

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Zero tolerance on imports

[Lennard]

On 20-2-2011 19:56, M∡rtin Koppenhoefer wrote:


Even if you import now up to date and "complete" data, if there is not
an active comunity to support and maintain this data its value will
shrink every day and it will be outdated soon.


As mentioned before in this thread, the same holds true of user 
collected and contributed information in OSM, to various degrees. Users 
loose interest, or worse (some have even died), and thus areas fall out 
of maintenance all the time. Waiting for someone else to come along and 
pick it up. -If- someone comes along.



--
Lennard


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Zero tolerance on imports

[M∡rtin Koppenhoefer]

2011/2/20 Frank Steggink :
>> This is killing OSM. We are not here to provide a free API to government
>> geodata that can be obtained trivially elsewhere. OSM is all about "added
>> value"; by deleting genuine surveyed data in favour of mindless duplication
>> of other, poorer quality datasets, we are _destroying_ value.


+1


> ...Because the scale of the
> province and the entire country, it is simply impossible to depend on local
> users for contributing to OSM.


given the actual user base


> Anyways, because there are only a few active users, I decided to join the
> Geobase NRN (roads) efforts at one point, and Canvec at the beginning of
> this month.


It is obvious that a crowd based mapping can not work without an
actual "crowd".


> Regarding the age of
> the data (which can be 30 years old): it is still better than nothing for an
> area which is too vast to survey by individuals like you and me.


better for what? IMHO for attracting other people to the project it is
worse. If I came along a project full of imported old stuff with lots
of outdated and wrong features I'd rather turn my back then beeing
attracted to correct the mess. On the other hand if you had some good
quality but scarse and incomplete data people will understand the
method and scope of the project and some might join you in your
mapping efforts, so in the end it might work out.

Even if you import now up to date and "complete" data, if there is not
an active comunity to support and maintain this data its value will
shrink every day and it will be outdated soon.

cheers,
Martin

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Zero tolerance on imports

[Serge Wroclawski]

On Sun, Feb 20, 2011 at 4:44 AM, Daniel Sabo  wrote:

>>> Maybe you don't like it, but you are not the entire OSM community.

>> David, how would you propose to measure consensus from the OSM community?
>
> I assume you were replying to me? At present I think it's pretty much 
> impossible: e.g. the license debate :). We just don't have enough OSMers on 
> one communication channel to make real policy about these things, so I expect 
> were stuck with the Wikipedia model right now where the few people with 
> enough technical knowledge to revert things try to police everyone else.

Yes, my mistake (re: your name).

I've been thinking about this communication issue and am working on a
technical solution. If you know Ruby or if others who do want to help,
I've forked a copy of the ruby port and have been working on
something- it's just not on the top of my list at this moment, but it
could be with others.

Or a sprint during SOTM EU?


> Really it should be the importer making those fixes if at all possible, so 
> personally I would be much faster to revert things.

That's fair. I think as a community we're hesistant to revert changes
since things like that can end up in an edit war. I think a better
communication system could help here.


> If we could email back someone their changesets as an OSM file and say "it 
> was nice of you to try importing this but could you not erase that lake over 
> on the left?" I think we could even do it without chasing too many would be 
> importers away.

That's another thing I think we need, along with communication- a tool
do incrementally edit a changeset based on a previous changeset, and
or at least track those lineages. Eg I make a changeset, and you "fix"
it, and there's a tag that says something like "based_on" with a
changeset ID.

> A major limitation is also that there's really no way to collaborate on 
> something like this without dumping it into the main map.

I wrote an email about this to talk-us about a year ago. Want me to dig it up?

- Serge

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Zero tolerance on imports

[Juan Lucas Domínguez Rubio]

--- On Sun, 2/20/11, Steve Bennett  wrote:

> From: Steve Bennett 
> Subject: Re: [OSM-talk] Zero tolerance on imports
> To: "Richard Fairhurst" 
> Cc: talk@openstreetmap.org
> Date: Sunday, February 20, 2011, 2:08 PM
> On Sun, Feb 20, 2011 at 11:03 AM,
> Richard Fairhurst
> 
> wrote:
> > This is killing OSM. We are not here to provide a free
> API to government
> 
> Sounds like OSM has reached the point Wikipedia many years
> ago, where
> the limits of open slather editing become apparent.
> 
> Suggestions:
> 1) Lock down the upload capability, requiring approval for
> big uploads
> 2) Make rollbacks easier
> 3) Improve detection of big changes
> 
> And, sure, continue to attempt to educate the community.
> But with a
> wide open API, that's only going to be so effective.
> 
> Steve
> 
> ___
> talk mailing list
> talk@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk
>

hello,zero tolerance on X implies X is bad,
which sounds ridiculous after all the huge imports already done.
This thread totally backfired...

also, how do you distinguish an 'import' from a long JOSM tracing session? I 
think the concept 'import' is artificial and useless. We don't have imports, we 
have big and small contributions. All data -surveyed by the person who uploads 
them or not- have errors and need maintenance. The important things are: 
respect the license terms, do not destroy data, do not upload irrelevant data, 
use tags reasonably.

Regards,
Juan Lucas


  

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Zero tolerance on imports

[Steve Bennett]

On Sun, Feb 20, 2011 at 11:03 AM, Richard Fairhurst
 wrote:
> This is killing OSM. We are not here to provide a free API to government

Sounds like OSM has reached the point Wikipedia many years ago, where
the limits of open slather editing become apparent.

Suggestions:
1) Lock down the upload capability, requiring approval for big uploads
2) Make rollbacks easier
3) Improve detection of big changes

And, sure, continue to attempt to educate the community. But with a
wide open API, that's only going to be so effective.

Steve

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Zero tolerance on imports

[Jaak Laineste]

 Without knowing local situation I cannot comment this particular
case, but I can tell about mass-imports what I have done myself, spent
each time many man-days for conversions, improving scripts,
discussions with community etc

 1. second largest city of our country full data (streets,buildings
etc) import. The city had a few streets before, and person who had
added most of them, agreed to replace them. It created positive buzz
about "good quality OSM database", but killed local community.
 2. Corine Land Cover, nation-wide import. Today I would do it much
more carefully, or not at all. It has made more mess and troubles, the
only advantage is that medium-zoom rendering looks nicer with a lot of
green forests; but high-zoom is terrible and it is very hard to fix it
now.
 3. National administrative borders (from state source), all levels.
This was the only good import so far you could not get the data with
field survey.
 4. I have also prepared quite good water info - decided NOT import
it, keep for manual copy
 5. In the pipeline is national address database (should have all
addresses/buildings as points).  I have permission from source,
accept/comments from the community, reject from local post agency
regarding including post codes (surprise-surprise).

 So out of 5 imports maybe 1 or 2 were really "good" ones, if you look
it this way. So imports are very-very dangerous and should be done
only if there really is no other alternative. My own optimism of
re-using existing souces (as anyone with strong background in
GIS/geodata would have) to improve OSM has reduced dramatically.

 But I like the idea that there should be separate shared import-data
layer in OSM database (API and editing tools) itself, similar to GPS
files. Right now I have several new datasets just as bunch of OSM
files somewhere in our HTTP, and URLs are posted to local talk-list,
but this is not a good solution, I actually dont recall myself where
they were.

Jaak from Estonia

2011/2/20 Frank Steggink :
> On 11-02-20 11:54 AM, SomeoneElse wrote:
>>
>> Frank Steggink wrote:
>>>
>>> I believe the average community opinion is more like: imports _are_
>>> welcome, but _only_ if there are no better alternatives, and _only_ if a
>>> strict set of guidelines is followed (for example _not_ deleting better
>>> quality user contributed data).
>>
>> I think that historical messages here show that there IS a majority
>> anti-import stance in the community, but that's mainly because your two
>> important provisos aren't often followed.
>>
>> However, surely we're missing the important point here - that someone had
>> "hours of work obliterated" by another person?  There's a lesson that we can
>> all take from this - to better respect other mappers' work and to try and
>> understand what they're trying to do and how they're trying to do it.  That
>> might be by respecting "no import" or "no tracing" zones or it might be by
>> working together in other ways - but we have to try and work with and not
>> against each other on this.
>>
>> Cheers,
>> Andy
>>
>>
>> ___
>> talk mailing list
>> talk@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk
>>
> Andy,
>
> Not everyone in the community is following OSM-talk, let alone commenting on
> discussions. There is surely a vocal minority against imports, like there is
> also a vocal minority against the upcoming license change. Yet, support for
> ODbL and the CT by pre-May 2010 users is growing, and yet imports are not
> rolled back large scale.
>
> People tend to make themselves heard when they do not agree with something,
> not whenthey are content. So, the messages here have a certain bias.
>
> I do agree that we should all respect the efforts of others. OSM is a
> collaborative effort. My response is mostly an attempt to counter the
> anti-import discussion. I find that what has happened in Aylmer is equally
> bad as the next person.
>
> Frank
>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk
>



-- 
Jaak Laineste

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Zero tolerance on imports

[Ulf Lamping]

Am 20.02.2011 12:24, schrieb Frank Steggink:

Not everyone in the community is following OSM-talk, let alone
commenting on discussions. There is surely a vocal minority against
imports, like there is also a vocal minority against the upcoming
license change. Yet, support for ODbL and the CT by pre-May 2010 users
is growing, and yet imports are not rolled back large scale.

People tend to make themselves heard when they do not agree with
something, not whenthey are content. So, the messages here have a
certain bias.

I do agree that we should all respect the efforts of others. OSM is a
collaborative effort. My response is mostly an attempt to counter the
anti-import discussion. I find that what has happened in Aylmer is
equally bad as the next person.


+1

Regards, ULFL

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Zero tolerance on imports

[Frank Steggink]

On 11-02-20 11:54 AM, SomeoneElse wrote:

Frank Steggink wrote:
I believe the average community opinion is more like: imports _are_ 
welcome, but _only_ if there are no better alternatives, and _only_ 
if a strict set of guidelines is followed (for example _not_ deleting 
better quality user contributed data).


I think that historical messages here show that there IS a majority 
anti-import stance in the community, but that's mainly because your 
two important provisos aren't often followed.


However, surely we're missing the important point here - that someone 
had "hours of work obliterated" by another person?  There's a lesson 
that we can all take from this - to better respect other mappers' work 
and to try and understand what they're trying to do and how they're 
trying to do it.  That might be by respecting "no import" or "no 
tracing" zones or it might be by working together in other ways - but 
we have to try and work with and not against each other on this.


Cheers,
Andy


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk


Andy,

Not everyone in the community is following OSM-talk, let alone 
commenting on discussions. There is surely a vocal minority against 
imports, like there is also a vocal minority against the upcoming 
license change. Yet, support for ODbL and the CT by pre-May 2010 users 
is growing, and yet imports are not rolled back large scale.


People tend to make themselves heard when they do not agree with 
something, not whenthey are content. So, the messages here have a 
certain bias.


I do agree that we should all respect the efforts of others. OSM is a 
collaborative effort. My response is mostly an attempt to counter the 
anti-import discussion. I find that what has happened in Aylmer is 
equally bad as the next person.


Frank


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Zero tolerance on imports

[SomeoneElse]

Frank Steggink wrote:
I believe the average community opinion is more like: imports _are_ 
welcome, but _only_ if there are no better alternatives, and _only_ if 
a strict set of guidelines is followed (for example _not_ deleting 
better quality user contributed data).


I think that historical messages here show that there IS a majority 
anti-import stance in the community, but that's mainly because your two 
important provisos aren't often followed.


However, surely we're missing the important point here - that someone 
had "hours of work obliterated" by another person?  There's a lesson 
that we can all take from this - to better respect other mappers' work 
and to try and understand what they're trying to do and how they're 
trying to do it.  That might be by respecting "no import" or "no 
tracing" zones or it might be by working together in other ways - but we 
have to try and work with and not against each other on this.


Cheers,
Andy


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Zero tolerance on imports

[Elizabeth Dodd]

On Sun, 20 Feb 2011 11:01:59 +0100
Frank Steggink  wrote:

> > Which I think is basically why the airports import didn't get
> > reverted. There was bad data but also a lot of good data and no
> > better option for separating the two than just leaving it all in
> > the map.  
> This should have been taken care of before the import. Anyways, if it
> is obvious which airports are misplaced, they should be moved or
> deleted.

It's not obvious
It is also about the lack of a hierarchy of 'airports'
in which a dirt strip is imported the same as a large international
airport.

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Zero tolerance on imports

[Frank Steggink]

On 11-02-20 10:44 AM, Daniel Sabo wrote:

Really it should be the importer making those fixes if at all possible, so personally I 
would be much faster to revert things. If we could email back someone their changesets as 
an OSM file and say "it was nice of you to try importing this but could you not 
erase that lake over on the left?" I think we could even do it without chasing too 
many would be importers away.
I agree. Things like this should be dealt with off-list first. It 
doesn't help if the entire OSM community immediately jumps in on this.

A major limitation is also that there's really no way to collaborate on 
something like this without dumping it into the main map. There have been 
previous talks about making some repository were people could put OSM formatted 
data they want imported and then let other people gradually copy it into the 
map but I don't think it's ever gotten off the ground.
FYI, this is basically the Canvec import model. The repository is 
available by FTP here: ftp://ftp2.cits.rncan.gc.ca/osm/pub/ . There is 
also a Google Docs spreadsheet where the status is being recorded, but 
personally I find it pretty cumbersome. It's still better than trying to 
manage it on the OSM wiki, as  was the case first.


Of course a repository, even a centralized one, does not prevent 
incidents like this happening. The best way to prevent this is by 
education, by stressing (would-be) importers about the impact their work 
is having, so they should even take more diligence than as normal users

Which I think is basically why the airports import didn't get reverted. There 
was bad data but also a lot of good data and no better option for separating 
the two than just leaving it all in the map.
This should have been taken care of before the import. Anyways, if it is 
obvious which airports are misplaced, they should be moved or deleted.

- Daniel
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Frank

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Zero tolerance on imports

[Kevin Peat]

This is a very good point. In the past I have thought about contacting the
mappers active in a particular area but it's a pain in the a*se to do
something that should be trivial. The current OSM messaging system could
really do with a bit more "social" thinking not just relying on users adding
their names to wiki pages that most people probably don't even know exist.

Quite a few areas are covered these days by user groups or dedicated mailing
lists. It might be a good idea if those areas were stored and then when
someone starts mapping in the area then JOSM/Potlatch/etc. could pop up a
box saying you should check out the Wiki/Website for the group, where they
could state their views on things like imports.

Kevin








On 20 February 2011 09:06, Daniel Sabo  wrote:

>
> The other issue is that the community is hard to communicate with
>
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Zero tolerance on imports

[Daniel Sabo]

On Feb 20, 2011, at 1:03 AM, Serge Wroclawski wrote:

> On Sat, Feb 19, 2011 at 10:40 PM, Daniel Sabo  wrote:
>> On Feb 19, 2011, at 4:03 PM, Richard Fairhurst wrote:
>>> From what I can tell (talk-ca postings etc.) 'sammuell' is a fairly 
>>> inexperienced OSMer who presumably thinks "this is how things are done". It 
>>> isn't. How do we stop this impression taking hold? How do we explain that 
>>> imports are _not_ welcome except as a last resort, and if you do them, you 
>>> _must_ follow a very, very rigorous set of guidelines?
>> 
>> Maybe you don't like it, but you are not the entire OSM community. Yes, in 
>> this case someone overwritten what I presume was good surveyed data with an 
>> import was stupid. But in general the fact that data was gathered by a 
>> government surveyor with tools an order of magnitude more accurate than ours 
>> does not, IMHO, make it less "worthy" of being in OSM.
> 
> David, how would you propose to measure consensus from the OSM community?

I assume you were replying to me? At present I think it's pretty much 
impossible: e.g. the license debate :). We just don't have enough OSMers on one 
communication channel to make real policy about these things, so I expect were 
stuck with the Wikipedia model right now where the few people with enough 
technical knowledge to revert things try to police everyone else.

>> From my limited experience working with a bunch of conflicting government 
>> shapefiles is a HUGE pain in the ass. Doing quality imports where we correct 
>> conflicts based on actual research (on the ground or otherwise) IS adding 
>> value.
> 
> The process of reconciliation is painful and difficult, and,
> unfortunately, rarely is the importer the one making the corrections,
> especially in large scale imports. It's not reasonable for someone to
> survey all the airstrips in the world, but neither is it reasonable
> for a single person to verify all the streets in a city.
> 
> I say this both as a previous "bad importer" and as someone who fixes
> errors on the map.
> 
> Since you feel strongly about imports, how would you go about
> preserving their value while reducing the kinds of issues brought up
> on the list (conflicts, removal of ground surveyed data, etc.)

Really it should be the importer making those fixes if at all possible, so 
personally I would be much faster to revert things. If we could email back 
someone their changesets as an OSM file and say "it was nice of you to try 
importing this but could you not erase that lake over on the left?" I think we 
could even do it without chasing too many would be importers away.

A major limitation is also that there's really no way to collaborate on 
something like this without dumping it into the main map. There have been 
previous talks about making some repository were people could put OSM formatted 
data they want imported and then let other people gradually copy it into the 
map but I don't think it's ever gotten off the ground.

Which I think is basically why the airports import didn't get reverted. There 
was bad data but also a lot of good data and no better option for separating 
the two than just leaving it all in the map.

- Daniel
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Zero tolerance on imports

[Frank Steggink]

Richard,

On 11-02-20 01:03 AM, Richard Fairhurst wrote:

This is getting crazy.

Exhibit 1:
http://twitter.com/#!/maproomblog/status/39053538692698112

"Whoever imported CanVec in Aylmer, Quebec obliterated hours of work 
and introduced hundreds of errors. #osm #openstreetmap #whybother"
Of course this should never have happened. I absolutely agree with 
Jonathan and you about that.


Once again, some keyboard jockey has decided that his l337 import 
skills are better than the knowledge and hours of work by a local 
mapper. The offender appears to be user 'sammuell' by the look of it - 
http://www.openstreetmap.org/user/sammuell - though he hasn't posted 
anything about his activities on the user page, the wiki, or indeed 
anywhere.
I don't know where you have looked, but apparently you didn't do a very 
good job. The user you're pointing out is importing Canvec and making a 
lot of contributions in Manitoba, which is a long way from Aylmer / 
Ottawa. Some excuses would be appropriate.


This is killing OSM. We are not here to provide a free API to 
government geodata that can be obtained trivially elsewhere. OSM is 
all about "added value"; by deleting genuine surveyed data in favour 
of mindless duplication of other, poorer quality datasets, we are 
_destroying_ value.
How about the reverse case? I've seen that many times. Sometimes it's 
really obvious that data is not "genuinely surveyed", but just pulled 
out of thin air.


I'll confess, I'm an importer. I have imported and am still importing 
data in the Netherlands and Québec. Not in Aylmer though, but mostly 
Central Québec. I've spent countless hours in surveying the city of 
Québec itself and the (major) highways in Central Québec myself. Because 
the scale of the province and the entire country, it is simply 
impossible to depend on local users for contributing to OSM. During my 
time I only had contact with a handful of other locals, of which I only 
one met (she happened to be a colleague). The other users I met came 
mostly from the Sherbrooke area, which is over 2 hours away by car.


Anyways, because there are only a few active users, I decided to join 
the Geobase NRN (roads) efforts at one point, and Canvec at the 
beginning of this month. With Geobase I did my proper duty, by joining 
up the roads to the existing ones. With Canvec I omitted all roads. 
There are names on them which are not on Geobase, but I'll look at that 
later. Regarding the age of the data (which can be 30 years old): it is 
still better than nothing for an area which is too vast to survey by 
individuals like you and me. Also keep in mind that there is only 
Landsat coverage, except for the larger urban areas. So, I think that it 
is appropriate to use as a template on which other users can elaborate.


The import in the Netherlands is landuse only (the infamous 3dShapes 
import, for the statisticians among you). We're trying to engage other 
users too, although this isn't always going smoothly. In the end we 
always came to some kind of agreement, so that's a big win for OSM. (No, 
3dShapes doesn't always draw the long straw.) After an import of a sheet 
we always do a post-import cleanup. That means evaluating 
inconsistencies, conflicts, etc. Since the import is landuse only, I 
restrict the cleanup mostly to this, although I do some minor cleanup of 
obvious errors, like self-intersecting ways, untagged nodes, etc., as 
well. Many of the pre-existing data which gets cleaned up comes from the 
AND import. In other cases I'm using Bing imagery as the judge. 
Sometimes I keep the imported feature, sometimes the user feature, 
sometimes both.


In case anyone is completely up in arms about this: this is why I can 
tell that user contributed data is not always better than imported data. 
(And imported data is also better than no data, unless the imported data 
is plainly wrong and misleading). It is not as black-and-white as you 
paint. So, please lower your pitchforks, and accept that imported data 
CAN BE better than user-contributed data. OSM has over 360k registered 
accounts, and it is impossible to keep everyone happy. Nearly everyone 
is genuinely doing his best, and I'm pretty sure the user who messed up 
in Aylmer did this by accident. He should have been contacted first, 
before the entire anti-import brigade is stumbling over him. Anyways, 
now I will have that coming, by writing this mail :)


Importers are humans too, and all humans do make mistake. However, I do 
realize that the work (and especially the mistakes) of importers are 
much more scrutinized. This is OK, because of the impact of their work 
in certain areas is much larger.


From what I can tell (talk-ca postings etc.) 'sammuell' is a fairly 
inexperienced OSMer who presumably thinks "this is how things are 
done". It isn't. How do we stop this impression taking hold? How do we 
explain that imports are _not_ welcome except as a last resort, and if 
you do them, you _must_ follow a very, v

Re: [OSM-talk] Zero tolerance on imports

[Daniel Sabo]

On Feb 20, 2011, at 12:32 AM, David Murn wrote:

> On Sat, 2011-02-19 at 19:40 -0800, Daniel Sabo wrote:
> 
>> Maybe you don't like it, but you are not the entire OSM community. Yes,
>> in this case someone overwritten what I presume was good surveyed data
>> with an import was stupid. But in general the fact that data was
>> gathered by a government surveyor with tools an order of magnitude
>> more accurate than ours does not, IMHO, make it less "worthy" of being
>> in OSM.
> 
> As was stated in the previous email, OSM isnt designed to simply be an
> API for people to load government data into.  Your comment about the
> 'order of magnitude more accurate than ours', shows that maybe you need
> to read about the airport import, where some airports were added many
> kilometres away from their accurate location, or several cases reported
> here in the last few weeks of deleted surveyed data and tags, replaced
> with generic un-verified tags.
> 
> Yes, some imports are good, especially when the community is consulted
> and comes up with a proper way to import/tag/maintain them, but if one
> individual just decides to use their own data sources, with their own
> tags without consultation with the community, it almost always leads to
> more damage than added value.  Its no good doing an import that 'saves'
> 20 hours of handwork, if it takes 100 hours of handwork to correct it.
> One practical example of this, was when I made a cross-country trip last
> year, and found some fuel stations were mapped upto 100km away from
> their real location.  Imagine if someone was relying on that data, in a
> remote area if could be life-endangering, or worse imagine if it was a
> hospital import. Some things Id rather not have mapped, than to have
> them mapped possibly inaccurately, or to at least have renderers show
> imported data with a warning to be wary of its accuracy.
> 
> David
> 

I don't disagree with anything you said. What I disagree with is that every 
time someone does a bad import there's a very vocal "ban all imports" response 
like the first message in this thread. If it were my choice I would have 
reverted the airports import immediately, but other people are more tolerant :).

When I say "an order of magnitude more accurate than ours" I'm restricting that 
to things things that are more accurate, not random lat,lon coordinates people 
pull of the internet :). I'm pretty sure that most municipal road data is much 
better than anything I can do with my GPS, and if someone can do proper 
conflation on it I'd have no problem with my roads getting aligned with their 
roads.

The problem isn't imports. If you personally know that the data is good, or are 
willing to put the time into verifying it and checking for dupes there is 
nothing wrong with importing data. The problem is that people either don't know 
how to do this due diligence or they're lazy and assume that someone else will 
clean it up. From most of the "oh god why did you import that" discussions I've 
seen here there's a lot more user error than malice.

The other issue is that the community is hard to communicate with. As far as 
I've seen the mailing lists are the only active OSM discussion, and IMHO 
mailing lists are a bit of a barrier to entry. Expecting people to join 3 
mailing lists (talk, imports, talk-country at minimum) to ask if it's OK for 
them to map something is unreasonable.

- Daniel
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Zero tolerance on imports

[Serge Wroclawski]

On Sat, Feb 19, 2011 at 10:40 PM, Daniel Sabo  wrote:
> On Feb 19, 2011, at 4:03 PM, Richard Fairhurst wrote:
>> From what I can tell (talk-ca postings etc.) 'sammuell' is a fairly 
>> inexperienced OSMer who presumably thinks "this is how things are done". It 
>> isn't. How do we stop this impression taking hold? How do we explain that 
>> imports are _not_ welcome except as a last resort, and if you do them, you 
>> _must_ follow a very, very rigorous set of guidelines?
>
> Maybe you don't like it, but you are not the entire OSM community. Yes, in 
> this case someone overwritten what I presume was good surveyed data with an 
> import was stupid. But in general the fact that data was gathered by a 
> government surveyor with tools an order of magnitude more accurate than ours 
> does not, IMHO, make it less "worthy" of being in OSM.

David, how would you propose to measure consensus from the OSM community?


> From my limited experience working with a bunch of conflicting government 
> shapefiles is a HUGE pain in the ass. Doing quality imports where we correct 
> conflicts based on actual research (on the ground or otherwise) IS adding 
> value.

The process of reconciliation is painful and difficult, and,
unfortunately, rarely is the importer the one making the corrections,
especially in large scale imports. It's not reasonable for someone to
survey all the airstrips in the world, but neither is it reasonable
for a single person to verify all the streets in a city.

I say this both as a previous "bad importer" and as someone who fixes
errors on the map.

Since you feel strongly about imports, how would you go about
preserving their value while reducing the kinds of issues brought up
on the list (conflicts, removal of ground surveyed data, etc.)

- Serge

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Zero tolerance on imports

[Serge Wroclawski]

On Sat, Feb 19, 2011 at 7:03 PM, Richard Fairhurst  wrote:

> This is killing OSM. We are not here to provide a free API to government
> geodata that can be obtained trivially elsewhere. OSM is all about "added
> value"; by deleting genuine surveyed data in favour of mindless duplication
> of other, poorer quality datasets, we are _destroying_ value.
>
> From what I can tell (talk-ca postings etc.) 'sammuell' is a fairly
> inexperienced OSMer who presumably thinks "this is how things are done". It
> isn't. How do we stop this impression taking hold? How do we explain that
> imports are _not_ welcome except as a last resort, and if you do them, you
> _must_ follow a very, very rigorous set of guidelines?

I concur with the view that bad imports hurt OSM.

I'd like to make a few pragmatic suggestions to reduce imports.

First, I think the most important thing we as a community can do to
reduce bot/import issues is to identify them.

I personally use OWL to monitor the area around where I live and I
make a cursory check of the changes in my area. I think most serious
mappers should consider doing the same, just to keep up to date with
what's happening in their area.

One could certainly write a script to help identify bots. Tell-tale
signs might include large bounding boxes, large numbers of changesets
in succession, lots of the same types of changes, etc.

Next, I'd suggest we reduce the number of changes per changeset. While
doing this might make bot detection harder, the upside might be easier
changeset reversion.

Then we should require bots to be registered- a "bot account" would
have reduced restrictions on it, but would be more heavily
scrutinised, if by no one else, then by the community at large.

None of these, with the exception of the bot detection, would require
any new software.

- Serge

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Zero tolerance on imports

[David Murn]

On Sat, 2011-02-19 at 19:40 -0800, Daniel Sabo wrote:

> Maybe you don't like it, but you are not the entire OSM community. Yes,
> in this case someone overwritten what I presume was good surveyed data
> with an import was stupid. But in general the fact that data was
> gathered by a government surveyor with tools an order of magnitude
> more accurate than ours does not, IMHO, make it less "worthy" of being
> in OSM.

As was stated in the previous email, OSM isnt designed to simply be an
API for people to load government data into.  Your comment about the
'order of magnitude more accurate than ours', shows that maybe you need
to read about the airport import, where some airports were added many
kilometres away from their accurate location, or several cases reported
here in the last few weeks of deleted surveyed data and tags, replaced
with generic un-verified tags.

Yes, some imports are good, especially when the community is consulted
and comes up with a proper way to import/tag/maintain them, but if one
individual just decides to use their own data sources, with their own
tags without consultation with the community, it almost always leads to
more damage than added value.  Its no good doing an import that 'saves'
20 hours of handwork, if it takes 100 hours of handwork to correct it.
One practical example of this, was when I made a cross-country trip last
year, and found some fuel stations were mapped upto 100km away from
their real location.  Imagine if someone was relying on that data, in a
remote area if could be life-endangering, or worse imagine if it was a
hospital import. Some things Id rather not have mapped, than to have
them mapped possibly inaccurately, or to at least have renderers show
imported data with a warning to be wary of its accuracy.

David


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Zero tolerance on imports

[Nathan Edgars II]

Richard Fairhurst wrote:
> 
> This is getting crazy.
> 
> Exhibit 1:
> http://twitter.com/#!/maproomblog/status/39053538692698112
> 
> "Whoever imported CanVec in Aylmer, Quebec obliterated hours of work and 
> introduced hundreds of errors. #osm #openstreetmap #whybother"
> 

I wonder how many complaints like this there will be if and when the license
is changed.
-- 
View this message in context: 
http://gis.638310.n2.nabble.com/Zero-tolerance-on-imports-tp6044534p6045014.html
Sent from the General Discussion mailing list archive at Nabble.com.

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Zero tolerance on imports

[Julio Costa Zambelli]

Dear Richard and everyone else,

We have a totally different experience here. We have done some import
processes here in Chile, probably not more than four or five till now, I
talked about the suburban highways import process in my "State of Chile"
presentation in Amsterdam, and after that we added: all the schools and Town
Halls in Santiago; all the Hospitals and municipal/provincial borders in the
Maule Region after the earthquake. This mostly from datasets liberated by
different government agencies, and they have been a total successes (In a
couple of days I will pick-up an external hard drive with more than 150GB of
data liberated by SECTRA, the Government Secretary of Transportation,
including aerial imagery for many of Chiles biggest cities).

Actually right now we are discussing, in the talk-cl mailing list, the
import process of all the bus stops of Transantiago (the transportation
system of Santiago). There are more than 10,000 bus stops in this dataset
(we have manually/randomly tested some of them and the accuracy of the
geolocation is pretty much the same that we get from our "on the ground
survey", the nodes also have the two codes used to identify each stop
something we do not have right now, probably because one of those codes is
a 10~12 characters alphanumeric string). The contributor that did the
request of authorisation for the dataset with the transportation authority
also researched how many bus stops we have added all over the country, and
he told me that there are no more than 700.

So this is not a very difficult decision (700 all over the country versus
more than 10,000 just for Santiago), we have talked (
http://lists.openstreetmap.org/pipermail/talk-cl/2011-February/000927.html)
about preserving the already surveyed stops, but since the data per bus stop
in the dataset is so complete it doesn't make too much sense to keep
duplicated nodes (in my particular case I probably have added "not included"
data tags like "shelter" or "towards" just to ~10% of my surveyed stops).


What I am trying to say is that not all the import processes are bad, and
the ones well planned, well executed, and broadly discussed in mailing list
and other channels of communication are really good tools for expanding our
coverage _and_ improving the quality of our data.

Cheers,

Julio Costa Zambelli
OpenStreetMap Chile

julio.co...@openstreetmap.cl

http://www.openstreetmap.cl/
Cel: +56(9)89981083
Postal: Casilla 9002, Correo 3, Viña del Mar, Chile



On 19 February 2011 21:03, Richard Fairhurst  wrote:

> This is getting crazy.
>
> Exhibit 1:
> http://twitter.com/#!/maproomblog/status/39053538692698112
>
> "Whoever imported CanVec in Aylmer, Quebec obliterated hours of work and
> introduced hundreds of errors. #osm #openstreetmap #whybother"
>
> Once again, some keyboard jockey has decided that his l337 import skills
> are better than the knowledge and hours of work by a local mapper. The
> offender appears to be user 'sammuell' by the look of it -
> http://www.openstreetmap.org/user/sammuell - though he hasn't posted
> anything about his activities on the user page, the wiki, or indeed
> anywhere.
>
> This is killing OSM. We are not here to provide a free API to government
> geodata that can be obtained trivially elsewhere. OSM is all about "added
> value"; by deleting genuine surveyed data in favour of mindless duplication
> of other, poorer quality datasets, we are _destroying_ value.
>
> From what I can tell (talk-ca postings etc.) 'sammuell' is a fairly
> inexperienced OSMer who presumably thinks "this is how things are done". It
> isn't. How do we stop this impression taking hold? How do we explain that
> imports are _not_ welcome except as a last resort, and if you do them, you
> _must_ follow a very, very rigorous set of guidelines?
>
> cheers
> Richard
>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Zero tolerance on imports

[Nathan Edgars II]

Daniel Sabo wrote:
> 
> I would think (or at least hope) that this kind of bad import would be
> less of an issue if the revert tools were not so arcane. My previous
> attempts are reverting stuff have always ended up with manual XML fiddling
> to get the desired results.
> 
I don't know how recent it is, but JOSM's reverter plugin integrates nicely
with the conflict manager.

I'm sure someone will say now that making reverts too easy is a bad thing
and that we should have zero tolerance on them (by reverting them, of
course!).
-- 
View this message in context: 
http://gis.638310.n2.nabble.com/Zero-tolerance-on-imports-tp6044534p6044953.html
Sent from the General Discussion mailing list archive at Nabble.com.

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Zero tolerance on imports

[Daniel Sabo]

On Feb 19, 2011, at 4:03 PM, Richard Fairhurst wrote:
> From what I can tell (talk-ca postings etc.) 'sammuell' is a fairly 
> inexperienced OSMer who presumably thinks "this is how things are done". It 
> isn't. How do we stop this impression taking hold? How do we explain that 
> imports are _not_ welcome except as a last resort, and if you do them, you 
> _must_ follow a very, very rigorous set of guidelines?

Maybe you don't like it, but you are not the entire OSM community. Yes, in this 
case someone overwritten what I presume was good surveyed data with an import 
was stupid. But in general the fact that data was gathered by a government 
surveyor with tools an order of magnitude more accurate than ours does not, 
IMHO, make it less "worthy" of being in OSM.

>From my limited experience working with a bunch of conflicting government 
>shapefiles is a HUGE pain in the ass. Doing quality imports where we correct 
>conflicts based on actual research (on the ground or otherwise) IS adding 
>value.

- Daniel
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Zero tolerance on imports

[Nathan Edgars II]

Andrew Errington-2 wrote:
> 
> Anyway, I like the idea of using imports as a 'scaffold' for building real 
> objects.  Imported data could sit on a separate layer, much like GPS
> traces, 
> then a mapper can either trace over the imported shapes, or select an 
> imported object and 'promote' it to become a real object (then join it up
> to 
> existing objects), or select an imported object and delete it, either
> because 
> it already exists, or it's wrong, or it has served its purpose for
> tracing.  
> Over time the import layer will fade away once all of its objects have
> been 
> scrutinised.
> 
We already have such a setup with respect to the "reviewed" tags on any
imports that include those. If we really wanted to, we could not render
anything with *reviewed=no, but that would be silly.
-- 
View this message in context: 
http://gis.638310.n2.nabble.com/Zero-tolerance-on-imports-tp6044534p6044950.html
Sent from the General Discussion mailing list archive at Nabble.com.

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Zero tolerance on imports

[Daniel Sabo]

On Feb 19, 2011, at 4:27 PM, Nic Roets wrote:

> On Sun, Feb 20, 2011 at 2:03 AM, Richard Fairhurst  
> wrote:
>> This is getting crazy.
>> 
>> Exhibit 1:
>> http://twitter.com/#!/maproomblog/status/39053538692698112
>> 
>> "Whoever imported CanVec in Aylmer, Quebec obliterated hours of work and
>> introduced hundreds of errors. #osm #openstreetmap #whybother"
>> 
>> Once again, some keyboard jockey has decided that his l337 import skills are
>> better than the knowledge and hours of work by a local mapper. The offender
>> appears to be user 'sammuell' by the look of it -
>> http://www.openstreetmap.org/user/sammuell - though he hasn't posted
>> anything about his activities on the user page, the wiki, or indeed
>> anywhere.

And has anyone bothered to email him and ask whats up? Maybe he honestly 
thought the CanVec data was better that what was there?

> I would consider that immediate ground for reverting it.

I would think (or at least hope) that this kind of bad import would be less of 
an issue if the revert tools were not so arcane. My previous attempts are 
reverting stuff have always ended up with manual XML fiddling to get the 
desired results.

It would be good to provide the user who made the changes with an easy "undo" 
button on the web interface, at least if they realized their error before other 
modifications where made to it.

> But Samuel has made over 500 changesets in the 3 years he's been
> active and most of them are normal edits. Which means a normal dispute
> resolution process may be advisable.
> 
> ___
> talk mailing list
> talk@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Zero tolerance on imports

[Mike N]

On 2/19/2011 8:48 PM, Andrew Errington wrote:

Anyway, I like the idea of using imports as a 'scaffold' for building real
objects.  Imported data could sit on a separate layer, much like GPS traces,
then a mapper can either trace over the imported shapes, or select an
imported object and 'promote' it to become a real object (then join it up to
existing objects), or select an imported object and delete it, either because
it already exists, or it's wrong, or it has served its purpose for tracing.
Over time the import layer will fade away once all of its objects have been
scrutinised.


  For this description, there is no need to even bring it into the map, 
where it will just vegetate and serve no function until activated.   But 
it would be better to create editor add-ins that work with the data as 
described above; as the scaffold import data is reviewed, it is promoted 
to the active map layer to be joined and uploaded.


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Zero tolerance on imports

[john]

I have also encountered situations where an imported road is in the correct 
location, but is incorrectly tagged, such as with the name of a street that is 
actually a couple of miles away.  The imported data may also lack Points Of 
Interest, or a given POI may be out of date (for example, I found and corrected 
a post office in my neighborhood that was still shown in its original location, 
twenty years out of date).

---Original Email---
Subject :Re: [OSM-talk] Zero tolerance on imports
>From  :mailto:a.erring...@lancaster.ac.uk
Date  :Sat Feb 19 19:48:33 America/Chicago 2011


On Sun, 20 Feb 2011 10:16:10 Mike N wrote:
> On 2/19/2011 8:04 PM, Andrew Errington wrote:
>
>   Imports aren't always bad.  Consider the equivalent case of one or
> more mappers who worked heavily in your area 2 years ago.  You might
> discover errors and lack of new roads and come to the same conclusion.

That case is not equivalent because it's hypothetical.  My observation is 
actual.

Anyway, I like the idea of using imports as a 'scaffold' for building real 
objects.  Imported data could sit on a separate layer, much like GPS traces, 
then a mapper can either trace over the imported shapes, or select an 
imported object and 'promote' it to become a real object (then join it up to 
existing objects), or select an imported object and delete it, either because 
it already exists, or it's wrong, or it has served its purpose for tracing.  
Over time the import layer will fade away once all of its objects have been 
scrutinised.

Best wishes,

Andrew

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

-- 
John F. Eldredge -- j...@jfeldredge.com
"Reserve your right to think, for even to think wrongly
is better than not to think at all." -- Hypatia of Alexandria
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Zero tolerance on imports

[Andrew Errington]

On Sun, 20 Feb 2011 10:16:10 Mike N wrote:
> On 2/19/2011 8:04 PM, Andrew Errington wrote:
>
>   Imports aren't always bad.  Consider the equivalent case of one or
> more mappers who worked heavily in your area 2 years ago.  You might
> discover errors and lack of new roads and come to the same conclusion.

That case is not equivalent because it's hypothetical.  My observation is 
actual.

Anyway, I like the idea of using imports as a 'scaffold' for building real 
objects.  Imported data could sit on a separate layer, much like GPS traces, 
then a mapper can either trace over the imported shapes, or select an 
imported object and 'promote' it to become a real object (then join it up to 
existing objects), or select an imported object and delete it, either because 
it already exists, or it's wrong, or it has served its purpose for tracing.  
Over time the import layer will fade away once all of its objects have been 
scrutinised.

Best wishes,

Andrew

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Zero tolerance on imports

[john]

In Nashville, Tennessee, USA, where I live, most of the existing data came from 
the TIGER import (mapping done by census workers).  In the areas that I have 
checked, about 60% of the data appears to be correct; about 20% needs tweaking 
for issues such as one or two streets in a neighborhood being offset by 10 or 
15 meters from their actual location, while the rest of the streets in the 
neighborhood are OK; and about 20% are either seriously obsolete (in some 
cases, by 30 years or more), or represent new construction.  In a few cases, 
the TIGER data reflects what was originally planned, as opposed to what was 
actually built (or not built).

---Original Email---
Subject :Re: [OSM-talk] Zero tolerance on imports
>From  :mailto:a.erring...@lancaster.ac.uk
Date  :Sat Feb 19 19:04:05 America/Chicago 2011


On Sun, 20 Feb 2011 09:40:03 Frederik Ramm wrote:
> Finally, all these warnings must sound hollow to someone who lives in a
> place where 90% of data around him is imported. You will have a hard
> time telling him that imports are bad.

I live in a place where 90% of the data is imported.  Imports are bad.  It's 
bad because I discover errors and start to think 'How many more errors must 
there be?'.  It's mainly bad for two reasons.  Firstly, the data is old, and 
there has been a significant road-building program going on here for a while.  
Secondly, things don't join up because the import processing didn't process 
road junctions properly, so routing doesn't work (until mappers go around and 
join them up).

IMHO imports should exist as 'ghost objects' or 'pencil lines'.  They should 
never render on Mapnik etc. and never be used for routing, but a mapper with 
local knowledge should be able to verify the objects and change them to a 
real object (i.e. 'ink them in').

Of course, if we had one million mappers here they could all take a quick look 
at their local area and fix the mistakes in a couple of days...

Best wishes,

Andrew

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

-- 
John F. Eldredge -- j...@jfeldredge.com
"Reserve your right to think, for even to think wrongly
is better than not to think at all." -- Hypatia of Alexandria
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Zero tolerance on imports

[Mike N]

On 2/19/2011 8:04 PM, Andrew Errington wrote:
> Imports are bad.  It's
> bad because I discover errors and start to think 'How many more 
errors must
> there be?'.  It's mainly bad for two reasons.  Firstly, the data is 
old, and
> there has been a significant road-building program going on here for 
a while.


 Imports aren't always bad.  Consider the equivalent case of one or 
more mappers who worked heavily in your area 2 years ago.  You might 
discover errors and lack of new roads and come to the same conclusion.


> Secondly, things don't join up because the import processing didn't 
process
> road junctions properly, so routing doesn't work (until mappers go 
around and

> join them up).

  Agreed, things should be joined properly.  But for all its warts, the 
import is much faster to get things started.   I drive around with 
Skobbler enabled whenever possible to check for Goofball driving 
instructions.  Goofball driving instructions are most often based in 
Goofball map data, which is easily fixed.


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Zero tolerance on imports

[Andrew Errington]

On Sun, 20 Feb 2011 09:40:03 Frederik Ramm wrote:
> Finally, all these warnings must sound hollow to someone who lives in a
> place where 90% of data around him is imported. You will have a hard
> time telling him that imports are bad.

I live in a place where 90% of the data is imported.  Imports are bad.  It's 
bad because I discover errors and start to think 'How many more errors must 
there be?'.  It's mainly bad for two reasons.  Firstly, the data is old, and 
there has been a significant road-building program going on here for a while.  
Secondly, things don't join up because the import processing didn't process 
road junctions properly, so routing doesn't work (until mappers go around and 
join them up).

IMHO imports should exist as 'ghost objects' or 'pencil lines'.  They should 
never render on Mapnik etc. and never be used for routing, but a mapper with 
local knowledge should be able to verify the objects and change them to a 
real object (i.e. 'ink them in').

Of course, if we had one million mappers here they could all take a quick look 
at their local area and fix the mistakes in a couple of days...

Best wishes,

Andrew

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Zero tolerance on imports

[Frederik Ramm]

Hi,

Richard Fairhurst wrote:
It isn't. How do we stop this impression taking hold? How do we explain 
that imports are _not_ welcome except as a last resort, and if you do 
them, you _must_ follow a very, very rigorous set of guidelines?


Find out what tools the importers are using. Place very big warnings in 
the existing bulk uploaders etc.; JOSM could probably be made to issue a 
warning (JOSM is good at warnings) when you load a local file with lots 
of negative IDs and try to upload that:


"Uploading this file will incur the wrath of Richard Fairhurst. Continue?"

Also, http://wiki.openstreetmap.org/wiki/Imports is currently painting 
the picture that imports are something for the real pros - and could 
even be interpreted as: "You're a real cool guy if you manage to do an 
import properly." - when instead it should read: "Every import damages 
the project, sacrificing long-term health for a short-term nice-looking 
map."


Finally, all these warnings must sound hollow to someone who lives in a 
place where 90% of data around him is imported. You will have a hard 
time telling him that imports are bad. Maybe we should treat every 
import as provisional, and if it hasn't been taken up and improved upon 
by a local community after 12 months, remove it again.


I know and accept that some people do not have a strong anti-import 
mindset. But I think we will all agree that even one mapper discouraged 
by his work being plastered over with an import is the worst possible 
outcome.


Bye
Frederik

--
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Zero tolerance on imports

[Nic Roets]

On Sun, Feb 20, 2011 at 2:03 AM, Richard Fairhurst  wrote:
> This is getting crazy.
>
> Exhibit 1:
> http://twitter.com/#!/maproomblog/status/39053538692698112
>
> "Whoever imported CanVec in Aylmer, Quebec obliterated hours of work and
> introduced hundreds of errors. #osm #openstreetmap #whybother"
>
> Once again, some keyboard jockey has decided that his l337 import skills are
> better than the knowledge and hours of work by a local mapper. The offender
> appears to be user 'sammuell' by the look of it -
> http://www.openstreetmap.org/user/sammuell - though he hasn't posted
> anything about his activities on the user page, the wiki, or indeed
> anywhere.

I would consider that immediate ground for reverting it.

But Samuel has made over 500 changesets in the 3 years he's been
active and most of them are normal edits. Which means a normal dispute
resolution process may be advisable.

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Zero tolerance on imports

[Richard Fairhurst]

This is getting crazy.

Exhibit 1:
http://twitter.com/#!/maproomblog/status/39053538692698112

"Whoever imported CanVec in Aylmer, Quebec obliterated hours of work and 
introduced hundreds of errors. #osm #openstreetmap #whybother"


Once again, some keyboard jockey has decided that his l337 import skills 
are better than the knowledge and hours of work by a local mapper. The 
offender appears to be user 'sammuell' by the look of it - 
http://www.openstreetmap.org/user/sammuell - though he hasn't posted 
anything about his activities on the user page, the wiki, or indeed 
anywhere.


This is killing OSM. We are not here to provide a free API to government 
geodata that can be obtained trivially elsewhere. OSM is all about 
"added value"; by deleting genuine surveyed data in favour of mindless 
duplication of other, poorer quality datasets, we are _destroying_ value.


From what I can tell (talk-ca postings etc.) 'sammuell' is a fairly 
inexperienced OSMer who presumably thinks "this is how things are done". 
It isn't. How do we stop this impression taking hold? How do we explain 
that imports are _not_ welcome except as a last resort, and if you do 
them, you _must_ follow a very, very rigorous set of guidelines?


cheers
Richard


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk