Foundation/Import Support Working Group/Minutes 2009-09-10

From OpenStreetMap Wiki
Jump to: navigation, search

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.


  • 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.



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. lists, and their need

  • Resolved to use 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
  • Next call to be scheduled for approx two weeks

live notes from call

SteveC - Proposes we shut down osmfoundation list in favour of public mailing list.

Motion carries


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
  • 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.