Updated OptimizeRenderingWithPostGIS (markdown)

Pete 2016-06-28 16:26:09 +01:00
parent 7d2a9e95cc
commit d015bd575d

@ -214,7 +214,7 @@ If there is any active connection Postgresql will wait until it is closed, so if
## Use an extent parameter
If an extent parameter is not set, mapnik will perform a query like this...
```
```sql
SELECT ST_XMin(ext),ST_YMin(ext),ST_XMax(ext),ST_YMax(ext)
FROM (SELECT ST_Extent(geom) as ext from planet_osm_line) as tmp
```
@ -222,7 +222,10 @@ FROM (SELECT ST_Extent(geom) as ext from planet_osm_line) as tmp
...which requires PostGIS to walk the entire result set of the queried table each time the DataSource is used for the first time in a rendering session. There are three parameters available for use to avoid this process:
### extent_from_subquery
E.g. `<Parameter name="extent_from_subquery">true</Parameter>`
E.g.
```xml
<Parameter name="extent_from_subquery">true</Parameter>
```
**Pros:**
* Precise estimate of extent
@ -239,7 +242,10 @@ E.g. `<Parameter name="extent_from_subquery">true</Parameter>`
* tile server where render requests return small features sets or any render requests with large feature sets are pre-rendered and cached
### extent
E.g. `<Parameter name="extent">-20037508,-19929239,20037508,19929239</Parameter>`
E.g.
```xml
<Parameter name="extent">-20037508,-19929239,20037508,19929239</Parameter>
```
**Pros:**
* No database overhead
@ -259,7 +265,10 @@ E.g. `<Parameter name="extent">-20037508,-19929239,20037508,19929239</Parameter>
* Seldom changing result set with few updates
### estimate_extent
E.g. `<Parameter name="estimate_extent">true</Parameter>`
E.g.
```xml
<Parameter name="estimate_extent">true</Parameter>
```xml
**Pros:**
* Faster than not setting any extent parameters; significantly for large result sets