akollmorgen at gmail.com
Wed Feb 16 13:37:49 GMT 2011
On 2011-01-14 13:33, Daniel Sabo wrote:
> I have a beta version of an osm2spatialite script written in python.
> Neither the GOES C api and SpatialLite have a version of BuildArea
> so most of the code is devoted to assembling multipolygons, so
> that's the area it's most likely to produce different results than
SpatiaLite has BuildArea() support since 2010-04-01 (svn) / 2010-08-15
(2.4.0 RC3) [1,2]. also, spatialite-tools include the spatialite_osm_*
tools, among them spatialite_osm_raw, which "simply acquir[es] OSM XML
into DB tables (fully preserving the XML layout)" . the schema
generated by spatialite_osm_raw is different from the osm2pgsql schema,
but all the important ingredients (raw data for nodes, ways, relations;
tags; join tables for ways and relations; geometry for nodes) are there.
it wouldn't require too much effort to transform this into the osm2pgsql
schema, either by postprocessing it with sql, or (probably the better
idea) by adapting spatialite_osm_raw.c. we might even suggest a
spatialite_osm_pgsql tool to Alessandro "Sandro" Furieri, the developer
of SpatiaLite - he is known for magically producing code for many
> Ram is an issue so I'm not sure python is the best choice in the long
> term. Right now a 450MB xml file takes ~900MB to process. It is
> fairly speedily though as long as you don't run out of memory.
running spatialite_osm_raw on a 368MB osm file takes 76 secs and less
than 30MB RAM (on a virtual debian server with 1GB RAM). this will take
more if we want to have osm2pgsql's geometry tables for lines, roads,
and polygons also. i still find this quite impressing, and i'm sure it
is way more efficient than doing the processing in python.
More information about the dev