Jon, Mike (inline)
On Jun 4, 2010, at 1:21 PM, Michal Migurski wrote: > On Jun 4, 2010, at 11:16 AM, Jon Burgess wrote: > >> On Fri, 2010-06-04 at 08:50 -0700, Dane Springmeyer wrote: >>> I've been wondering if we need to switch to clipping (the extents used >>> to determine layer intersection in feature_style_processor.cpp) by map >>> extent (rather than layer extent), while adding the ability to >>> manually set the MAX_EXTENT in the <Map /> section of an xml (in the >>> target projection). This method would open the door to bogus (and >>> unprojectedable) extents being passed to proj4 based on the map bbox, >>> but hopefully most situations could be prevented using a MAX_EXTENT >>> variable, which could be auto-calculated from each layer if not set >>> (http://trac.mapnik.org/ticket/506). >>> >> >> I have been thinking about a different solution. If there was some way >> to mark the layer extent as 'all' or 'world', then the stage which >> projects the layer extent to the target srs & applies the clipping could >> be skipped entirely. This would be simple to implement and should avoid >> all these issues. Yes, that seems like a good idea for truly global data, and if I understand right could complement any other solution. Even for regional data (that might present the same problems with unique local projections) this could work by simply skipping the error-prone intersection check. How best to expose to users? <Layer name="osm" srs="merc...." global_extent="true" > <Layer name="osm" srs="merc...." check_intersection="false" > <Layer name="osm" srs="merc...." hit_test="false" > > > > What is the default behavior of Mapnik here? Not sure exactly which piece you are asking about, but generally.... When deciding whether to skip or process a layer (send a bounds query to the datasource), Mapnik checks intersection of the layer with the map. Hence, all datasources report (and must calculate at initialization) their bounding box in the layers projection. And when the map projection differs we use Proj4 to transform coordinates of the layer into the map's projection (to check intersection), which is where things can first go wrong if proj4 is unable to make that translation. > > I've repeatedly run into extent/estimate_extent issues, most recently > yesterday. I've managed to develop the right calluses around this stuff, but > I find myself explaining it as magic to other users. I hear you, at least I know situations where I've been confused with behavior from PostGIS in relation to those settings. One is due to a bug I recently fixed: http://trac.mapnik.org/changeset/1720 Basically, you had to send estimate_extent="true" in Python to get that parameter to take effect (while estimate_extent=True did not work as you would think). This should not have presented any issues from XML. Another is that if your sql query limits records, then the extents will be wrong (not applicable), unless fetched dynamically from the sub-set of records. But this is potentially expensive, so it is an option you have to turn on: "extent_from_subquery=true or false". If true, and you've not provided the 'extent' parameter manually, then this will dynamically fetch the right extents for the layer, intelligent to the query. I'm sorry these are not documented on the wiki, I need to do this. Now, keep in mind that if we implement the ability to turn on assumed world-based extents of a layer, then all this stuff would be skipped, and the complexities would fall away. The tradeoff being that no matter what, a query will be send to a layer, even if it is unlikely to return any data, and time would be incurred for this hit on the datasource. > It seems useful for Mapnik to assume "world" in most if not all cases. > Just could be expensive for sparse data.... > -mike. > > ---------------------------------------------------------------- > michal migurski- [email protected] > 415.558.1610 > > > > _______________________________________________ > Mapnik-users mailing list > [email protected] > https://lists.berlios.de/mailman/listinfo/mapnik-users _______________________________________________ Mapnik-users mailing list [email protected] https://lists.berlios.de/mailman/listinfo/mapnik-users
