Foundation/Import Support Working Group/Minutes 2009-09-10
The first meeting of the Foundation/Import Support Working Group took place Thursday 10 September 2009 at 10 AM Pacific time (California) (UTC-7), 6 PM British summer time (UK) (UTC+1) and 7 PM Central European summer time (Madrid, Paris, Berlin) (UTC+2). The participant Passcode was 727420.
Present:
- Steve Coast- OSM Founder. Likes imports.
- Richard Weait (importing canadian data)
- Simone Cortesi (interested in finding data, licensing data, not importing)
- Emilie Laffray (technical imports)
- Stephen Vogel (interested in importing stuff in the USA)
- Ivàn Sanchez Ortega - Importing in Columbia and Spain
- Russ Nelson - Importing in USA.
- Greg Matthews - USGS transport liason. Listening. Hope to help with USGS import
- Richard Shank - Oregon intersted in address imports. Writes Ruby / php.
- Matt Amos - Cloudmade API developer hopes we don't go overboard with imports.
- Harry Wood - concerned with effects of imports on community.
- Andy Allan - interested in avoiding TIGER cleanup effects in future imports.
Regrets:
none.
Russ left call after half-hour.
SteveC had call problem right at end and missed saying goodbye.
Agenda and results:
Participant introductions
See above.
Sort out the imports@osmfoundation vs. imports@openstreetmap.org lists, and their need
- Resolved to use imports@openstreetmap.org and drop @osmfoundation private list.
Divide work in to people finding data, people good at getting it licensed, and those who can do imports
- Agreed in principle for future
- Desire expressed for overview of entire process, especially for newer OSM-ers
- Considering additional steps / substeps and functions.
- consider dataset quality evaluation as a function of import group or step in import process
- consider dataset utility evaluation as a function of import group or step in import process
Create list of potential and existing imports
- several data sets to be proposed for testing, others for real imports
- Emilie, Greg, Simone, Richard to recommend data sets for evaluation corpus for various conversion / import functions.
Prioritise them
- Agreed in principle
- deferred for future
Any other business
- Continue discussions on imports@openstreetmap.org
- Next call to be scheduled for approx two weeks
live notes from call
SteveC - Proposes we shut down osmfoundation list in favour of public imports@openstreetmap.org mailing list.
Motion carries
Vision:
SteveC- introduce those with (finding) data to those negotiating permission, and those with techincal skills to convert and import.
Matt - consider value / quality of data as a step in this process.
additional tasks for group
Russ - import / data drop vs. contributors wishing feedback.
Matt - planet provides feedback
Compare cost/manpower of import vs, community mapping
Greg - can offer experience here
Emilie - corine started with separate import superimposed for demonstration and evaluation.
- tested locally, as well as a test on test.openstretmap.org
- nodes first has problems. nodes, ways, relations more effective.
- corrine shares points. Emilie is merging common points.
SteveC - perhaps we take a couple of sample data sets and work through them. to test the systems for import evaluation.
Greg -has sample data we can use.
Emilie - used postgis to exclude overlapping areas before upload. Corrine imports are closer to feature by feature than bulk_import.
SteveC - break into separate groups who pass work back and forth?
Andy - warned that this may be too stratified.
others - concurred
Richard Shank - new to project and overview is appreciated.
SteveC - we'll review dividing group again in future.
Richard - dream tool would reduce overlap / duplicates.
Russ - why import when you know the data exists? SteveC - defers this concern.
Matt - likes Sam V's preference for no bulk uploads, but provide a tool for individual inclusion from a dataset, one feature at a time. Emilie - plans not to abandon corrine dataset. SteveC- Matt clarify? Matt - user views multiple data sources, evaluates for an area, then commits them to OSM. Needs fleshing out. Andy - let's considere generic data, not just TIGER. Overlapping is bad.
SteveC - next steps.
Andy - find some sample data sets. visualize and evaluate them. Emilie - wiki discussion for which codes to convert, and how. Andy - can Canada, etc publish some best practices? Emilie / Richard - both will reply this week. Andy - little followup documentaiton for Emilie
SteveC - suggestions to m,ailing list for next week. Steven - consider overlapping data non-overlapping as well as data from differen scales,
Simone - Perhaps some Italian boundary data with replacement higher precision data.
Simone - are we happy with personal recognizance on licensing? Ivan - seems fine. Andy - some transparency concerns, limited visibility in advance is potential problem. Matt - concur.
Andy - possibliity of ODBL should be menitioned
Steven - How do we know a license is compatible?
Andy - Often best to ask the provider directly.
Matt - Really better to warn.
Steven - Is there a typical license document?
Richard W - Can provide samples
Ivan - blanket license letter is a local concern. Local laws will require local wisdom. Local chapters should lead only local letters.
SteveC - next call circa. one / two weeks.
others - two weeks? Two weeks
Andy - Richard will add roadmatcher summary to mailing list
Ivan - will get columbia border data. Is there a boundary way / relation tool?
Andy - Ivan, check with dev?
Emilie - will publish sql scripts for overlap discovery.
Call ended.
Ideas: - build a better bug system.
Minutes were recorded by User:Rw.