On 2014-11-06 6:48 PM, Jukka Rahkonen wrote:
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-
Hi Jukka,
I think you are saying what I was thinking (but trying to avoid):
modifying my osm2pgsql-to-imposm-schema.sql script[1] to something like
"ogr-to-imposm-schema-script.sql". I already started that but got stuck
at the z_order calculation. But before traveling down that path I
thought I'd see if others were interested in having that calculation
directly in the OSM driver, since it is so useful to many mapping
projects. It was just a thought.
I agree with your general plan, although I find it easier to just modify
the existing schema script (once we figure out the logic used by
osm2pgsql/imposm used for z_order).
[1]
https://github.com/mapserver/basemaps/blob/master/contrib/osm2pgsql-to-imposm-schema.sql
-jeff
--
Jeff McKenna
MapServer Consulting and Training Services
http://www.gatewaygeomatics.com/
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
