Jody Garnett ha scritto: > On 20/05/2010, at 4:57 PM, Andrea Aime wrote: > >> Eh, it might get tricky as we have two sources of uom >> specification, the literal itself, but also the symbolizer one. I >> guess the local one would win. >> >> Anyone interested in cooking up a patch? > > Pick me pick me! After all I failed at applying the screenmap patch > :-(
Don't feel bad about that, the patch went out of synch and would not apply... > I would actually like a bit of discussion first... We would still > like to be fast at the default case of working with pixels, is there > any way we can detect when we should check of a Measure.class? Or > should we just try all the time. Good question, I don't have much of an answer. The current approach is to transform the SLD into pixels uom before giving it to the SLDStyleFactory and more importantly before doing the query over the data so that we know how much to enlarge the query area to take into account big symbolizers. With this idea that one can put the uom in the text + filter functions that can add it dynamically boom, the above does not work anymore. Quite honestly, I don't feel like restarting everything from scratch though, tempted to just refuse to handle the local uom on symbolizers that have the "px" pop up dynamically using functions... Otherwise we have to scrap the rescaling visitor and rebuild the uom -> px logic all in the SLDStyleFactory and also kiss goodbye the ability to automatically figure out the rendering meta-buffer when doing queries. So... what about having the rescale style visitor look for px at the end of an expression and handle that accordingly? If it's a literal check it if ends with px, if it's an expression check if it's a strConcat funcion and look if it has a "px" literal at the end? Cheers Andrea -- Andrea Aime OpenGeo - http://opengeo.org Expert service straight from the developers. ------------------------------------------------------------------------------ _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
