Hi all, As you my know there is a great tool call gdalcontour that will help trace sat images. The problem with it, it produces a huge amount of data. I have been working on how to process this data.
First I used shp2osm.pl to produce osm files from the output, but they are still huge. Then I used my modified version that splits into 100 way packages. http://xhema.flossk.org:8080/mapdata/02/mdupont/dlr/contours/shp2osm_split.pl Now today, I have rewarmed my c++ processing tool for high speed, single-pass osm processing, I have a program FindClosedWays (compiled version) <http://xhema.flossk.org:8080/mapdata/03/EPANatReg/FindClosedWays>that will emit only closed ways and only the ones above a certain length. That way you can remove alot of the junk. 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. here is my blog post for it, http://osmopenlayers.blogspot.com/2010/03/first-version-of-way-cutter.html Code and compiled version is here : http://xhema.flossk.org:8080/mapdata/03/EPANatReg/?C=M;O=A The code is also checked into the bzr repo on launchpad. I hope to make more filter features, for example to split data on a keyfield into new files, or to be able to process 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 http://www.gnu.org/software/libredwg/ 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. 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. 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. This can be optimized further. I have exploited the following optimisations : 1. the nodes are all declared before they are referenced. 2. the xml is not nested, its basically flat. I admit the code is not as clean as I would like it, but the speed and flexibility is promising, 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. The program is invoked like this : ./FindClosedWays INPUT LENGTH OUTPUT ./FindClosedWays inputways_2054100.osm 50 test_out_contour_ways_2054100.osm 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. Anyway, I hope some of my ideas will be adopted in OSM some day. mike
_______________________________________________ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
