We're still looking for a solution to this issue (ticketed as
https://jira.codehaus.org/browse/GEOT-4281 and the related issue
https://jira.codehaus.org/browse/GEOT-4285)
One possible fix is toremove the requerying (by removing the lines
2236-2239 in StreamingRenderer,java and simply returning the source). This
works in the test case under consideration (although it then runs into the
different issue 4295) and it doesn't seem to impact general operation. But
was there a reason the requerying was implemented in the first place?
This issue has now cropped up in several different contexts, so it really
needs to get resolved.
On Wed, Oct 3, 2012 at 4:24 PM, Martin Davis <[email protected]> wrote:
> Any thoughts on this from the Rendering Transformation designer?
>
> This same code is causing me problems as well, in a different way. I am
> experimenting with rendering transformations which consist of chains of
> processes. In particular, I am working with the chain Heatmap->Contour.
> It works great in the native CRS of the input data (WGS84 in this case),
> but doesn't work when the output CRS is different (e.g. WebMercator).
>
> The reason is that the original query contains a FastBBOX filter in WGS84
> CRS, which then filters out the transformed output, since it is in
> WebMercator CRS.
>
> Is it really necessary to re-apply the query?
>
>
> On Wed, Sep 19, 2012 at 3:25 PM, Ian Schneider <[email protected]>wrote:
>
>> In tracking down why a PointStacker transform isn't working, I found
>> that the StreamingRenderer adapts the original query then reapplies it
>> to the transformed feature collection. StreamingRenderer:2236 on 8.x
>> is the start of the relevant block of code.
>>
>> The issue in my case is that the original query[1] contains an
>> attribute that the PointStacker doesn't preserve and hence the second
>> query on the transformed collection yields nothing.
>>
>> Certainly one improvement would be to allow PointStacker to preserve
>> one of the aggregated feature's attributes to represent the new
>> stacked output feature, but my question is:
>>
>> Why is the query being run a second time? I could see that preserving
>> the BBOX would be useful for transformations that create new features
>> that lie outside the initial BBOX but it seems like the other work is
>> redundant as the features have already been filtered via the first
>> query. I admit I might be short-sighted here.
>>
>> Regards,
>> -Ian
>>
>> [1] [[ Date = Tue Jan 15 17:00:00 MST
>> 1980 ] AND FastBBOX [property=location,
>> envelope=ReferencedEnvelope[-216.56249996985542 : 216.56249996985542,
>> -75.1441685694744 : 86.89368497984668]]]
>>
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> GeoTools-Devel mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>
>
>
>
> --
> Martin Davis
> OpenGeo - http://opengeo.org
> Expert service straight from the developers.
>
>
--
Martin Davis
OpenGeo - http://opengeo.org
Expert service straight from the developers.
------------------------------------------------------------------------------
LogMeIn Central: Instant, anywhere, Remote PC access and management.
Stay in control, update software, and manage PCs from one command center
Diagnose problems and improve visibility into emerging IT issues
Automate, monitor and manage. Do more in less time with Central
http://p.sf.net/sfu/logmein12331_d2d
_______________________________________________
GeoTools-Devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
