On Mon, 2010-12-20 at 10:37 +0100, Andrea Aime wrote: > On Mon, Dec 20, 2010 at 10:11 AM, Niels <[email protected]> wrote: > > > >> 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/) > > > > Okay, I see, thanks for clearing that out for me. That still poses a problem > > if someone would try to use nested properties in the symbolizers. Perhaps > > the algorithm should be changed without changing the aim, instead of looking > > for geometry descriptors, get the property names directly from the > > symbolizers. > > I think we can do that, it's just a matter or writing another style > visitor that just > extracts the attribute names of the geometries used in the symbolizers. > > But we need to preserve some level of attribute checking to make sure > people get proper errors when asking for attributes that are not there > (the hints on the property accessors work for me, provided they do not > add significant overhead, the beauty of the code that we have now is > that it is performed just once, up front, instead of feature by feature)
For this same reason, possibility of properties not being there on a Feature (or metadata record for the sake), the CSW spec defines a propertyExists predicate. In GeoTools there's a propertyExists function that can be used in Filters, and I think it would be better to use it explicitly wherever polymorphism is used in order to take action based on the existence of a given xpath? 2c/ Gabriel > > 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 -- Gabriel Roldan [email protected] Expert service straight from the developers ------------------------------------------------------------------------------ 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
