stroke-dasharray from database

Andrea Aime added a comment - 08/Aug/11 2:23 AM Because it's a literal in the SLD specification. We expanded from literals to expressions in other places, someone with enough funding to go through the process and change all the API accordingly could push for an API change in the 8.0 series

Andrea Aime added a comment - 08/Aug/11 2:38 AM Btw, with some extra work the api could be made backwards compatible, allowing a commit on the 2.7.x series

Luca Morandini added a comment - 09/Aug/11 11:24 AM Andrea, I beg to differ: AFAIK, since "sld:ParameterValueType" element is allowed mixed content, including "ogc:expression" if need be, I presume properties from the layer can be used as well. Anyway, I think this issue can be merged with the following one: http://jira.codehaus.org/browse/GEOT-2929

Andrea Aime added a comment - 09/Aug/11 12:13 PM Luca, it's not so easy. Regardless of what the SLD spec say this is the GeoTools interface: {code} public interface Stroke extends org.opengis.style.Stroke {  ...     float[] getDashArray();     void setDashArray(float[] dashArray); } */ In order to do what Tobia asks the API needs to be changed to use Expression instead, and have all usage points follow suite, this needs a GSIP, and so on

Luca Morandini added a comment - 09/Aug/11 2:07 PM Andrea, I never thought it was going to be easy ;) I just meant to point out that this specific aspect of SLD was not implemented (yet) in GeoTools. Hmm... could WKT shapes help Tobias's use case somehow ?

Andrea Aime added a comment - 09/Aug/11 2:36 PM Right, I stand corrected, normally we are more flexible than the sld spec but this one, dasharray, is not up to the actual SLD flexibility. It has been has been there in its float[] form for the past 9 year without much of a complain (besides GEOT-2929 , which is a dead report since it was never assigned to anyone, so I guess nobody noticed it): {code} ------------------------------------------------------------------------ r360 | jmacgill | 2002-05-01 18:51:53 +0200 (mer, 01 mag 2002) | 2 lines dash array is now returned as a float array and not a string of space seperated floats {code} That said, most of what I said above is still valid: {panel} We expanded from literals to expressions in other places, someone with enough funding to go through the process and change all the API accordingly could push for an API change in the 8.0 series, with some extra work the api could be made backwards compatible, allowing a commit on the 2.7.x series {panel} Not sure if wkt shapes can be of help here, in case of large strokes or short segments they won't bend like a normal line.

Tobias Warneke added a comment - 10/Aug/11 1:38 AM Without breaking to much (I hope), I introduced for my temporary solution custom properties into Stroke, StrokeImpl ... and used a property dynamic-dasharray to achieve my goal. Here is a snipped from a style: <LineSymbolizer> <Stroke> <CssParameter name="stroke"><ogc:PropertyName>stroke</ogc:PropertyName></CssParameter> <CssParameter name="stroke-opacity"><ogc:PropertyName>stroke_opacity</ogc:PropertyName></CssParameter> <CssParameter name="stroke-width"><ogc:PropertyName>stroke_width</ogc:PropertyName></CssParameter> <CustomProperty name="dynamic-dasharray">                     <ogc:PropertyName>stroke_dasharray</ogc:PropertyName>                 </CustomProperty> </Stroke> </LineSymbolizer> For my usecase: I want to visualize dynamic database data through this dash array. Using svgs does not follow the line so nicely, I think. Thanks Tobias

Trupti Pol added a comment - 10/Jul/12 6:38 AM Hi Tobias, I am also facing the same issue and would like to use your workaround. Will you please elaborate more on how to create Custom Property for Dynamic dasharray Thanks in advance Trupti

Tobias Warneke added a comment - 15/Feb/13 7:51 AM Hi Trupti, sorry but I forgot about this issue, thus my late answer. I was talking about a geotools - patch, that I introduced to make it use the custom property syntax above. I am about to actualize my patch to the actual geotools version. @aaime: Would this kind of patch have a chance to be introduced in a official GeoTools Version. I saw that custom properties were used in some places. Regards Tobias

Andrea Aime added a comment - 19/Feb/13 2:50 AM Tobias, I have doubts the custom property approach will be accepted, something that is more likely to be accepted is changing the Stroke interface so that the dasharray property becomes an Expression, and amend the code using it accordingly (sld parsers and encoders, renderer, dpi and uom rescalers, and so on). In any case that would be a API change, so it needs to be discussed on the devel mailing list with a formal proposal.

Tobias Warneke added a comment - 19/Feb/13 8:33 AM I just checked by switching from float[] to Expression within org.opengis.style.Stroke.getDashArray. Thats quite a change. So to get a solution more quickly as a first step I will adapt my patch.

Tobias Warneke added a comment - 27/Feb/13 4:59 AM Applying my patch I got to RescaleStyleVisitor which should consider my dynamic-dasharrays as well. I have to construct a new dynamic sld part like (line 105)  Expression rescale = ff.multiply( scale, expr ); but for a text list. So my way of achieving this would be to create a new FilterFunction "multiplyList", or so, and use this one like  Expression rescale = new FilterFunction_multiplyList( scale, expr ); or is there a better way to do this?

Andrea Aime added a comment - 27/Feb/13 7:08 AM Hum... given that the input is dynamic, your suggestion seems fine.

Tobias Warneke added a comment - 01/Mar/13 8:41 AM And finally here is the patch. Maybe you could discuss to include it :) . It has the advantage not to change the API. There was more to do than I first thought. All this uom rescaling was not included in my first version. But I digged through it and added testcases. Besides you include it or not, is there any "style" problem with this patch, which I should consider making future patches.

Andrea Aime added a comment - 01/Mar/13 9:23 AM I don't agree with the approach, as such, I won't start a discussion to include it. But you can, and the decision is not only mine. I'm not in favour, but not strongly against either, so if there is a vote I'll cast a -0 (non blocking).

Tobias Warneke added a comment - 06/Mar/13 3:06 AM You told me, that this approach is probably not included. I simply tried again ;). Here is a correction of my original patch. I send it here only for persistance reasons. So could you give mit a hint where I would start/send a proposal to force an api change for dash arrays to be expressions and not float arrays?

Andrea Aime added a comment - 06/Mar/13 3:43 AM You subscribe to geotools-devel and describe the API change you want to make, including the expected consequences on the codebase (what else needs to be modified as a result), and get some discussion going. You'll most likely be asked to prepare a format change proposal (which, at that point, will be mostly a summary of the discussion), which then needs to be voted by the control commitee. Once you get a positive vote you can implement your changes and submit a pull request for integration. Sorry this is a big long, but it's mandatory for public API changes that involve core modules

Tobias Warneke added a comment - 06/Mar/13 4:20 AM Don't be sorry for organizational workflows, long or short, that serve the stability of this great project. Regarding the proposal I will look into it. But at the moment there is a time issue.