a featureType containing a raster basically have an attribute called "grid" which contains the GridCoverage Object. If you look at the renderRaster method you can notice that this method simply gets back the GridCoverage from this attribute. So for the raster the renderer doesn't care of the geometry, but if it doesn't parse the FeatureType grid attribute it won't work.
Don't know if I get the point.
On 11/17/05, [EMAIL PROTECTED] <
[EMAIL PROTECTED]> wrote:
I noticed that the lite/streaming renderer makes some bad assumptions
when you try to render a feature type with multiple geometries in it.
For example, I have a Postgis database with 261 rows (one for each
country in the world). It has 4 geometry columns in it, one for
varying degrees of generalization:
gen_full -- ungeneralized data (81mb)
gen1 -- 25mb
gen2 -- 10mb
gen3 -- 2mb
I then choose which geometry column by using
<MinScaleDenominator>/<MaxScaleDenominator> in my SLD file.
So far, everything is great. But, Geotools makes a little boo-boo in
Lite/StreamRenderer#findStyleAttributes().
It adds ALL the geometry columns (and GRID columns) to the list of
requested attributes. The JDBC driver pre-fetches 200 rows, so I get
an out-of-memory error even though I'm only rendering about 2mb of
data!
NOTE: 200 rows is basically the entire dataset, so its loading about
81+25+10+2 megs = 128 megs of data!
Here's the code comment on this:
/*
* GR: if as result of sae.getAttributeNames() ftsAttributes already
contains geometry
* attribue names, they gets duplicated, wich produces an error in
AbstracDatastore when
* trying to create a derivate FeatureType. So I'll add the default
geometry only if it is
* not already present, but: should all the geometric attributes be
added by default? I will
* add them, but don't really know what's the expected behavior
*/
...
//ALX: For rasters I need even the "grid" attribute.
The reason this was done was because, in SLD, you dont have to
explicity declare a reference to the default geometry.
For example, this symbolizer has an 'invisible' reference to the
default geometry:
<PolygonSymbolizer>
<Fill>
...
</Fill>
</PolygonSymbolizer>
This one has a direct reference to a geometry (could be the default
geometry, could be a secondary geometry):
<PolygonSymbolizer>
<Geometry><PropertyName>mygeometry</PropertyName></Geometry>
<Fill>
...
</Fill>
</PolygonSymbolizer>
I imagine there is a 'default' GRID-geometry for the RasterSymbolizer
too.
A simple way of dealing with is to have the style visitor have a flag
for "defaultGeometryUsed" and "defaultGridUsed". Then, instead of
adding all geometry&grid types to the Query we only add the explicitly
referenced ones (<Geometry>...</Geometry>) and add in the default
Geometry & Grid property if (1) it wasnt already explicitly referenced
and (2) the appropriate flag was set in the style visiting.
This will cut down the Query so its only pulling in geometry/grid
columns that it explictly needs. I dont think this will affect anyone
- but someone could have code that relies on this incorrect behavior.
Any code that does this should just make the style visitor know about
their invisible need of a column.
IS THIS GOING TO AFFECT ANYONE?
dave
PS.
Has anyone investigated what happens if you're not using the default
geometry, and you require coordinate reprojection?
----------------------------------------------------------
This mail sent through IMP: https://webmail.limegroup.com/
-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc. Get Certified Today
Register for a JBoss Training Course. Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
