On Wed, 2008-10-08 at 14:40 -0700, Dane Springmeyer wrote:
> Hi,
>
> I've been trying to more fully understand the various postgis plugin
> options, and I'm hoping someone can clarify the best practices and
> tradeoffs of various usages.
>
> I'm sure I'm confusing something here, so anyone feel free to correct
> me.
>
> It's clear that something like this (found in the OSM stylesheet)
> works fine:
>
> <Parameter name="table">(select * from planet_osm_polygon order
> by z_order,way_area desc) as leisure</Parameter>
> <Parameter name="estimate_extent">false</Parameter>
> <Parameter name="extent">-20037508,-19929239,20037508,19929239</
> Parameter>
>
> where the features (in projected coordinates inside a projected layer)
> returned are sure to fall within the manually specified extent. And
> this should be fast since we are not requiring mapnik's postgis plugin
> to generate a temporary table of extents, like I see happens here:
>
> http://trac.mapnik.org/browser/trunk/plugins/input/postgis/postgis.cpp#L287
>
> I've also noticed that if you use a query within the table parameter
> that radically alters the extents of the original table, one must use
> the above approach to manually set the extents otherwise the
> automatically estimated extents will not match the new extents of the
> dynamic geometries, as I noted here:
>
> http://trac.mapnik.org/wiki/PostGIS#XML
>
> But here's where I am confused: When loading OSM data in EPSG
> 900913( Google Mercator) and using this configuration:
>
> <Layer class="citylike area" srs="+proj=merc +a=6378137
> +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m
> [EMAIL PROTECTED] +no_defs +over">
> <Datasource>
> <Parameter name="type">postgis</Parameter>
> <Parameter name="host">127.0.0.1</Parameter>
> <Parameter name="port">5432</Parameter>
> <Parameter name="user">postgres</Parameter>
> <Parameter name="password"></Parameter>
> <Parameter name="dbname">gis</Parameter>
> <Parameter name="estimate_extent">false</Parameter>
> <Parameter name="table">(SELECT * FROM planet_osm_polygon
> WHERE landuse IN ('reservoir', 'water') OR "natural" IN ('lake',
> 'water', 'land') ORDER BY z_order ASC) AS water</Parameter>
> </Datasource>
> </Layer>
>
> ...without setting the extent manually, I figure that the extents
> would be calculated without the 'estimated' approach. However, while I
> assume approach on line 310 is being used here:
>
> http://trac.mapnik.org/browser/trunk/plugins/input/postgis/postgis.cpp#L310
>
> in the mapnik debug output I get:
>
> select asbinary(way) as geom,"name","size" from (SELECT *, (CASE WHEN
> round(way_area * 1000000) >= 20 THEN 'large' WHEN round(way_area *
> 1000000) >= 1 THEN 'medium' ELSE 'small' END) AS size FROM
> planet_osm_polygon WHERE building IS NOT NULL ORDER BY z_order ASC,
> way_area DESC) AS citylike where way &&
> setSRID('BOX3D(-122.2381318249312
> 0.9837931753848186,-2.175896660733377 47.67119999999999)'::box3d,
> 900913);
>
> This is obviously problematic and will not return any features because
> the BOX3D is using geographical coordinates but setting the SRID to
> 900913.
That query could not be generated from the 'layer' definition that you
posted, the select queries are too different. Which layer definitions do
you have which mention 'AS citylike' in the "table" parameter? My guess
is that other layer has the wrong SRS.
The main reason for using a fixed extent is that the estimated_extent
has been observed to have significant errors. You need to perform a
'VACUUM ANALYZE' to force the estimated extent to be updated after
loading new data and even then it is not accurate enough for Mapnik.
Calculating the true extent involves a full table scan which incurs a
considerable startup penalty.
Jon
_______________________________________________
Mapnik-users mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/mapnik-users
