[prev in list] [next in list] [prev in thread] [next in thread]
List: mapguide-internals
Subject: RE: [mapguide-internals] MapGuide RFC 69 - Rendering Layer Styles
From: "Scott Hameister" <scotth () mpowerinnovations ! com>
Date: 2009-06-29 15:33:49
Message-ID: 006401c9f8ce$fffbe720$fff3b560$ () com
[Download RAW message or body]
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@lists.osgeo.org \
[mailto:mapguide-internals-bounces@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@lists.osgeo.org \
[mailto:mapguide-internals-bounces@lists.osgeo.org] On Behalf Of \
scotth@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@autodesk.com>
Sent: Friday, June 26, 2009 3:48 PM
To: MapGuide Internals Mail List <mapguide-internals@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@mpowerinnovations.com [mailto:scotth@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@autodesk.com>
Sent: Friday, June 26, 2009 9:39 AM
To: MapGuide Internals Mail List <mapguide-internals@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@lists.osgeo.org \
[mailto:mapguide-internals-bounces@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@lists.osgeo.org
> [mapguide-internals-bounces@lists.osgeo.org
> ] On Behalf Of Zac Spitzer [zac.spitzer@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@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@lists.osgeo.org
> > [mapguide-internals-bounces@lists.osgeo.org
> > ] On Behalf Of Zac Spitzer [zac.spitzer@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@lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/mapguide-internals
> > _______________________________________________
> > mapguide-internals mailing list
> > mapguide-internals@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@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
> _______________________________________________
> mapguide-internals mailing list
> mapguide-internals@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@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapguide-internals
_______________________________________________
mapguide-internals mailing list
mapguide-internals@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapguide-internals
_______________________________________________
mapguide-internals mailing list
mapguide-internals@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapguide-internals
_______________________________________________
mapguide-internals mailing list
mapguide-internals@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapguide-internals
_______________________________________________
mapguide-internals mailing list
mapguide-internals@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapguide-internals
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic