Jeff McKenna <jmckenna <at> gatewaygeomatics.com> writes: > > Hi all, > > I've successfully used the OSM driver[1] to convert from the OSM pbf > binary format into another (in my case Postgres/PostGIS, and testing > with Japan dataset). The time to do this is much much faster than other > tools such as osm2pgsql (once I learned the "PG_USE_COPY YES" parameter > the time went from more than 3 hours down to minutes). > > That is the good news. The bad news is that I am stuck now because the > OSM driver does not set z_order (rendering order) values, which are > important for display in MapServer (and Mapnik etc.). Tools like > osm2pgsql and imposm do set those values[2]. > > Now I realize that I could go through the osm2pgsql/imposm code and set > those myself manually somehow, once I figure out the exact logic used by > those tools, but, I am wondering if this could be added to the OGR/OSM > driver itself, as it is so useful for many mapping projects (?). > > Call this a wishlist email then, but I just thought I'd file the request :)
Hi Jeff, Imposm and osm2pgsql utilities are more or less made to one purpose that is to generate database for rendering with more or less standard styles and therefore they can have fixes rules for creating z_orders. I am not sure if the GDAL OSM driver has such a strong same-for-all use case. I would make a little test first: - add column "z_order" - create indexes for highway, tunnel, and bridge which is probably a good idea anyway (consider also the other fields used in SELECTs during rendering time) - udpdate z_order by your rules with CASE...WHEN...THEN...ELSE it should be one or a couple SQL statements and thus fast. http://www.sqlite.org/lang_expr.html speaks about short-circuit which may mean that the indexes above are not even needed for making populating z_order faster but at rendering time they are anyway good to have - create index for z_order All the SQL post-process commands can be run with GDAL as well from a script as ogrinfo commands with -sql parameter. If you still aim to something better, create also simplified geometries for the most heavy geometries and save them as additional geometry fields which saves space because there is no need to copy the attributes. A few more lines of SQL will be needed for creating spatial indexes and adding new geometries into geometry_columns. Finally you just need to publish the rendering rules (mapfile I guess), osmconf.ini and post-process SQL all together and you should have an easily deliverable package with optimized data access which you probably would like to name as "MS4OSM". I volunteer to test the package. Actually I have done some tests myself but been too lazy for putting everything together into a single executable script. -Jukka Rahkonen- _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
