Morning Milton: On Sat, Apr 11, 2009 at 8:52 AM, Milton Jonathan <[email protected]> wrote: > Hello Jody and list > > OK, so we're starting to deal with the UOM issue again, and we stumbled upon > some little issues: > > In the new SLD/SEParser's parse methods, such as parseLineSymbolizer, we now > want to make use of factory methods to create the symbolizers, instead of > using deprecated setXXX methods, right? (especially since we are *not* going > to add a deprecated setUnitOfMeasure method!). So, in order to do that, we > must implment the new GeoAPI's StyleFactory methods such as: > lineSymbolizer(String name, Expression geometry, Description description, > Unit<?> unit, org.opengis.style.Stroke stroke, Expression offset)
Correct; I am actually thinking we should make a new class here - so we can avoid all the madness that the current StyleFactory has - and make one explicitly just for construction. > The current StyleFactoryImpl simply returns null for those, and we are going > to fill that in. However, the constructor currently available in > LineSymbolizerImpl has some differences that I'm not completely sure how to > cope with: > 1. LineSymbolizerImpl expects a org.geotools.styling.Stroke, instead of the > org.opengis.style.Stroke from the GeoAPI interface. Do we need to convert it > to a Geotools Stroke if necessary, or could we change LineSymbolizerImpl to > simply deal with the GeoAPI Stroke and make no other assumptions? I will have a look and see what can be done; it may just be an incorrect import. > 2. LineSymbolizerImpl expects a geometry name as a String, while GeoAPI > specifies an Expression. I guess this may go into some big "property names > are/aren't Strings" issue, so I'd like some guidance here: should we keep > using a geometryProperyName as a String in these Impl's, or should we switch > to Expression and have SLD/SEParser pass on a literal Expression with the > geometry name? This has implications on > LineSymbolizerImpl.getGeometryPropertyName, which many people seem to use... I have lost track a bit on where we are with this one; I recently rolled out a change to Like Filter; and got a bit stuck on incomplete StyleFactory changes. My feeling is that GeometryName will remain a String (or explicitly become a PropertyName expression); I find that easier to take then a flat String since the string was allowed to be an XPath expression anyways. And then we will probably add an extra method to hold some kind of formal geometry preprocessing thing. I was hoping it could be a general Function (so we would not need new API); but we kind of need it to be invertible etc... > Besides that, some minor issues > - Whenever necessary, we are changing all uses of Unit without generics to > versions using generics (Unit<?>). good good. > - If it's ok with you I was going to move around the parameters in > LineSymbolizerImpl's constructor to match those used in the GeoAPI > StyleFactory, just to make it easier on the user. I would like to start making these package visible only so people have to go through the factory. > Of course, these same issues also apply for the other symbolizers. Cheers, Jody ------------------------------------------------------------------------------ This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
