<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">I volunteered to report on this weeks IRC meeting.<div><br></div><div>Understandably, not everyone can attend the weekly meeting, so here is a summary:<div><br></div><div># Present</div><div><br></div><div>Jeff McKenna</div><div>Michael Smith</div><div>Pirmin Kalberer<br><div>Martin Daly</div><div>Dane Springmeyer</div><div>Oliver Tonnhofer</div><div><span class="Apple-style-span" style="font-family: 'Lucida Grande'; ">Adam Włodarkiewicz</span></div><div><br></div></div></div><div># Key Decisions</div><div>As a group we decided to use the imposm tool (<a href="http://imposm.org/">http://imposm.org/</a>) to import OSM data into PostGIS. This will provide a common source of data for the "vector" test.</div><div><br></div><div>Pros of imposm where discussed:</div><div>* It new and written from the ground up</div><div>* Will likely see large adoption soon - so great visibility.</div><div>* Many of us are familiar with osm2pgsql but happy to try something new</div><div>* Having the convertor author involved in the benchmark is a big plus</div><div><br></div><div>Cons were:</div><div> * None discussed. Hopefully we can use this mailing list to understand any drawbacks - Only potential I can see is that it has a more flexible output schema than osm2pgsql so those of us familiar with osm2pgsql will need to adjust a bit.</div><div><br></div><div>Oliver Tonnhofer, the lead developer of imposm was present and volunteered to handle the import. </div><div><br></div><div>We discussed that once the OSM data is in PostGIS the OGR2OGR can be used to convert it to different database (or other) formats that any teams wish. For example Michael Smith will then plan to move the data tables to Oracle. So, the idea here is that we must use the same processing tool to handle the initial processing of OSM data into a renderable format and common layout, but that teams can convert it from postgis to any other storage format they wish as long as the resolution and structure is maintained.</div><div><br></div><div>Please see the logs for details of this consensus: <a href="http://logs.qgis.org/foss4g/%23foss4g.2011-05-11.log">http://logs.qgis.org/foss4g/%23foss4g.2011-05-11.log</a></div><div> </div><div>Also, in light of our use of OSM data for vectors as a group we agreed to removing one item from the Rules of Engagement that is out of date:</div><div><br></div><div>"Data formats to be used will be shapefiles for vectors, and uncompressed geotiffs for rasters."</div><div><br></div><div># Follow up / Actionables</div><div><br></div><div>1) Oliver is now signed up to this list, and should work with Michael Smith (<a href="mailto:michael.smith@usace.army.mil">michael.smith@usace.army.mil</a>) to get a login to the machine where imposm should be run.</div><div><br></div><div>2) We should discuss timelines and objectives for next steps now that we have good movement on how to set up OSM/Vector data.</div><div><br></div><div>Cheers,</div><div><br></div><div>Dane</div></body></html>