On Fri, Dec 17, 2010 at 9:15 AM, Niels <[email protected]> wrote:
> Hi Andrea and list,
>
> The next chapter in the app-schema + WMS saga.
>
> In the streaming renderer code there are some assumptions in conflict with
> polymorphism. In particular, I'm struggling with following code:
>
> private Filter createBBoxFilters(FeatureType schema, String[] attributes,
> List<ReferencedEnvelope> bboxes) throws IllegalFilterException {
> Filter filter = Filter.INCLUDE;
> final int length = attributes.length;
> PropertyDescriptor attType;
>
> for (int j = 0; j < length; j++) {
> attType = schema.getDescriptor(attributes[j]);
>
> // DJB: added this for better error messages!
> if (attType == null) {
> if (LOGGER.isLoggable(Level.FINE))
> LOGGER.fine(new StringBuffer("Could not find '").append(
> attributes[j]).append("' in the FeatureType (")
> .append(schema.getName()).append(")")
> .toString());
> throw new IllegalFilterException(new StringBuffer(
> "Could not find '").append(
> attributes[j] + "' in the FeatureType (").append(
> schema.getName()).append(")").toString());
> }
>
> if (attType instanceof GeometryDescriptor) {
> String localName = ((GeometryDescriptor)
> attType).getLocalName();
> Filter gfilter = new FastBBOX(localName, bboxes.get(0),
> filterFactory);
>
> if (filter == Filter.INCLUDE) {
> filter = gfilter;
> } else {
> filter = filterFactory.or( filter, gfilter );
> }
>
> if(bboxes.size() > 0) {
> for (int k = 1; k < bboxes.size(); k++) {
> filter = filterFactory.or( filter, new
> FastBBOX(localName, bboxes.get(k), filterFactory) );
> }
> }
> }
> }
>
> return filter;
> }
> Two things
>
> 1. I tried writing code that can get accessors from x-paths attributes
> against a complex type, but this isn't possible because of polymorphism.
> With polymorphism, you cannot verify whether a certain attribute exists
> using just only a type. Validation of attributes can be different per
> feature. The attributes aren't only validated at this stage (which is a
> strange place), but also in the geoserver itself.
>
> 2. Why is a BBOX created for each geometry type it can find? Isn't it enough
> to create a BBOX for the geometry type that is used for rendering? In most
> cases there would only be one, but why doing it in a loop then?
I think you're looking at the piece of code out of context, otherwise I don't
see how you're reaching such conclusions.
The array of attribute names coming down into the method is generated
in the queryLayer method, line 944, by the following call:
attributes = findStyleAttributes(styles, schema);
So the attributes are not "all the attributes", but only the ones the
SLD author
explictly mentioned in the SLD in the <geometry> elements (plus the
default ones).
So to answer your question "Isn't it enough
to create a BBOX for the geometry type that is used for rendering" the
answer is yes, that's exactly what we're doing.
As for attribute validation, we cannot just remove it, that would be a massive
regression, we had no ends of issues year ago because people did not know why a
certain SLD did not work with their data, and the reason was just a typo
or a case issue in the attribute names.
The problem here is that the normal behavior for features (at least,
simple ones)
is to return a null if you ask for a feature that is not there, so we
cannot trust
the rendering runtime to just break on error. That's by contract:
/**
* Gets an attribute value by name.
* <p>
* This method is a convenience for:
* <pre>
* Property p = getProperty( name );
* return p.getValue();
* </pre>
* </p>
* @param name The name of the attribute whose value to retrieve.
*
* @return The attribute value, or <code>null</code> if no such attribute
* exists with the specified name.
*/
Object getAttribute( String name );
and property accessors just follow suit, not checking if the
attribute is actually there. I think there is quite a bit of code depending on
this behavior, whether one likes it or not.
So not sure how to handle this one. Disable static validation only for
complex featuers? Is there a way to know in advance they are using
polymorphism and maybe disable validation only in that case?
Alternatively we could have some kind of hint be passed down
in expression evaluation that forces the property accessors to
just throw an exception if the attribute is not there.
Haven't checked if that is possible at all, just thinking out loud here
Cheers
Andrea
-----------------------------------------------------
Ing. Andrea Aime
Senior Software Engineer
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584962313
fax: +39 0584962313
http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf
-----------------------------------------------------
------------------------------------------------------------------------------
Lotusphere 2011
Register now for Lotusphere 2011 and learn how
to connect the dots, take your collaborative environment
to the next level, and enter the era of Social Business.
http://p.sf.net/sfu/lotusphere-d2d
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
