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.
I'm wondering if perhaps I have a problem with my postgis/osm
database, or perhaps I'm just not understanding the meaning of these
options. To test my osm setup I tried to replicate the query that
would be created on line 310 as:
select xmin(ext),ymin(ext),xmax(ext),ymax(ext) from (select
extent(way) as ext from planet_osm_polygon) as tmp;
xmin | ymin | xmax | ymax
-----------+-----------+-----------+---------
-13878167 | 5708620.5 | -13450855 | 6275076
(1 row)
which shows the correct output in google mercator.
So, does anyone have any idea how it is possible that in the mapnik
debug I am getting this line?
setSRID('BOX3D(-122.2381318249312
0.9837931753848186,-2.175896660733377 47.67119999999999)'::box3d,900913)
Thanks for any thoughts,
Dane
select xmin(ext),ymin(ext),xmax(ext),ymax(ext) from (select
extent(way) as ext from planet_osm_line) as tmp;
and running into cases where the datasource will return no features
unless I'm careful.
_______________________________________________
Mapnik-users mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/mapnik-users
