On Mon, Dec 20, 2010 at 9:33 AM, Niels <[email protected]> wrote:
> 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. > > You're right, it does only loop over the attributes used in the style, I did > know that, perhaps I wasn't clear about that. > I still don't understand why it loops over all the attributes used in the > style's filters? The filters don't really have anything to do with the > geometry that is used, have they? Isn't it just the default geometry that is > used? That's what I understood from the drawing code. There is some truth there but it's not the whole story. Yes, that method extract all of the attributes used in the style, whether they are used in a filter or in the symbolizers, and to build the bbox we would just need the ones used in the symbolizers. But no, we don't just use the default geometry. I said that in the previous mail already, all symbolizers have a <geometry> element which can contain a PropertyName to select whatever geometry attribute you want out of the feature. Using the default geometry is the default behavior, the SLD author can however use <xyzSymbolizer><geometry>...</geometry></xyzSymbolizer> to specify a certain geometry to be painted, different than the default one. Or, in your case, as a custom extension, apply a funcion on top of it to transform it (see http://blog.geoserver.org/2010/03/17/extending-your-map-styling-with-geometry-transformations/) > 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 > > Haha, but something like that already exists, because I implemented it! Does it work on simple features as well? > There is a property in AttributeExpressionImpl to make it throw an expection > on invalid property names, for exactly that purpose, that is used by > app-schema. (It was used because people had exactly the same problem with > non-existing column names in the app-schema mapping file). > We could use that to report the error at time of the evaluation of the > property name against a specific feature, rather than in advance. > One issue: I am not sure if this would eliminate the problem with > polymorphism completely though. Because doesn't polymorphism imply that some > x-paths won't be able to be evaluated against some features - in which case > they probably should be ignored? Is there any way to know if not finding the property is legit due to polymorphism or if it's a mistake? Whatever we do mind the simple feature path does not have to suffer functional or performance regressions. 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
