Glad you guys highlighted this as I was going to follow up. Using expressions to calculate and render the stylization makes it difficult without walking the data to know what needs to be rendered and as was pointed out, you can't really do this on large datasets. Secondly if we were to apply this logic to features then their labels likely have to be included and that just makes for more processing overhead.
One somewhat workable solution might be to provide a LAYER SPECIFIC "extent buffer" or "overpost" (as Craig mentioned), that the author can specify on the layer definition or maybe the map (I'm not sure which is the best place for it from a server processing perspective). This value would actually query x% more than the current map extent so as to include features outside the visible area. Not a perfect solution, but if you know your stylization bounds you can probably get most of your desired features to appear. Alternately the buffer could be a value representing how many extra tile rows around the visible map extent to query and render instead of a percent (I like this better because at low scale values the percentages would be less accurate). Because this is layer specific you'd end up only setting it on 1 or 2 layers so that the whole map doesn't take the extra performance hit of returning unnecessary data. I don't see this as an ideal solution, but sufficient in most cases. A user could come up with some really large values for the use case presented and again if an expression is used there may be odd data points this doesn't cover properly. Any thoughts on this? Maybe there is a better technical solution I'm not seeing. Dave -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Jason Birch Sent: Tuesday, February 16, 2010 6:18 PM To: MapGuide Users Mail List Subject: Re: [mapguide-users] Is their a major flaw with theming point data? That might be tough to support properly given the complexity of the stylization, especially because they can scale, be offset, etc based on attributes. Basically, you're stuck in a chicken/egg situation where you need the data to calculate the symbol MBRs to figure out how much data to request :) Jason On 2010-02-16, Miller, Craig <[email protected]> wrote: > With the points, you could only fetch an over-post if there is a point layer > that has a large symbol. You could use the radius of the symbol to > determine how much additional area to fetch. You'd need MBRs for every > possible symbol to be rendered before setting the map window MBR and > fetching data. > > Craig > On Tue, Feb 16, 2010 at 2:37 PM, Jason Birch <[email protected]> wrote: > >> How would you handle this James? >> >> The spatial intersection that MapGuide performs with the current >> viewport's >> extents is critical to performance when you are dealing with large amounts >> of data, and many of the FDO data sources are optimized using R-Tree (or >> similar) indices to return only the data which is currently in view. >> >> I guess you could conceivably fetch an over-post of the current extents by >> some factor, but that would only work for a subset of point symbols (those >> where the maximum dimensions of the theming is < half the expanded extent >> dimension, and it would mean that everyone has to live with the decreased >> performance of the over-fetch. >> >> A few options: >> - Make the over-fetch percentage or distance configurable per server, per >> map, or per-layer >> - Only apply the over-fetch to points (there are actually cases where the >> same problem happens with lines and polygons, so I don't think this is >> valid) >> >> I personally feel that the current behaviour is generally OK, but there >> are >> definitely cases where you wouldn't want features missed just because >> their >> mid-point isn't in the current view extents. >> >> Regardless of the solution, I think this would take some work, so might >> require some funding or somehow making it important to one of the >> developers. >> >> Jason >> >> >> On 16 February 2010 12:06, JamesDudden wrote: >> >>> I understand how it happens and it does make sense but it renders the >>> theming of points useless if they are going to be anything larger than a >>> few >>> pixels. >>> >>> I think it would be good to see future versions of Mapguide become more >>> intelligent and be able to cope with theming of points. >>> >>> >> _______________________________________________ >> mapguide-users mailing list >> [email protected] >> http://lists.osgeo.org/mailman/listinfo/mapguide-users >> >> > > > -- > Craig Miller > Geospatial Software Architect > _______________________________________________ mapguide-users mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/mapguide-users _______________________________________________ mapguide-users mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/mapguide-users
