Re: [Talk-us] Would Like To Clean Salt Lake City Street Names

2010-08-05 Thread Kevin Atkinson


This is in progress, and taking forever (I about 10,000 ways in all).

Apparently uploading large changesets with JOSM takes a long time.  Not 
sure if it's JOSM or the server.  Worse, I started to upload some changes 
(using 1000 size chunks as JOSM couldn't handle it all at once), but it 
took forever and didn't look like it was making progress so I canceled it. 
Well apparently the server got the changes and posted them so when I tried 
again I got a conflict. ... and than after trying various things which I 
won't go into I got things going again, this time using 100 size chunks so 
at least I know its making progress.


Moral of the story, when uploading a large changeset with JOSM use small 
chunks (like 100) or be very very patient.


BTW: I also looked into using an upload script, but the only one I could 
find that would do what I want with the new API (0.6) requires python 3 
which I don't have installed (there is a python 2 version, but that failed 
with a syntax error).



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


Re: [Talk-us] Proposal to change ref format for county roads in Florida from (x) to CR x

2010-08-05 Thread Nathan Edgars II
On Wed, Aug 4, 2010 at 1:46 PM, Alan Mintz alan_mintz+...@earthlink.net wrote:
 I've written perl scripts in the past, but these ad-hoc changes I've done as
 follows:
[snip]

Thanks - this worked perfectly. I've uploaded
http://www.openstreetmap.org/browse/changeset/5406539.

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


Re: [Talk-us] Would Like To Clean Salt Lake City Street Names

2010-08-05 Thread Apollinaris Schoell
It's the API not JOSM. You have to be patient. 



On 5 Aug 2010, at 24:40 , Kevin Atkinson wrote:

 
 This is in progress, and taking forever (I about 10,000 ways in all).
 
 Apparently uploading large changesets with JOSM takes a long time.  Not sure 
 if it's JOSM or the server.  Worse, I started to upload some changes (using 
 1000 size chunks as JOSM couldn't handle it all at once), but it took forever 
 and didn't look like it was making progress so I canceled it. Well apparently 
 the server got the changes and posted them so when I tried again I got a 
 conflict. ... and than after trying various things which I won't go into I 
 got things going again, this time using 100 size chunks so at least I know 
 its making progress.
 
 Moral of the story, when uploading a large changeset with JOSM use small 
 chunks (like 100) or be very very patient.
 
 BTW: I also looked into using an upload script, but the only one I could find 
 that would do what I want with the new API (0.6) requires python 3 which I 
 don't have installed (there is a python 2 version, but that failed with a 
 syntax error).
 
 
 ___
 Talk-us mailing list
 Talk-us@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-us


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


Re: [Talk-us] Would Like To Clean Salt Lake City Street Names

2010-08-05 Thread Serge Wroclawski
I'm afraid we've veered way off topic here.

There were three topics and I'd like to close one of them (or spin it
off) and discuss the other two.

Topic 3 (the unimportant one):

Periods are AFAIK, valid in OSM. We don't care about the underlying
implementation, whether it's Postgres or Mongo or anything else. We
communicate to an API and the API says what is and isn't valid. For
you CS people, that's why we have APIs and separation of concerns. :)

I'm happy to discuss this with folks (as I've looked into this a bit)
but I'd love if we dropped it from this thread.

Topic 1:

Is this proposed mass-change something good for Salt Lake City. That
is does it fit in with the way locals name the streets. This seemed to
get lost somewhere in the discussion but is the most important thing
about this change.

A rule of thumb is if you're thinking of doing something like this,
announce it and wait 10 days for feedback. 10 days is just long enough
to be frustrating, and gives people time to give useful feedback. Of
course I'm not the king of OSM, but that's just something I recommend


Topic 2:

Bots and Imports

I don't know why we in the US love bots and imports so much. I admit
their utility, but we have to be really careful about them.

What do people think of a something like A friendly guide to bots and imports?

- Serge

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


[Talk-us] A Friendly Guide to 'Bots and Imports

2010-08-05 Thread Richard Weait
On Thu, Aug 5, 2010 at 1:19 PM, Serge Wroclawski emac...@gmail.com wrote:
[ ... ]
 What do people think of a something like A friendly guide to bots and 
 imports?

I like it.  Let's start.

Required reading:

http://www.asklater.com/matt/wordpress/2009/09/imports-and-the-community/
http://www.asklater.com/matt/wordpress/2009/09/imports-and-the-community-ii/

And previous guidance on 'bots and imports:

http://wiki.openstreetmap.org/wiki/Imports
http://wiki.openstreetmap.org/wiki/Import/Guidelines
http://wiki.openstreetmap.org/wiki/Automated_Edits/Code_of_Conduct

And support, the imports mailing list:

http://lists.openstreetmap.org/listinfo/imports

Motto:

It doesn't take years of experience to mess up an import really
badly.  But it helps.

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


Re: [Talk-us] A Friendly Guide to 'Bots and Imports

2010-08-05 Thread Frederik Ramm

Hi,

Richard Weait wrote:

Required reading:

http://www.asklater.com/matt/wordpress/2009/09/imports-and-the-community/
http://www.asklater.com/matt/wordpress/2009/09/imports-and-the-community-ii/


I also like The Pottery Club:

http://www.gravitystorm.co.uk/shine/archives/2009/11/10/the-pottery-club/

Bye
Frederik

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

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


Re: [Talk-us] A Friendly Guide to 'Bots and Imports

2010-08-05 Thread Nathan Edgars II
One thing I'm wondering about: how useful is a small piece of a future
larger import? For example, there's the National Hydrography Dataset,
import of which is apparently being coordinated on the wiki. I've
imported individual lakes and swamps from it, as well as all of those
in small areas (such as Disney World). Obviously this is a good thing
if I'm working on the area. But does it help at all for a future
larger import, or is it just more 'noise' like lakes drawn from
aerials?

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


Re: [Talk-us] A Friendly Guide to 'Bots and Imports

2010-08-05 Thread Ian Dees
On Thu, Aug 5, 2010 at 1:27 PM, Nathan Edgars II nerou...@gmail.com wrote:

 One thing I'm wondering about: how useful is a small piece of a future
 larger import? For example, there's the National Hydrography Dataset,
 import of which is apparently being coordinated on the wiki. I've
 imported individual lakes and swamps from it, as well as all of those
 in small areas (such as Disney World). Obviously this is a good thing
 if I'm working on the area. But does it help at all for a future
 larger import, or is it just more 'noise' like lakes drawn from
 aerials?


I think the NHD import is a good example of a well-intentioned importer
(me) gone wrong. I had initially planned to import the whole darn thing in
one swoop, but various technical and life challenges came up before I could
get it going. While I was working on those issues, people started importing
it themselves (sometimes marking so on the wiki, sometimes not). Now that
there are some areas imported, the import of the whole dataset becomes
infinitely harder because we have to match existing data with new OSM-ified
data.

What I'm trying to say is that once a small part of an import happens, the
larger import probably doesn't make sense to do.
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us


Re: [Talk-us] A Friendly Guide to 'Bots and Imports

2010-08-05 Thread Nathan Edgars II
On Thu, Aug 5, 2010 at 2:38 PM, Ian Dees ian.d...@gmail.com wrote:
 I think the NHD import is a good example of a well-intentioned importer
 (me) gone wrong. I had initially planned to import the whole darn thing in
 one swoop, but various technical and life challenges came up before I could
 get it going. While I was working on those issues, people started importing
 it themselves (sometimes marking so on the wiki, sometimes not). Now that
 there are some areas imported, the import of the whole dataset becomes
 infinitely harder because we have to match existing data with new OSM-ified
 data.

But how is this any different from importing it into an area where
people have already mapped some lakes from aerials?

Personally I think the best US example of a bad import is the
environmental hazards.

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


Re: [Talk-us] A Friendly Guide to 'Bots and Imports

2010-08-05 Thread Ian Dees
On Thu, Aug 5, 2010 at 1:47 PM, Nathan Edgars II nerou...@gmail.com wrote:

 On Thu, Aug 5, 2010 at 2:38 PM, Ian Dees ian.d...@gmail.com wrote:
  I think the NHD import is a good example of a well-intentioned importer
  (me) gone wrong. I had initially planned to import the whole darn thing
 in
  one swoop, but various technical and life challenges came up before I
 could
  get it going. While I was working on those issues, people started
 importing
  it themselves (sometimes marking so on the wiki, sometimes not). Now that
  there are some areas imported, the import of the whole dataset becomes
  infinitely harder because we have to match existing data with new
 OSM-ified
  data.

 But how is this any different from importing it into an area where
 people have already mapped some lakes from aerials?


It isn't any different. I had made the (bad) decision at the time to import
over any existing data because in the several hundred places I spot-checked,
NHD was vastly superior in resolution (and probably quality).

If we wanted to support imports as a community, a tool like [0] should be
the only way of letting imports in to OSM.

[0]
http://wiki.openstreetmap.org/wiki/OSM_Import_Database#French_Corine_Import_as_Template
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us


Re: [Talk-us] A Friendly Guide to 'Bots and Imports

2010-08-05 Thread Ian Dees
On Sat, Jan 8, 2000 at 3:20 PM, Katie Filbert filbe...@gmail.com wrote:

 The difference with NHD is that we are leaving conversion to osm format for
 the local mapper / importer.  Since OSM US has server space, maybe that's
 good use of it to host converted data ready for import.


I like this... the NHD status page on the wiki sort of already does this in
a backwards way. Perhaps I will look in to writing a web tool to keep track
of the import and give easy access to the pre-generated OSM files for
subbasins.
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us


Re: [Talk-us] A Friendly Guide to 'Bots and Imports

2010-08-05 Thread Richard Weait
On Sat, Jan 8, 2000 at 4:20 PM, Katie Filbert filbe...@gmail.com wrote:
 Bad imports are bad for the osm.  High quality data carefully imported is
 helpful.  If such high quality data is available for us that is as good or
 better than what we can do ourselves, then it's fine not to reinvent the
 wheel. Where it's lower quality data than what we can do ourselves, then
 let's not use it.
[ ... ]
 Leaving imports to local mappers is good.  They are best able to assess the
 quality of the data for that area an care about quality of their local map
 data.   It also leaves low hanging fruit for them. Some areas without
 local mappers may take longer to finish. That is okay.

I have no arguments with this.

Consider this: Does importing to an area where there is no thriving
OSM community inhibit the creation of that thriving community in
future?

At SotM, one of our friends suggested that imports are, okay except
road networks.  Never import road networks.  The suggestion is that
building the road network also builds the community.  An existing road
network inhibits the community.  I apologize for not attributing that
comment.  I've forgotten who said it to me.

Or from another point of view.  If the local community isn't
substantial enough to maintain the imported data and keep it up to
date, is it better to not import until the community can maintain it?
Why import 2004 data, if it will be unchanged when the 2006 update is
published?  Does that mean that you should only import once you have
such a thriving community and high quality local data that you no
longer would benefit substantially from that import?

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


Re: [Talk-us] A Friendly Guide to 'Bots and Imports

2010-08-05 Thread David Carmean
On Thu, Aug 05, 2010 at 01:38:36PM -0500, Ian Dees wrote:


 I think the NHD import is a good example of a well-intentioned importer
 (me) gone wrong. I had initially planned to import the whole darn thing in
 one swoop, but various technical and life challenges came up before I could
 get it going. While I was working on those issues, people started importing
 it themselves (sometimes marking so on the wiki, sometimes not). Now that
 there are some areas imported, the import of the whole dataset becomes
 infinitely harder because we have to match existing data with new OSM-ified
 data.

And I'll add my own mea-culpa.  I created some wiki pages/features to
help partition and coordinate NHD import efforts, and then also found
that I didn't have the time to follow up.

I would agree that the partial imports will have increased the difficulty
of a large-scale bulk import, but we already had hydrographic features
from TIGER, did we not.  And hand-drawn features from aerial traces and
actual boots-on-the-ground mapping.  Conflation in general is a tough
problem, I gather.  There are tools, algorithms and heuristics in the
GIS world but the OSM data model makes translation between the two models
somewhat difficult.

For example, something that looks very interesting which I plan to examine
is the Java Conflation Suite [1], which looks like it could be used over
relatively small areas (probably about the size of the API limit... 0.25
degrees square?).  But as a component of the JUMP[2] platform, it operates
only on Shapefiles and GML out of the box.  (If we could get some Java
expertise I think it would be very worthwhile working with the JUMP team
to create an OSM driver.)

At any rate, while I think we could mitigate a number of problems 
given some development effort, I also agree that we might want to 
spend more time thinking about why we want to make the imports--and 
perhaps publically debate, if only in talking to yourself on the 
project wiki page, the pros and cons of a particular import.



[1] http://www.vividsolutions.com/JCS/
[2] http://www.vividsolutions.com/jump/



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


Re: [Talk-us] A Friendly Guide to 'Bots and Imports

2010-08-05 Thread Frederik Ramm

Katie,

   your computer thinks it is the year 2000. I see you sent that from 
your iPhone. Maybe you had your fingers on the wrong spot so it didn't 
get a time signal.


Katie Filbert wrote:
Bad imports are bad for the osm.  High quality data carefully imported 
is helpful. 


Not unconditionally.

For example, high quality data carefully exported which is a copy of 
someone else's, and which is maintained professionally at the source, 
may not be helpful (because while we import it as high quality, the 
quality vis-a-vis the original source will deteriorate over time, with 
the original source issuing updates that we cannot import easily).


Also, high quality data carefully imported which depicts things we 
cannot possibly edit - example: official airspace boundaries - is not 
helpful, since we are not a collector of data, but a data maintenance 
machine - anything static that cannot be modified by our mappers will 
always remain a foreign object.


Leaving imports to local mappers is good.  They are best able to assess 
the quality of the data for that area an care about quality of their 
local map data. It also leaves low hanging fruit for them. Some 
areas without local mappers may take longer to finish. That is okay.


+1 to that.

Bye
Frederik

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

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


Re: [Talk-us] A Friendly Guide to 'Bots and Imports

2010-08-05 Thread David Carmean
On Thu, Aug 05, 2010 at 10:38:47PM +0200, Frederik Ramm wrote:
 Katie,
 
 your computer thinks it is the year 2000. I see you sent that from 
 your iPhone. Maybe you had your fingers on the wrong spot so it didn't 
 get a time signal.

Not only that, all of your messages (katie) are being trapped as spam 
by my provider's system, probably because of the bad date.


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


Re: [Talk-us] A Friendly Guide to 'Bots and Imports

2010-08-05 Thread Alan Mintz

At 2010-08-05 11:52, Ian Dees wrote:

...
It isn't any different. I had made the (bad) decision at the time to 
import over any existing data because in the several hundred places I 
spot-checked, NHD was vastly superior in resolution (and probably quality).


By import over, do you mean to add duplicates, replace the existing 
features, or merge the info from the two manually?


As I manually survey various features (POIs, some hydro, etc.), I usually 
try to merge in the data from existing imports so as to maintain the link 
(e.g. gnis:feature_id) back to the original database, in case we want to 
exchange updates with them again.


One thing that occurs to me that may be a problem is that I occasionally 
have to delete a feature that is no longer present (e.g. 
http://www.openstreetmap.org/browse/node/358808220). If we were to feed an 
update back to GNIS or get one from them, this situation would have to be 
taken into account.


--
Alan Mintz alan_mintz+...@earthlink.net


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


Re: [Talk-us] A Friendly Guide to 'Bots and Imports

2010-08-05 Thread Ian Dees
On Thu, Aug 5, 2010 at 4:43 PM, Alan Mintz
alan_mintz+...@earthlink.netalan_mintz%2b...@earthlink.net
 wrote:

 At 2010-08-05 11:52, Ian Dees wrote:

 ...
 It isn't any different. I had made the (bad) decision at the time to
 import over any existing data because in the several hundred places I
 spot-checked, NHD was vastly superior in resolution (and probably quality).


 By import over, do you mean to add duplicates, replace the existing
 features, or merge the info from the two manually?


Add duplicates.


 As I manually survey various features (POIs, some hydro, etc.), I usually
 try to merge in the data from existing imports so as to maintain the link
 (e.g. gnis:feature_id) back to the original database, in case we want to
 exchange updates with them again.

 One thing that occurs to me that may be a problem is that I occasionally
 have to delete a feature that is no longer present (e.g.
 http://www.openstreetmap.org/browse/node/358808220). If we were to feed an
 update back to GNIS or get one from them, this situation would have to be
 taken into account.


When I made the original GNIS import I saved the resulting XML and IDs
(which would have allowed us to detect deletions) but promptly lost it in a
hard drive crash.
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us


Re: [Talk-us] A Friendly Guide to 'Bots and Imports

2010-08-05 Thread James U
I have to say that after importing a large amount of NHD data (most of NC 
and MN) that it is of varying quality, as was the preexisting water related 
data already on the server.  In general, I agree with Ian that it is higher 
quality (both resolution and accuracy) than the preexisting data that 
largely consisted of quickly drawn Yahoo traces.  I saw very little evidence 
of on the ground surveying of these features and don't think the import 
will hinder most people from participating in OSM writ large.

I have a fair bit of experience in converting data and would be happy to 
convert subbasins (these appear to be rougly 2500 square mile areas 
and are documented on the wiki) for people if they want to go through 
the process of double checking to make sure the data don't conflict with 
or overlap already existing data.

James

On Thursday, August 05, 2010 04:29:19 pm David Carmean wrote:
 On Thu, Aug 05, 2010 at 01:38:36PM -0500, Ian Dees wrote:
  I think the NHD import is a good example of a well-intentioned 
importer
  (me) gone wrong. I had initially planned to import the whole darn 
thing
  in one swoop, but various technical and life challenges came up 
before I
  could get it going. While I was working on those issues, people 
started
  importing it themselves (sometimes marking so on the wiki, 
sometimes
  not). Now that there are some areas imported, the import of the 
whole
  dataset becomes infinitely harder because we have to match existing 
data
  with new OSM-ified data.
 
 And I'll add my own mea-culpa.  I created some wiki pages/features to
 help partition and coordinate NHD import efforts, and then also found
 that I didn't have the time to follow up.
 
 I would agree that the partial imports will have increased the difficulty
 of a large-scale bulk import, but we already had hydrographic features
 from TIGER, did we not.  And hand-drawn features from aerial traces 
and
 actual boots-on-the-ground mapping.  Conflation in general is a tough
 problem, I gather.  There are tools, algorithms and heuristics in the
 GIS world but the OSM data model makes translation between the two 
models
 somewhat difficult.
 
 For example, something that looks very interesting which I plan to 
examine
 is the Java Conflation Suite [1], which looks like it could be used over
 relatively small areas (probably about the size of the API limit... 0.25
 degrees square?).  But as a component of the JUMP[2] platform, it 
operates
 only on Shapefiles and GML out of the box.  (If we could get some Java
 expertise I think it would be very worthwhile working with the JUMP team
 to create an OSM driver.)
 
 At any rate, while I think we could mitigate a number of problems
 given some development effort, I also agree that we might want to
 spend more time thinking about why we want to make the imports--and
 perhaps publically debate, if only in talking to yourself on the
 project wiki page, the pros and cons of a particular import.
 
 
 
 [1] http://www.vividsolutions.com/JCS/
 [2] http://www.vividsolutions.com/jump/
 
 
 
 ___
 Talk-us mailing list
 Talk-us@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-us

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


Re: [Talk-us] Would Like To Clean Salt Lake City Street Names

2010-08-05 Thread Kevin Atkinson
BTW: In case you missed it I already did the initial upload.  But there is 
always room to fix things up.


On Thu, 5 Aug 2010, Serge Wroclawski wrote:


Is this proposed mass-change something good for Salt Lake City. That
is does it fit in with the way locals name the streets. This seemed to
get lost somewhere in the discussion but is the most important thing
about this change.


Yes it does, and also how they are signed.

The rest is for another thread.

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


Re: [Talk-us] A Friendly Guide to 'Bots and Imports

2010-08-05 Thread Nathan Edgars II
On Thu, Aug 5, 2010 at 6:10 PM, James U jumba...@gmail.com wrote:
 I have to say that after importing a large amount of NHD data (most of NC
 and MN) that it is of varying quality, as was the preexisting water related
 data already on the server.  In general, I agree with Ian that it is higher
 quality (both resolution and accuracy) than the preexisting data that
 largely consisted of quickly drawn Yahoo traces.  I saw very little evidence
 of on the ground surveying of these features and don't think the import
 will hinder most people from participating in OSM writ large.

On the other hand, my (extremely limited) experience is that the
aerial water traces for Disney World were superior to the NHD import
(so I quickly deleted all the dupes from NHD). But the swamps were a
lot more useful, since you can't really tell if something's swampy
without physically going there. I love how all these islands
suddenly made sense:
http://www.openstreetmap.org/?lat=28.29lon=-81.5191zoom=14layers=M

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


Re: [Talk-us] Would Like To Clean Salt Lake City Street Names

2010-08-05 Thread Kevin Atkinson


So the upload went well, there is still a lot that can be done but this a 
good first start.


I am going to fix up the script so that it can run repeatably on the same 
area to allow it to further be refined.


Maybe I make the source available, but it only really should be used in 
areas that use a Salt Lake City style grid system.


If anyone wan't me to run it on other areas just let me know.  It will 
only fix streets on a single grid system so its pretty safe to run without 
steeping on anyone else's toes.




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


Re: [Talk-us] A Friendly Guide to 'Bots and Imports

2010-08-05 Thread Kevin Atkinson


Some guides aimed at focused scripts which address a particular problem in 
a well defined area would be useful, as most of the guide is aimed at 
automatic fixup bots and large scale imports.  For example a note in big 
bold letters that large uploads take a long time will be very helpful. 
Also a guide to using JOSM advanced chunk upload feature will be very 
helpful.


Also, I think what the bot does is very important, tag fixups are 
generally a lot safer than bots which affect nodes, and those are safer 
than those that remove ways.



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


Re: [Talk-us] A Friendly Guide to 'Bots and Imports

2010-08-05 Thread andrzej zaborowski
Hi,

On 5 August 2010 21:46, Richard Weait rich...@weait.com wrote:
 On Sat, Jan 8, 2000 at 4:20 PM, Katie Filbert filbe...@gmail.com wrote:
 Leaving imports to local mappers is good.  They are best able to assess the
 quality of the data for that area an care about quality of their local map
 data.   It also leaves low hanging fruit for them. Some areas without
 local mappers may take longer to finish. That is okay.

Definitely there are advantages from the import being done by a local,
but, as always, there are also advantages from the import being done
by the author of conversion script, someone who understands exactly
what parts need to be checked manually and someone who has done many
such imports instead of only a limited area.  (I have taken part in an
import where I made converted data available on the web for locals to
import and often had to spend longer fixing stuff after them than it
would have taken me to do it myself).

So it's hard to stand on one side or the other, probably best to look
at it case by case.


 I have no arguments with this.

 Consider this: Does importing to an area where there is no thriving
 OSM community inhibit the creation of that thriving community in
 future?

 At SotM, one of our friends suggested that imports are, okay except
 road networks.  Never import road networks.  The suggestion is that
 building the road network also builds the community.  An existing road
 network inhibits the community.  I apologize for not attributing that
 comment.  I've forgotten who said it to me.

 Or from another point of view.  If the local community isn't
 substantial enough to maintain the imported data and keep it up to
 date, is it better to not import until the community can maintain it?
 Why import 2004 data, if it will be unchanged when the 2006 update is
 published?  Does that mean that you should only import once you have
 such a thriving community and high quality local data that you no
 longer would benefit substantially from that import?

I totally agree here, it's a bit of a trade-off choosing the right
moment.  If you do it too soon, you get an unmaintained map of the
area.  If you do it too late, local mappers who didn't know about the
datasource contribute their time to re-collect the data, which later
clashes with the datasource and costs time to choose the better
version, to merge, and it is frustrating when someone finds out they
could have spent the time on the finer details.

Cheers

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


[Talk-us] minutes from August 5th OSMF US chapter conference call

2010-08-05 Thread Richard Welty

 the web page may be found here:

https://docs.google.com/document/pub?id=1YTf9-iUKivwvAOEN6VpkGRyDDrABMIsMAFtiF5ehBz0


OSM US Chapter Call August 5th, 2010



Attendees

Kate Chapman, Serge Wroclawski, Richard Welty, Thea Clay, Steven Johnson

Approval of Minutes

July 22nd, 2010

https://docs.google.com/document/pub?id=1lfEfdlHwM3Gxi26UpfexQ1FgI2DmE4K4gDUE8_mqb7o

Thea motion to approve, Serge seconded. no objections, minutes approved.

Consent Agenda

Nothing scheduled.

Officers Reports

Kate Chapman (President)

Has been focused on SOTM-US stuff. Wishes to start on tax-exempt 
paperwork after SOTM-US.




Serge Wroclawski (VP)

Working on presentations and with Ian on OSM US server work.

Richard Welty (Secretary)

1) Membership report as of 6PM ET 8/5/2010. 23 have filled out 
membership forms: 20 paid members, 2 have submitted forms but not paid 
via Paypal. 1 has paid via paypal but the payment was reversed. One 
student discount so far. Need to contact (again) the 3 unpaid to resolve 
the issue.


2) Election report: nominations open, 9 nominations. All nominees to 
date are paid members and eligible to serve.


3) i have requested that mailman (or equivalent mailing list manager) be 
installed on openstreetmap.us to facilitate an announce@ list for members.


Thea Clay (Treasurer)

- PayPal account = $1,613.94 USD as of 5:20 PM August 5, 2010.

(Apx $400 in membership dues and $1,200 in SOTM US fees and sponsorships)

- Wachovia Bank total = $.22 as of 5:20 August 5, 2010.

- Need to work out a process to transfer accounts to new treasurer asap 
because transfer of accounts will be involved process and require 
multiple steps. Suggest finding way to avoid having accounts in 
individuals names in the future.


- Vendor payments begin for SOTM US on Monday August 9, 2010

Steven Johnson (at Large)

1) Ticket issue for SOTM registrant. Thea has started corrective action.

2) Working on SOTM issues for the past several weeks, sponsorship and 
panel related.


Old Business

Election Observer

Thea hopes to have a name for an Independent Election Observer to 
nominate shortly.


Election Procedure

After some discussion, it was agreed to use survey monkey as was done 
with the first election.


New Business

Role Email accounts

These are needed for roles such as treasurer. Action item for Serge. 
This will facilitate handing Thea’s concern about transition of 
Treasurer to a new board member.


Annual Meeting Format

The question was raised of how we will run the first annual meeting. 
Serge suggests we probably are required to produce a formal annual 
report. It was agreed that we would all review the bylaws and further 
discuss in email.


Mapping Parties

Kate reports Penn State wants to learn how to put on a mapping party.

Serge is still working on a DC mapping party, but is deferring further 
effort until after SOTM US.


Motion to Adjourn

Thea motion to adjourn, Kate seconded. No objections, meeting adjourned.


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