Re: [Talk-us] Would Like To Clean Salt Lake City Street Names
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
