From: Andrea A. <and...@ge...> - 2013-10-14 20:29:22
|
On Mon, Oct 14, 2013 at 10:15 PM, Nuno Oliveira < nun...@pt...> wrote: > Hi, > > I have some questions about the SLD stroke-dasharray property support. > Does it exists some reason for stroke-dasharray property only supports > literal expressions ? > Easy: nobody ever donated/funded the work to go beyond the current situation. > > After reading some code I come to the conclusion that the only restriction > is defined > by the Stroke interfaces, i.e. org.opengis.style.Stroke and > org.geotools.styling.Stroke. > Basically they define that the stroke-dasharray property can only be an > array of floats > and everyone else just follow that definition. > Correct. Breaking an interface is possible, but would require extra work, and can be done only in the development series, never to be backported to the stable one (in other words, if you make changes to it, you'll have to wait a few months so that the current dev series becomes the new stable one, in this case, 11.0, to be released March 2014). > > So, SLD parser for SLD 1.0.0 version do this (SLDParser): > > if (res.equalsIgnoreCase("dasharray") > || res.equalsIgnoreCase("stroke-dasharray")) { > String dashString = null; > if( child.getChildNodes().getLength() == 1 && > child.getFirstChild().getNodeType() == Node.TEXT_NODE ){ > dashString = getFirstChildValue(child); > } else { > Expression definition = parseCssParameter(child); > if( definition instanceof Literal){ > dashString = ((Literal)definition).getValue().toString(); > } > else { > LOGGER.warning("Only literal stroke-dasharray supported at > this time:"+definition); > } > } > } > > > And SLD parser for SLD 1.1.0 version do this (SLDStrokeBinding): > > float[] dash = null; > > if (dashArray != null) { > String[] string = Filters.asString(dashArray).split(" +"); > dash = new float[string.length]; > > for (int i = 0; i < string.length; i++) { > dash[i] = Float.parseFloat(string[i]); > } > } > > > In the rendering process the getStroke methods retrieve the values from > all the stroke properties > evaluating them except for the dasharray property that is already an array > of floats: > > // get the other properties needed for the stroke > float[] dashes = stroke.getDashArray(); > float width = evalToFloat(stroke.getWidth(), feature, 1); > float dashOffset = evalToFloat(stroke.getDashOffset(), feature, 0); > > I checked the SLD standard and I haven't found any restriction that force > the dash property to > be represented as an array of floats. > > Would it be acceptable to alter the Stroke interface to return and accept > the dashproperty as an Expression > instead of an array of floats ? > You'll have to make a formal proposal, get it accepted by the PMC (which is quite likely to happend), probably sign a contribution agreement to OSGEO, do the work, have it reviewed and merged, and be patient about the status of it being released as a stable version. Of course, you can develop the patch, and in the meantime apply it to your custom fork of the stable series. A bit annoying I know, however, the core developers do that from time to time, following the exact same rules. Cheers Andrea -- == Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it ------------------------------------------------------- |