[mapguide-users] RE: Is their a major flaw with theming point data?
With "old" MapGuide there was a fantastic option to be able to 1) turn off spatial filtering for a layer - ie ignore the current map window BBOX (OK, that wasn't that fantastic but the next variant was) 2) define your own spatial filter using special %XMIN, %XMAX variables in a query builder that allowed - on a per layer basis - a custom filter to be applied. Now that would be nice! -- View this message in context: http://n2.nabble.com/Is-their-a-major-flaw-with-theming-point-data-tp4580895p4588530.html Sent from the MapGuide Users mailing list archive at Nabble.com. ___ mapguide-users mailing list mapguide-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapguide-users
Re: [mapguide-users] RE: Is their a major flaw with theming point data?
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 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 > mapguide-users@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/mapguide-users > > -- Craig Miller Geospatial Software Architect ___ mapguide-users mailing list mapguide-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapguide-users
Re: [mapguide-users] RE: Is their a major flaw with theming point data?
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 mapguide-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapguide-users
[mapguide-users] RE: Is their a major flaw with theming point data?
Dave Wilson wrote: > > ...I wouldn't call this a bug. I think the workaround is to create > circular polygons. > 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. - http://www.software-matters.co.uk Software Matters - http://www.software-matters.co.uk/bespoke-database-design.html Bespoke Database and Software Solutions -- View this message in context: http://n2.nabble.com/Is-their-a-major-flaw-with-theming-point-data-tp4580895p4582316.html Sent from the MapGuide Users mailing list archive at Nabble.com. ___ mapguide-users mailing list mapguide-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapguide-users
