[mapguide-internals] MapGuide RFC 69 - Rendering Layer Styles
Scott Hameister
scotth at mpowerinnovations.com
Mon Jun 29 11:33:49 EDT 2009
That’s What I was trying to ask is why Its iterating one item at a time and not bulk querying for themes...
I understand that moving a theme rule to the top means that if that rule is met do not continue to another rule...and if we render in Rules order everything would get rendered reverse order "first rule rendered on bottom"...also a problem could have been that it was programmed so that an object couldn’t match more than one rule...Was that the case? Anyone? Too many objects to keep track of if we say an object can only match one rule?
Honestly I would rather have that be the case, have it faster and be forced to tidy up my Theme Rules than have no control over render order or labeling in a theme....Id rather have it that rules and Draw order are opposite and clean up my rules than have zero control.
This would fix Priority on themeing things like road networks, so Major Interstates, highways etc, would render and label over local roads etc.
Now if some one would just get into Studio and Maestro a simple HWY shield creator instead of forcing XML editing. I know not all maps have road networks in them, but I would guess the majority do....Having capabilities is fine, having usability is another...Id rather Teach an everyday gov't GIS person, with no programming abilities, how to read hieroglyphs than how to edit, Upload, and decipher errors in the stylization XML...Just my two cents
-----Original Message-----
From: mapguide-internals-bounces at lists.osgeo.org [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Martin Morrison
Sent: Monday, June 29, 2009 7:28 AM
To: MapGuide Internals Mail List
Subject: RE: [mapguide-internals] MapGuide RFC 69 - Rendering Layer Styles
This scenario is one that I struggled with at first. Then I hit the answer of using several layers in a group running against the same MS-SQL database. Each layer had a filter applied and only one style. I could display the several layers almost twice as fast I could theme a single layer. Two things happened to gain the speed, the first was the select statement queried the features in bulk rather than eval one feature at a time. The second was even though the SQL server was running on the same server, the processing of the query was off-loaded to a different process.
I would like to see the FDO providers select the groups of similar features and theme the whole group rather than evaluating one at a time.
Martin
-----Original Message-----
From: mapguide-internals-bounces at lists.osgeo.org [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of scotth at mpowerinnovations.com
Sent: Friday, June 26, 2009 6:05 PM
To: Walt Welton-Lair; MapGuide Internals Mail List
Subject: RE: [mapguide-internals] MapGuide RFC 69 - Rendering Layer Styles
Sorry accidently hit send...this is even more efficient if we assume once an objects stylized we no longer query it.
-----Original Message-----
From: Walt Welton-Lair <walt.welton-lair at autodesk.com>
Sent: Friday, June 26, 2009 3:48 PM
To: MapGuide Internals Mail List <mapguide-internals at lists.osgeo.org>
Subject: RE: [mapguide-internals] MapGuide RFC 69 - Rendering Layer Styles
100 soil types = 100 rules = 100 different filters
For each layer MapGuide does the following in the normal case:
for each feature F in layer data set (1 FDO query)
{
for each rule R in layer theme
{
evaluate filter for R against F
if success
{
apply style from rule R to feature F
break; // move to next feature
}
}
}
So yes, worst case scenario is 10000 x 100 filter evaluations for your example layer.
The actual code which does this is https://trac.osgeo.org/mapguide/browser/trunk/MgDev/Common/Stylization/DefaultStylizer.cpp.
* DefaultStylizer::StylizeVLHelper does the iteration over features (line 289)
* inside the call to adapter->Stylize (line 333) is where the iteration over the rules happens
* for example, see https://trac.osgeo.org/mapguide/browser/trunk/MgDev/Common/Stylization/PolylineAdapter.cpp
* PolylineAdapter::Stylize (line 79) is the loop over the rules
The inverse which makes draw order match rule order is:
for each rule R in layer theme
{
for each feature F in layer data set filtered against R (1 FDO query)
{
apply style from R to feature F
}
}
but this results in 100 FDO queries. Imagine an Oracle data source....
-----Original Message-----
From: scotth at mpowerinnovations.com [mailto:scotth at mpowerinnovations.com]
Sent: Friday, June 26, 2009 12:02 PM
To: Walt Welton-Lair; MapGuide Internals Mail List
Subject: RE: [mapguide-internals] MapGuide RFC 69 - Rendering Layer Styles
using Style Order
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Help me understand...
Lets say I have 10,000 soil polygons and 100 soil types to theme..how is mapguide handling this?
Does it iterate one geometry object at a time...send itself to the filter possibly 100 times until it finds a match then stylize itself...then move on to the next geometry objct and do this 9,999 more times? With a possible of 100 x 10,000 loops?
Or does it iterate through the rules as a filter and query the full geometry 100 times to stylize en masse? Which I would assume be more efficient..if it were doing this wouldnt we expect the objects to be rendered in reverse order Top theme rendered to the bottom? In the case of my roads...moving Interstates to the top or bottom doesnt seem to matter for labeling...
-----Original Message-----
From: Walt Welton-Lair <walt.welton-lair at autodesk.com>
Sent: Friday, June 26, 2009 9:39 AM
To: MapGuide Internals Mail List <mapguide-internals at lists.osgeo.org>
Subject: RE: [mapguide-internals] MapGuide RFC 69 - Rendering Layer Styles
using Style Order
They either split things up into multiple layers, as you say, or they use the rendering pass behavior in the enhanced stylization (currently no UI for the latter, so that complicates that one). Both will have similar performance impact as what's proposed in the RFC - both end up making the same number of FDO queries. And if you read ticket 618 referenced by the RFC, the number of queries is a concern.
I would love to see MapGuide be able to support this behavior. But without a good / novel approach for doing this the performance impact will be atrocious. There are customers who have themed layers with 100's of rules, and changing the default stylization behavior to have draw order match rule order will not work for those maps performance-wise. I think at minimum the RFC will need to be updated to make this behavior optional (default is off). And that means a layer definition schema change.
-----Original Message-----
From: mapguide-internals-bounces at lists.osgeo.org [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Paul Spencer
Sent: Friday, June 26, 2009 9:18 AM
To: MapGuide Internals Mail List
Subject: Re: [mapguide-internals] MapGuide RFC 69 - Rendering Layer Styles using Style Order
How would someone achieve the desired effect now? From what I understand (and I am not a power user of mapguide by any standard of measurement), you would need to create several layer definitions each with a filter and theme those layers for each road class?
how would performance for:
- for each rule, construct an FDO query filtered by the rule's condition
- render all features using the rule's style
differ from having separate layers?
Yours confusedly ;)
Paul
On 25-Jun-09, at 11:06 PM, Walt Welton-Lair wrote:
> "Can some elaborate on how the server currently handles this?"
> Handles what?
>
> The current code iterates once over the features (ignore the compound
> line style example). For every feature it evaluates the filters
> defined by the rules (in the order that the rules are specified).
> Once it finds a matching rule it applies its style to the feature.
>
> With compound line styles we make a pass over all the features for
> each line style. So for a compound line style containing M styles we
> make M FDO queries.
>
> With rendering passes (RFC 29) we also iterate over all the layer's
> features for each rendering pass. The more passes you define the more
> queries you make.
>
> How to implement your RFC?
>
> option 1
> - Make a pass over the features for each rule.
> - During each pass only render the features that satisfy the rule for
> that pass.
> - If there are M rules you will make M FDO queries.
> => performance (speed) will be unacceptable for anything more than a
> few themes
>
> option 2
> - Make one query against all the features, remembering (in memory?)
> all the feature information (attributes / geometry) needed by
> stylization.
> - During the initial pass render the features for the first rule.
> - Iterate over the remaining rules in order, rendering the features
> for each rule.
> => performance (memory use) will be unacceptable for data sources
> containing large numbers of features => this approach goes against the
> MG architecture of not keeping feature data in memory during
> stylization (we already break that rule with labels which is what
> leads to high memory usage spikes for some maps)
>
> option 3
> - Allocate one image per rule.
> - Make one query against all the features, and render each feature
> into the image corresponding to the rule it satisifes.
> - Merge all images at the end.
> => performance (speed + memory) will be unacceptable for anything more
> than a few themes
>
> option 4
> ???
>
>
> ________________________________________
> From: mapguide-internals-bounces at lists.osgeo.org
> [mapguide-internals-bounces at lists.osgeo.org
> ] On Behalf Of Zac Spitzer [zac.spitzer at gmail.com]
> Sent: Thursday, June 25, 2009 10:36 PM
> To: MapGuide Internals Mail List
> Subject: Re: [mapguide-internals] MapGuide RFC 69 - Rendering Layer
> Styles using Style Order
>
> At the moment the only way to achieve this is to split the road
> network out into multiple layers which is rather ugly.
>
> Taking a road network as the example here, it's only at the
> intersections where this problem occurs.
>
> Can some elaborate on how the server currently handles this?
>
> z
>
> On Fri, Jun 26, 2009 at 12:28 PM, Walt
> Welton-Lair<walt.welton-lair at autodesk.com> wrote:
>> "Proposed solution: Add support to the rendering engine to render
>> layer styles in ordered passes."
>>
>> I'd like to see some concrete suggestions in the RFC on how to
>> actually do this efficiently. Just consider a conservative use case
>> - say around 10 rules.
>>
>> Walt
>> ________________________________________
>> From: mapguide-internals-bounces at lists.osgeo.org
>> [mapguide-internals-bounces at lists.osgeo.org
>> ] On Behalf Of Zac Spitzer [zac.spitzer at gmail.com]
>> Sent: Thursday, June 25, 2009 9:29 PM
>> To: MapGuide Internals Mail List
>> Subject: [mapguide-internals] MapGuide RFC 69 - Rendering Layer
>> Styles using Style Order
>>
>> I have posted a new RFC
>>
>> http://trac.osgeo.org/mapguide/wiki/MapGuideRfc69
>>
>> --
>> Zac Spitzer -
>> http://zacster.blogspot.com
>> +61 405 847 168
>> _______________________________________________
>> mapguide-internals mailing list
>> mapguide-internals at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>> _______________________________________________
>> mapguide-internals mailing list
>> mapguide-internals at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>>
>
>
>
> --
> Zac Spitzer -
> http://zacster.blogspot.com
> +61 405 847 168
> _______________________________________________
> mapguide-internals mailing list
> mapguide-internals at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
> _______________________________________________
> mapguide-internals mailing list
> mapguide-internals at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
__________________________________________
Paul Spencer
Chief Technology Officer
DM Solutions Group Inc
http://research.dmsolutions.ca/
_______________________________________________
mapguide-internals mailing list
mapguide-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapguide-internals
_______________________________________________
mapguide-internals mailing list
mapguide-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapguide-internals
_______________________________________________
mapguide-internals mailing list
mapguide-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapguide-internals
_______________________________________________
mapguide-internals mailing list
mapguide-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapguide-internals
More information about the mapguide-internals
mailing list