Hi all,<br><br>As you my know there is a great tool call gdalcontour that will help trace sat images. <br>The problem with it, it produces a huge amount of data. I have been working on how to process this data.<br><br>First I used <a href="http://shp2osm.pl">shp2osm.pl</a> to produce osm files from the output, but they are still huge.<br>

Then I used my modified version that splits into 100 way packages.<br><a href="http://xhema.flossk.org:8080/mapdata/02/mdupont/dlr/contours/shp2osm_split.pl">http://xhema.flossk.org:8080/mapdata/02/mdupont/dlr/contours/shp2osm_split.pl</a><br>

<br>Now today, I have rewarmed my c++ processing tool for high speed, single-pass osm processing, <br>I have a program <a href="http://xhema.flossk.org:8080/mapdata/03/EPANatReg/FindClosedWays">FindClosedWays (compiled version) </a>that will emit only closed ways and only the ones above a certain length.<br>

That way you can remove alot of the junk. <br><br>This can be used for lakefinding and also forest finding. The image data can be preprocessed with different tools to extract colors, or apply filtering.<br><br>here is my blog post for it,<br>

<a href="http://osmopenlayers.blogspot.com/2010/03/first-version-of-way-cutter.html">http://osmopenlayers.blogspot.com/2010/03/first-version-of-way-cutter.html</a><br><br>Code and compiled version is here :<br><a href="http://xhema.flossk.org:8080/mapdata/03/EPANatReg/?C=M;O=A">http://xhema.flossk.org:8080/mapdata/03/EPANatReg/?C=M;O=A</a><br>

<br>The code is also checked into the bzr repo on launchpad.<br><br>I hope to make more filter features, for example to split data on a keyfield into new files, or to be able to process <br><br>I will also look into how my tools can fit into the ogr/gdal toolkit, I wonder why they dont deal with OSM data, or do they? there is the ogr2osm tool as well. Also we have this <a href="http://www.gnu.org/software/libredwg/">http://www.gnu.org/software/libredwg/</a> as a possible future datasource as well as my work on the dime/twonickets dxf2osm. And I have been working on the mapnik c++ code that is stalling atm. All of those programs work on structured geometry files. We should have a simple template callback system that can be adapted to all these tools to be able to process and emit structured data from them. <br>

<br>Of course we can just use OSM as our file format, and that is what I am doing here. I am also working with skippern on brasilian cad files. We are in the negotiations on getting a huge load of cad files from albania at the moment. When that happens, we will need tools to splitup and extract features from them.<br>

<br>Now my code works in a single pass, at least over the entire data. It builds up node indexes to remove duplicate, and processes the waypoints of each roads 3 times, one to read them and look for duplicates and one to emit the nodes. <br>

<br>This can be optimized further. I have exploited the following optimisations :<br>1. the nodes are all declared before they are referenced.<br>2. the xml is not nested, its basically flat.<br><br>I admit the code is not as clean as I would like it, but the speed and flexibility is promising,<br>

one area of the code that is a problem is the end node handling, there I introduced an enum to track in what node type I am in. this code needs to be refactored into the base class.<br><br>The program is invoked like this : <br>

./FindClosedWays INPUT LENGTH OUTPUT<br><br>./FindClosedWays inputways_2054100.osm 50 test_out_contour_ways_2054100.osm<br><br>As I have talked about previously, there is a great need for some high speed c++ processing in osm. I hope to make these tools to be usable in a  plug in processing schema. So you can activate certain features via including the templates for the algorithms and have the data shared.<br>

<br>Anyway, I hope some of my ideas will be adopted in OSM some day.<br><br>mike<br>