[mapguide-internals] MapGuide RFC 69 - Rendering Layer Styles using Style Order

Tue Jul 7 23:01:22 EDT 2009

On Wed, Jul 8, 2009 at 7:56 AM, Tom Fukushima<tom.fukushima at autodesk.com> wrote:
> Hi Zac,
>
> Please also update the following statement in the RFC: "The only work around currently is to break road networks into separate layers." to read as...
>
> There are three possible known work arounds:
> 1) Break the road networks into separate layers.
> 2) Render the roads using composite type styles and specify the RenderingPass appropriately (see RFC 29 for details).
> 3) Set up the data source so that it returns readers with the features in the correct draw order.

ok, I added three workarounds in.

> For #3, Walt gave a description of this in one of his emails.  I have extracted it for you here for your reference...
> 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)

this can be done pretty easily in php or c# via the mg api. going this approach,
massaging the data would also most likely end up elimating any complex
expression filters,

> * update your layer to use the new data set - the features will come in with the right order
>
> Also, we're not sure which, if any, data source #3 will work with. But if it does work, it will be the most efficient one.  So perhaps, we should leave out #3 above until someone tries it out and verifies that it works.

do you the potential datasource problem is that they don't perform ordering?

SDF does via http://fdo.osgeo.org/files/fdo/docs/SDF/_i_extended_select_8h-source.html

http://trac.osgeo.org/fdo/wiki/FDORfc26

pretty much all database servers do natively?

>
> Thanks
> Tom
>
> -----Original Message-----
> From: mapguide-internals-bounces at lists.osgeo.org [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Zac Spitzer
> Sent: Friday, June 26, 2009 7:02 PM
> To: MapGuide Internals Mail List
> Subject: Re: [mapguide-internals] MapGuide RFC 69 - Rendering Layer Styles using Style Order
>
> I have updated the RFC and added a FDO RFC for Ordering support
>
> http://trac.osgeo.org/mapguide/wiki/MapGuideRfc69
> http://trac.osgeo.org/fdo/wiki/FDORfc40
>
> z
>
>
> On Sat, Jun 27, 2009 at 12:40 AM, Walt
> Welton-Lair<walt.welton-lair at autodesk.com> wrote:
>> They either split things up into multiple layers, as you say, or they use the rendering pass behavior in the enhanced stylization (currently no UI for the latter, so that complicates that one).  Both will have similar performance impact as what's proposed in the RFC - both end up making the same number of FDO queries.  And if you read ticket 618 referenced by the RFC, the number of queries is a concern.
>>
>> I would love to see MapGuide be able to support this behavior.  But without a good / novel approach for doing this the performance impact will be atrocious.  There are customers who have themed layers with 100's of rules, and changing the default stylization behavior to have draw order match rule order will not work for those maps performance-wise.  I think at minimum the RFC will need to be updated to make this behavior optional (default is off).  And that means a layer definition schema change.
>>
>> -----Original Message-----
>> From: mapguide-internals-bounces at lists.osgeo.org [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Paul Spencer
>> Sent: Friday, June 26, 2009 9:18 AM
>> To: MapGuide Internals Mail List
>> Subject: Re: [mapguide-internals] MapGuide RFC 69 - Rendering Layer Styles using Style Order
>>
>> How would someone achieve the desired effect now?  From what I
>> understand (and I am not a power user of mapguide by any standard of
>> measurement), you would need to create several layer definitions each
>> with a filter and theme those layers for each road class?
>>
>> how would performance for:
>>
>> - for each rule, construct an FDO query filtered by the rule's condition
>> - render all features using the rule's style
>>
>> differ from having separate layers?
>>
>> Yours confusedly ;)
>>
>> Paul
>>
>>
>> On 25-Jun-09, at 11:06 PM, Walt Welton-Lair wrote:
>>
>>> "Can some elaborate on how the server currently handles this?"
>>> Handles what?
>>>
>>> The current code iterates once over the features (ignore the
>>> compound line style example).  For every feature it evaluates the
>>> filters defined by the rules (in the order that the rules are
>>> specified).  Once it finds a matching rule it applies its style to
>>> the feature.
>>>
>>> With compound line styles we make a pass over all the features for
>>> each line style.  So for a compound line style containing M styles
>>> we make M FDO queries.
>>>
>>> With rendering passes (RFC 29) we also iterate over all the layer's
>>> features for each rendering pass.  The more passes you define the
>>> more queries you make.
>>>
>>> How to implement your RFC?
>>>
>>> option 1
>>> - Make a pass over the features for each rule.
>>> - During each pass only render the features that satisfy the rule
>>> for that pass.
>>> - If there are M rules you will make M FDO queries.
>>> => performance (speed) will be unacceptable for anything more than a
>>> few themes
>>>
>>> option 2
>>> - Make one query against all the features, remembering (in memory?)
>>> all the feature information (attributes / geometry) needed by
>>> stylization.
>>> - During the initial pass render the features for the first rule.
>>> - Iterate over the remaining rules in order, rendering the features
>>> for each rule.
>>> => performance (memory use) will be unacceptable for data sources
>>> containing large numbers of features
>>> => this approach goes against the MG architecture of not keeping
>>> feature data in memory during stylization (we already break that
>>> rule with labels which is what leads to high memory usage spikes for
>>> some maps)
>>>
>>> option 3
>>> - Allocate one image per rule.
>>> - Make one query against all the features, and render each feature
>>> into the image corresponding to the rule it satisifes.
>>> - Merge all images at the end.
>>> => performance (speed + memory) will be unacceptable for anything
>>> more than a few themes
>>>
>>> option 4
>>> ???
>>>
>>>
>>> ________________________________________
>>> From: mapguide-internals-bounces at lists.osgeo.org [mapguide-internals-bounces at lists.osgeo.org
>>> ] On Behalf Of Zac Spitzer [zac.spitzer at gmail.com]
>>> Sent: Thursday, June 25, 2009 10:36 PM
>>> To: MapGuide Internals Mail List
>>> Subject: Re: [mapguide-internals] MapGuide RFC 69 - Rendering Layer
>>> Styles      using Style Order
>>>
>>> At the moment the only way to achieve this is to split the road
>>> network out into
>>> multiple layers which is rather ugly.
>>>
>>> Taking a road network as the example here, it's only at the
>>> intersections where this
>>> problem occurs.
>>>
>>> Can some elaborate on how the server currently handles this?
>>>
>>> z
>>>
>>> On Fri, Jun 26, 2009 at 12:28 PM, Walt
>>> Welton-Lair<walt.welton-lair at autodesk.com> wrote:
>>>> "Proposed solution: Add support to the rendering engine to render
>>>> layer styles in ordered passes."
>>>>
>>>> I'd like to see some concrete suggestions in the RFC on how to
>>>> actually do this efficiently.  Just consider a conservative use
>>>> case - say around 10  rules.
>>>>
>>>> Walt
>>>> ________________________________________
>>>> From: mapguide-internals-bounces at lists.osgeo.org [mapguide-internals-bounces at lists.osgeo.org
>>>> ] On Behalf Of Zac Spitzer [zac.spitzer at gmail.com]
>>>> Sent: Thursday, June 25, 2009 9:29 PM
>>>> To: MapGuide Internals Mail List
>>>> Subject: [mapguide-internals] MapGuide RFC 69 - Rendering Layer
>>>> Styles using    Style Order
>>>>
>>>> I have posted a new RFC
>>>>
>>>> http://trac.osgeo.org/mapguide/wiki/MapGuideRfc69
>>>>
>>>> --
>>>> Zac Spitzer -
>>>> http://zacster.blogspot.com
>>>> +61 405 847 168
>>>> _______________________________________________
>>>> mapguide-internals mailing list
>>>> mapguide-internals at lists.osgeo.org
>>>> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>>>> _______________________________________________
>>>> mapguide-internals mailing list
>>>> mapguide-internals at lists.osgeo.org
>>>> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>>>>
>>>
>>>
>>>
>>> --
>>> Zac Spitzer -
>>> http://zacster.blogspot.com
>>> +61 405 847 168
>>> _______________________________________________
>>> mapguide-internals mailing list
>>> mapguide-internals at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>>> _______________________________________________
>>> mapguide-internals mailing list
>>> mapguide-internals at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>>
>>
>> __________________________________________
>>
>>    Paul Spencer
>>    Chief Technology Officer
>>    DM Solutions Group Inc
>>    http://research.dmsolutions.ca/
>>
>> _______________________________________________
>> mapguide-internals mailing list
>> mapguide-internals at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>> _______________________________________________
>> mapguide-internals mailing list
>> mapguide-internals at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>>
>
>
>
> --
> Zac Spitzer -
> http://zacster.blogspot.com
> +61 405 847 168
> _______________________________________________
> mapguide-internals mailing list
> mapguide-internals at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
> _______________________________________________
> mapguide-internals mailing list
> mapguide-internals at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>

-- 
Zac Spitzer -
http://zacster.blogspot.com
+61 405 847 168