|
|
|
Flipper
|
using Style Order
MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Welt That was confusing...Are you saying if I put complex linestyles on highways and labels but leave local roads simplex thats why the local road labels render before myy complex linestyle roads no matter how far up I promote thhem in thhhe theme...I have the same problem with polygons...If I move townships, villages, or cities to the top of my theme of muniipalities it seems to have no effect onlabeling priority at all...it seems almost random -----Original Message----- From: Walt Welton-Lair <[hidden email]> Sent: Thursday, June 25, 2009 10:07 PM To: MapGuide Internals Mail List <[hidden email]> Subject: RE: [mapguide-internals] MapGuide RFC 69 - Rendering Layer Styles using Style Order "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: [hidden email] [[hidden email]] On Behalf Of Zac Spitzer [[hidden email]] 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<[hidden email]> 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: [hidden email] [[hidden email]] On Behalf Of Zac Spitzer [[hidden email]] > 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 > [hidden email] > http://lists.osgeo.org/mailman/listinfo/mapguide-internals > _______________________________________________ > mapguide-internals mailing list > [hidden email] > http://lists.osgeo.org/mailman/listinfo/mapguide-internals > -- Zac Spitzer - http://zacster.blogspot.com +61 405 847 168 _______________________________________________ mapguide-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/mapguide-internals _______________________________________________ mapguide-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/mapguide-internals _______________________________________________ mapguide-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/mapguide-internals |
||||||||||||||||
|
Walt Welton-Lair
|
In MapGuide the order of the rules has no influence at all on the feature rendering order or the label rendering order. Features are processed in the order that FDO returns them. If a feature corresponding to a local road is returned by FDO before a feature corresponding to a highway, then the local road gets rendered first - below the highway.
Labels are processed in reverse order. As we iterate over the features for all layers we build up a list of candidate labels. Feature 1 on layer 1 adds its candidate labels, then feature 2 on layer 1, ... Once all features on all visible layers have been processed we do the final processing of labels. We iterate over the list of candidate labels in reverse order - top down in rndering order. The last feature on the topmost layer has the first crack at displaying its labels. Then the next-to-last feature on the topmost layer, and eventually you move to the next lower layer. This is the way MapGuide has worked since the very beginning (pre-MapGuide 6.5). I'm going to bed... ________________________________________ From: [hidden email] [[hidden email]] Sent: Thursday, June 25, 2009 11:29 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 Welt That was confusing...Are you saying if I put complex linestyles on highways and labels but leave local roads simplex thats why the local road labels render before myy complex linestyle roads no matter how far up I promote thhem in thhhe theme...I have the same problem with polygons...If I move townships, villages, or cities to the top of my theme of muniipalities it seems to have no effect onlabeling priority at all...it seems almost random -----Original Message----- From: Walt Welton-Lair <[hidden email]> Sent: Thursday, June 25, 2009 10:07 PM To: MapGuide Internals Mail List <[hidden email]> Subject: RE: [mapguide-internals] MapGuide RFC 69 - Rendering Layer Styles using Style Order "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: [hidden email] [[hidden email]] On Behalf Of Zac Spitzer [[hidden email]] 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<[hidden email]> 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: [hidden email] [[hidden email]] On Behalf Of Zac Spitzer [[hidden email]] > 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 > [hidden email] > http://lists.osgeo.org/mailman/listinfo/mapguide-internals > _______________________________________________ > mapguide-internals mailing list > [hidden email] > http://lists.osgeo.org/mailman/listinfo/mapguide-internals > -- Zac Spitzer - http://zacster.blogspot.com +61 405 847 168 _______________________________________________ mapguide-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/mapguide-internals _______________________________________________ mapguide-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/mapguide-internals _______________________________________________ mapguide-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/mapguide-internals |
||||||||||||||||
|
zspitzer
|
So based on that, if FDO supported ordering both issues, that being
Scott's label problem and the overlay of roads might be solved? http://trac.osgeo.org/fdo/ticket/516 would that be more efficient than respecting the layer style order and would also allow complex overriding of the rendering order simply by manipulating the column used for order by? z On Fri, Jun 26, 2009 at 1:42 PM, Walt Welton-Lair<[hidden email]> wrote: > In MapGuide the order of the rules has no influence at all on the feature rendering order or the label rendering order. Features are processed in the order that FDO returns them. If a feature corresponding to a local road is returned by FDO before a feature corresponding to a highway, then the local road gets rendered first - below the highway. > > Labels are processed in reverse order. As we iterate over the features for all layers we build up a list of candidate labels. Feature 1 on layer 1 adds its candidate labels, then feature 2 on layer 1, ... Once all features on all visible layers have been processed we do the final processing of labels. We iterate over the list of candidate labels in reverse order - top down in rndering order. The last feature on the topmost layer has the first crack at displaying its labels. Then the next-to-last feature on the topmost layer, and eventually you move to the next lower layer. > > This is the way MapGuide has worked since the very beginning (pre-MapGuide 6.5). > > > I'm going to bed... > > ________________________________________ > From: [hidden email] [[hidden email]] > Sent: Thursday, June 25, 2009 11:29 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 > > Welt That was confusing...Are you saying if I put complex linestyles on highways and labels but leave local roads simplex thats why the local road labels render before myy complex linestyle roads no matter how far up I promote thhem in thhhe theme...I have the same problem with polygons...If I move townships, villages, or cities to the top of my theme of muniipalities it seems to have no effect onlabeling priority at all...it seems almost random > > -----Original Message----- > From: Walt Welton-Lair <[hidden email]> > Sent: Thursday, June 25, 2009 10:07 PM > To: MapGuide Internals Mail List <[hidden email]> > Subject: RE: [mapguide-internals] MapGuide RFC 69 - Rendering Layer Styles > using Style Order > > "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: [hidden email] [[hidden email]] On Behalf Of Zac Spitzer [[hidden email]] > 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<[hidden email]> 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: [hidden email] [[hidden email]] On Behalf Of Zac Spitzer [[hidden email]] >> 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 >> [hidden email] >> http://lists.osgeo.org/mailman/listinfo/mapguide-internals >> _______________________________________________ >> mapguide-internals mailing list >> [hidden email] >> http://lists.osgeo.org/mailman/listinfo/mapguide-internals >> > > > > -- > Zac Spitzer - > http://zacster.blogspot.com > +61 405 847 168 > _______________________________________________ > mapguide-internals mailing list > [hidden email] > http://lists.osgeo.org/mailman/listinfo/mapguide-internals > _______________________________________________ > mapguide-internals mailing list > [hidden email] > http://lists.osgeo.org/mailman/listinfo/mapguide-internals > > _______________________________________________ > mapguide-internals mailing list > [hidden email] > http://lists.osgeo.org/mailman/listinfo/mapguide-internals > -- Zac Spitzer - http://zacster.blogspot.com +61 405 847 168 _______________________________________________ mapguide-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/mapguide-internals |
||||||||||||||||
|
Flipper
|
In reply to this post
by Flipper
Thats really backwards...since the catch all of default should be the last rule processed..and is for themes...it soud also be the lowest level geometry and label rendered as well...what kind of speed issues would this entail?
-----Original Message----- From: Walt Welton-Lair <[hidden email]> Sent: Thursday, June 25, 2009 10:42 PM To: MapGuide Internals Mail List <[hidden email]> Subject: RE: [mapguide-internals] MapGuide RFC 69 - Rendering Layer Styles In MapGuide the order of the rules has no influence at all on the feature rendering order or the label rendering order. Features are processed in the order that FDO returns them. If a feature corresponding to a local road is returned by FDO before a feature corresponding to a highway, then the local road gets rendered first - below the highway. Labels are processed in reverse order. As we iterate over the features for all layers we build up a list of candidate labels. Feature 1 on layer 1 adds its candidate labels, then feature 2 on layer 1, ... Once all features on all visible layers have been processed we do the final processing of labels. We iterate over the list of candidate labels in reverse order - top down in rndering order. The last feature on the topmost layer has the first crack at displaying its labels. Then the next-to-last feature on the topmost layer, and eventually you move to the next lower layer. This is the way MapGuide has worked since the very beginning (pre-MapGuide 6.5). I'm going to bed... ________________________________________ From: [hidden email] [[hidden email]] Sent: Thursday, June 25, 2009 11:29 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 Welt That was confusing...Are you saying if I put complex linestyles on highways and labels but leave local roads simplex thats why the local road labels render before myy complex linestyle roads no matter how far up I promote thhem in thhhe theme...I have the same problem with polygons...If I move townships, villages, or cities to the top of my theme of muniipalities it seems to have no effect onlabeling priority at all...it seems almost random -----Original Message----- From: Walt Welton-Lair <[hidden email]> Sent: Thursday, June 25, 2009 10:07 PM To: MapGuide Internals Mail List <[hidden email]> Subject: RE: [mapguide-internals] MapGuide RFC 69 - Rendering Layer Styles using Style Order "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: [hidden email] [[hidden email]] On Behalf Of Zac Spitzer [[hidden email]] 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<[hidden email]> 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: [hidden email] [[hidden email]] On Behalf Of Zac Spitzer [[hidden email]] > 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 > [hidden email] > http://lists.osgeo.org/mailman/listinfo/mapguide-internals > _______________________________________________ > mapguide-internals mailing list > [hidden email] > http://lists.osgeo.org/mailman/listinfo/mapguide-internals > -- Zac Spitzer - http://zacster.blogspot.com +61 405 847 168 _______________________________________________ mapguide-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/mapguide-internals _______________________________________________ mapguide-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/mapguide-internals _______________________________________________ mapguide-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/mapguide-internals _______________________________________________ mapguide-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/mapguide-internals |
||||||||||||||||
|
Walt Welton-Lair
|
In reply to this post
by zspitzer
I'm not familiar with the specifics of FDO ordering, but yes if FDO had a way for you to set an "ordering filter" that controls how features are returned, then that would be the preferred way to address this since it would mean only one query.
But this just shifts the performance issue to FDO. How would commonly-used providers like SHP and SDF implement that efficiently? You may have another option - implement a utility which creates a data set optimized for a theme: * the utility will read the layer definition containing the themes * it will query the original data set once using each rule's filter, and write those features to a new data set (it needs to be a format which returns features in the order they were written) * update your layer to use the new data set - the features will come in with the right order -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Zac Spitzer Sent: Thursday, June 25, 2009 11:55 PM To: MapGuide Internals Mail List Subject: Re: [mapguide-internals] MapGuide RFC 69 - Rendering Layer Styles So based on that, if FDO supported ordering both issues, that being Scott's label problem and the overlay of roads might be solved? http://trac.osgeo.org/fdo/ticket/516 would that be more efficient than respecting the layer style order and would also allow complex overriding of the rendering order simply by manipulating the column used for order by? z On Fri, Jun 26, 2009 at 1:42 PM, Walt Welton-Lair<[hidden email]> wrote: > In MapGuide the order of the rules has no influence at all on the feature rendering order or the label rendering order. Features are processed in the order that FDO returns them. If a feature corresponding to a local road is returned by FDO before a feature corresponding to a highway, then the local road gets rendered first - below the highway. > > Labels are processed in reverse order. As we iterate over the features for all layers we build up a list of candidate labels. Feature 1 on layer 1 adds its candidate labels, then feature 2 on layer 1, ... Once all features on all visible layers have been processed we do the final processing of labels. We iterate over the list of candidate labels in reverse order - top down in rndering order. The last feature on the topmost layer has the first crack at displaying its labels. Then the next-to-last feature on the topmost layer, and eventually you move to the next lower layer. > > This is the way MapGuide has worked since the very beginning (pre-MapGuide 6.5). > > > I'm going to bed... > > ________________________________________ > From: [hidden email] [[hidden email]] > Sent: Thursday, June 25, 2009 11:29 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 > > Welt That was confusing...Are you saying if I put complex linestyles on highways and labels but leave local roads simplex thats why the local road labels render before myy complex linestyle roads no matter how far up I promote thhem in thhhe theme...I have the same problem with polygons...If I move townships, villages, or cities to the top of my theme of muniipalities it seems to have no effect onlabeling priority at all...it seems almost random > > -----Original Message----- > From: Walt Welton-Lair <[hidden email]> > Sent: Thursday, June 25, 2009 10:07 PM > To: MapGuide Internals Mail List <[hidden email]> > Subject: RE: [mapguide-internals] MapGuide RFC 69 - Rendering Layer Styles > using Style Order > > "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: [hidden email] [[hidden email]] On Behalf Of Zac Spitzer [[hidden email]] > 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<[hidden email]> 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: [hidden email] [[hidden email]] On Behalf Of Zac Spitzer [[hidden email]] >> 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 >> [hidden email] >> http://lists.osgeo.org/mailman/listinfo/mapguide-internals >> _______________________________________________ >> mapguide-internals mailing list >> [hidden email] >> http://lists.osgeo.org/mailman/listinfo/mapguide-internals >> > > > > -- > Zac Spitzer - > http://zacster.blogspot.com > +61 405 847 168 > _______________________________________________ > mapguide-internals mailing list > [hidden email] > http://lists.osgeo.org/mailman/listinfo/mapguide-internals > _______________________________________________ > mapguide-internals mailing list > [hidden email] > http://lists.osgeo.org/mailman/listinfo/mapguide-internals > > _______________________________________________ > mapguide-internals mailing list > [hidden email] > http://lists.osgeo.org/mailman/listinfo/mapguide-internals > -- Zac Spitzer - http://zacster.blogspot.com +61 405 847 168 _______________________________________________ mapguide-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/mapguide-internals _______________________________________________ mapguide-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/mapguide-internals |
||||||||||||||||
|
Flipper
|
In reply to this post
by Flipper
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 <[hidden email]> Sent: Friday, June 26, 2009 9:39 AM To: MapGuide Internals Mail List <[hidden email]> 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: [hidden email] [mailto:[hidden email]] 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: [hidden email] [[hidden email] > ] On Behalf Of Zac Spitzer [[hidden email]] > 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<[hidden email]> 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: [hidden email] [[hidden email] >> ] On Behalf Of Zac Spitzer [[hidden email]] >> 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 >> [hidden email] >> http://lists.osgeo.org/mailman/listinfo/mapguide-internals >> _______________________________________________ >> mapguide-internals mailing list >> [hidden email] >> http://lists.osgeo.org/mailman/listinfo/mapguide-internals >> > > > > -- > Zac Spitzer - > http://zacster.blogspot.com > +61 405 847 168 > _______________________________________________ > mapguide-internals mailing list > [hidden email] > http://lists.osgeo.org/mailman/listinfo/mapguide-internals > _______________________________________________ > mapguide-internals mailing list > [hidden email] > 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 [hidden email] http://lists.osgeo.org/mailman/listinfo/mapguide-internals _______________________________________________ mapguide-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/mapguide-internals _______________________________________________ mapguide-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/mapguide-internals |
||||||||||||||||
|
Walt Welton-Lair
|
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: [hidden email] [mailto:[hidden email]] 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 <[hidden email]> Sent: Friday, June 26, 2009 9:39 AM To: MapGuide Internals Mail List <[hidden email]> 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: [hidden email] [mailto:[hidden email]] 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: [hidden email] [[hidden email] > ] On Behalf Of Zac Spitzer [[hidden email]] > 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<[hidden email]> 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: [hidden email] [[hidden email] >> ] On Behalf Of Zac Spitzer [[hidden email]] >> 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 >> [hidden email] >> http://lists.osgeo.org/mailman/listinfo/mapguide-internals >> _______________________________________________ >> mapguide-internals mailing list >> [hidden email] >> http://lists.osgeo.org/mailman/listinfo/mapguide-internals >> > > > > -- > Zac Spitzer - > http://zacster.blogspot.com > +61 405 847 168 > _______________________________________________ > mapguide-internals mailing list > [hidden email] > http://lists.osgeo.org/mailman/listinfo/mapguide-internals > _______________________________________________ > mapguide-internals mailing list > [hidden email] > 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 [hidden email] http://lists.osgeo.org/mailman/listinfo/mapguide-internals _______________________________________________ mapguide-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/mapguide-internals _______________________________________________ mapguide-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/mapguide-internals |
||||||||||||||||
|
Flipper
|
In reply to this post
by Flipper
So why isnt it reverswd..run the filter on the full geometry set 100 times and stylize all at once than itterating ttthrough 10000 objects aaacross 100 filters? Sorry wm6 phone..
It drops out having to itterate through 100 styles aaas well as well as 100 label types....You would have he style stored, label type stored and do a bulk filter on all geometry...and bulk stylize....It seems ludacris to itterate through geometry on a theme as the oooutside loop...at what point would anyone ver logically have more rules than geometry objects? Having the rules the outside loop would be immensly more efficient...Even if the filter werent a bulk query and literally was an inner loop over geometry half would end before 5000, all in the other scenario itterate 10000 regRDLESS -----Original Message----- From: Walt Welton-Lair <[hidden email]> Sent: Friday, June 26, 2009 3:48 PM To: MapGuide Internals Mail List <[hidden email]> 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: [hidden email] [mailto:[hidden email]] 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 <[hidden email]> Sent: Friday, June 26, 2009 9:39 AM To: MapGuide Internals Mail List <[hidden email]> 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: [hidden email] [mailto:[hidden email]] 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: [hidden email] [[hidden email] > ] On Behalf Of Zac Spitzer [[hidden email]] > 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<[hidden email]> 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: [hidden email] [[hidden email] >> ] On Behalf Of Zac Spitzer [[hidden email]] >> 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 >> [hidden email] >> http://lists.osgeo.org/mailman/listinfo/mapguide-internals >> _______________________________________________ >> mapguide-internals mailing list >> [hidden email] >> http://lists.osgeo.org/mailman/listinfo/mapguide-internals >> > > > > -- > Zac Spitzer - > http://zacster.blogspot.com > +61 405 847 168 > _______________________________________________ > mapguide-internals mailing list > [hidden email] > http://lists.osgeo.org/mailman/listinfo/mapguide-internals > _______________________________________________ > mapguide-internals mailing list > [hidden email] > 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 [hidden email] http://lists.osgeo.org/mailman/listinfo/mapguide-internals _______________________________________________ mapguide-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/mapguide-internals _______________________________________________ mapguide-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/mapguide-internals _______________________________________________ mapguide-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/mapguide-internals |
||||||||||||||||
|
Flipper
|
In reply to this post
by Flipper
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 <[hidden email]> Sent: Friday, June 26, 2009 3:48 PM To: MapGuide Internals Mail List <[hidden email]> 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: [hidden email] [mailto:[hidden email]] 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 <[hidden email]> Sent: Friday, June 26, 2009 9:39 AM To: MapGuide Internals Mail List <[hidden email]> 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: [hidden email] [mailto:[hidden email]] 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: [hidden email] [[hidden email] > ] On Behalf Of Zac Spitzer [[hidden email]] > 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<[hidden email]> 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: [hidden email] [[hidden email] >> ] On Behalf Of Zac Spitzer [[hidden email]] >> 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 >> [hidden email] >> http://lists.osgeo.org/mailman/listinfo/mapguide-internals >> _______________________________________________ >> mapguide-internals mailing list >> [hidden email] >> http://lists.osgeo.org/mailman/listinfo/mapguide-internals >> > > > > -- > Zac Spitzer - > http://zacster.blogspot.com > +61 405 847 168 > _______________________________________________ > mapguide-internals mailing list > [hidden email] > http://lists.osgeo.org/mailman/listinfo/mapguide-internals > _______________________________________________ > mapguide-internals mailing list > [hidden email] > 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 [hidden email] http://lists.osgeo.org/mailman/listinfo/mapguide-internals _______________________________________________ mapguide-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/mapguide-internals _______________________________________________ mapguide-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/mapguide-internals _______________________________________________ mapguide-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/mapguide-internals |
||||||||||||||||
|
Martin Morrison
|
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: [hidden email] [mailto:[hidden email]] On Behalf Of [hidden email] 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 <[hidden email]> Sent: Friday, June 26, 2009 3:48 PM To: MapGuide Internals Mail List <[hidden email]> 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: [hidden email] [mailto:[hidden email]] 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 <[hidden email]> Sent: Friday, June 26, 2009 9:39 AM To: MapGuide Internals Mail List <[hidden email]> 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: [hidden email] [mailto:[hidden email]] 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: [hidden email] [[hidden email] > ] On Behalf Of Zac Spitzer [[hidden email]] > 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<[hidden email]> 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: [hidden email] [[hidden email] >> ] On Behalf Of Zac Spitzer [[hidden email]] >> 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 >> [hidden email] >> http://lists.osgeo.org/mailman/listinfo/mapguide-internals >> _______________________________________________ >> mapguide-internals mailing list >> [hidden email] >> http://lists.osgeo.org/mailman/listinfo/mapguide-internals >> > > > > -- > Zac Spitzer - > http://zacster.blogspot.com > +61 405 847 168 > _______________________________________________ > mapguide-internals mailing list > [hidden email] > http://lists.osgeo.org/mailman/listinfo/mapguide-internals > _______________________________________________ > mapguide-internals mailing list > [hidden email] > 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 [hidden email] http://lists.osgeo.org/mailman/listinfo/mapguide-internals _______________________________________________ mapguide-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/mapguide-internals _______________________________________________ mapguide-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/mapguide-internals _______________________________________________ mapguide-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/mapguide-internals _______________________________________________ mapguide-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/mapguide-internals |
||||||||||||||||
|
Flipper
|
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: [hidden email] [mailto:[hidden email]] 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: [hidden email] [mailto:[hidden email]] On Behalf Of [hidden email] 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 <[hidden email]> Sent: Friday, June 26, 2009 3:48 PM To: MapGuide Internals Mail List <[hidden email]> 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: [hidden email] [mailto:[hidden email]] 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 <[hidden email]> Sent: Friday, June 26, 2009 9:39 AM To: MapGuide Internals Mail List <[hidden email]> 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: [hidden email] [mailto:[hidden email]] 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: [hidden email] > [[hidden email] > ] On Behalf Of Zac Spitzer [[hidden email]] > 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<[hidden email]> 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: [hidden email] >> [[hidden email] >> ] On Behalf Of Zac Spitzer [[hidden email]] >> 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 >> [hidden email] >> http://lists.osgeo.org/mailman/listinfo/mapguide-internals >> _______________________________________________ >> mapguide-internals mailing list >> [hidden email] >> http://lists.osgeo.org/mailman/listinfo/mapguide-internals >> > > > > -- > Zac Spitzer - > http://zacster.blogspot.com > +61 405 847 168 > _______________________________________________ > mapguide-internals mailing list > [hidden email] > http://lists.osgeo.org/mailman/listinfo/mapguide-internals > _______________________________________________ > mapguide-internals mailing list > [hidden email] > 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 [hidden email] http://lists.osgeo.org/mailman/listinfo/mapguide-internals _______________________________________________ mapguide-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/mapguide-internals _______________________________________________ mapguide-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/mapguide-internals _______________________________________________ mapguide-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/mapguide-internals _______________________________________________ mapguide-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/mapguide-internals |
||||||||||||||||
| Free Embeddable Forum Powered by Nabble | Help |