On Thu, 2010-06-10 at 10:56 -0700, Dane Springmeyer wrote: > 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" >
I was originally thinking of using a Parameter for consistency with the other extent settings: <Parameter name="extent">world</Parameter> <Parameter name="global_extent">true</Parameter> > > > > > > > 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.... The case I have seen where we could hit this is for something like SRTM or raster data where there could be hundreds of layers, each one covering a 1x1 degree tile. On the other hand, I would expect any well indexed datasource to be able to determine that there is no data within the requested bbox with fairly little effort. > > -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
