Ok. It quite will suit me
--
View this message in context:
http://osgeo-org.1560.x6.nabble.com/SLD-Stroke-Dasharray-Property-tp5083512p5220467.html
Sent from the geotools-devel mailing list archive at Nabble.com.
--
_
Hi,
I have submitted a pull request for this issue.
Igor if you don't mind I will put this as the pull request for the
proposal.
Best regards,
Nuno Oliveira
Le dimanche 16 août 2015 à 12:20 +0100, Igor Volkov a écrit :
> In order to clarify the essence of my doubts about the expected behavior
In order to clarify the essence of my doubts about the expected behavior of
the method float[] Stroke.getDashArray() I have add new test in
SLDStyleTest:
Stroke stroke = sf.createStroke(null, null);
assertNull(stroke.getDashArray());
List dashArray = stroke.dashArray();
dashArray.
In my last commit
(https://github.com/igorvolk/geotools/commit/3ea8bd1f2cd017c2e0b312b9f52c02e04612b5ff)
I have implemented the proposals of Jody Garnett, concerning the interface
org.geotools.styling.Stroke. I have left interface org.opengis.style.Stroke
unmodified. I have some doubts concerning t
Hi!
If anyone is curious, my code for the parsing of the dash-array property
looks like this:
...
String dashString = null;
if( child.getChildNodes().getLength() == 1 &&
child.getFirstChild().getNodeType() == Node.TEXT_NODE ){
dashSt
Hi,
Glad I could help :)
About your doubts, the dash-array use case is different from the one
solved by the parseCssParameter method.
We actually want a list of expressions, so no need for the concat
function or other function.
In my opinion the implementation of the parsing of the dash-array
Also I have another doubts concerned to logic of sharing of implementation
for float [] getDashArray () and List dashArray in StrokeImpl. I
suggest that if List<> contains only float literals then getDasharray will
return them. If List <> is empty then getDasharray will return null. And if
element
Thank you Nuno! Through your doubts I continued my search and found a nice
solution, which is a symbiosis of my idea to use the argument of a function
for storing expressions for dash array (list) and your desire to do without
superfluous functions similar to that of the Label concatenation in SLD.
Hi,
I made a bad decision representing the dasharray property as an unique
expression.
Having the dasharray property represented as a set of expressions allows us to
handle
more uses cases and is more natural. It also helps solving the rescaling cases
...
Thanks for the feedback. I will w
Yep.
I think we may map Label to several expressions, or perhaps it is a single
concatenate expression which is a variable argument function.
Actually if you want to follow that line of reasoning you could make an
function to evaluate
a list of expressions into a double[] - and then the parser /
Hi,
> The principle is not exactly the same as linecap and linejoin are single
> values, while a dasharray is an array of values.
You're right my bad ...
> I believe that's why Jody was expecting a Expression[], one expression for
> each float/double value to be returned.
> This is more in li
On Fri, Jul 3, 2015 at 8:51 PM, Nuno Oliveira <
[email protected]> wrote:
> Thanks for your feedback.
>
> I'm a bit lost about his one
>
> I follow the same principie of others methods in that class, for example:
>
> public static String lineLinecap(LineSymbolizer symbolizer) ..
I thought line-up and line-join were Enums of some sort? Rather than an
expression ...
--
Jody Garnett
On 3 July 2015 at 11:51, Nuno Oliveira
wrote:
> Thanks for your feedback.
>
> I'm a bit lost about his one
>
> I follow the same principie of others methods in that class, for example:
Thanks for your feedback.
I'm a bit lost about his one
I follow the same principie of others methods in that class, for example:
public static String lineLinecap(LineSymbolizer symbolizer) ...
public static String lineLinejoin(LineSymbolizer symbolizer) ...
Le vendredi 03 juillet 2015 à 17
Le vendredi 03 juillet 2015 à 17:43 +0100, Jody Garnett a écrit :
> Got a question about the proposal:
>
>
> Expression dashArray()
>
>
>
> Is this a single expression, or do we expect an Expression[]?
Is a single Expression (I implemented a converter that convert a String
to an array of floa
One change to the utility method SLD.lineDash(LineSymbolizer symbolizer)
does not make sense to me ... returning a String rather than a float[].
This class is tasked with providing quick access to the data structure, so
if the data structure is Expression it should return an Expression (rather
tha
Got a question about the proposal:
Expression dashArray()
Is this a single expression, or do we expect an Expression[]?
I have made some additional tasks (for documentation, style factory,
etc...).
In general I like the idea of style supporting expression everywhere ...
--
Jody Garnett
On 3 J
Hi,
Thanks for the feedback.
>> Will this change break existing code that uses GeoTools?
Yes, at least in geoserver ...
I made the proposal:
https://github.com/geotools/geotools/wiki/stroke-dasharray-as-an-expression
Best regards,
Nuno Oliveira
Le jeudi 02 juillet 2015 à 22:45 +0100, Ben Ca
Nuno,
pull requests are preferred as they enable discussion and allow
automatic testing with Travis CI. Please use a feature branch in your
githib repository and rebasing and/or squashing improve the clarity of
your pull request:
http://docs.geotools.org/latest/developer/procedures/pull_request
Hi,
One year after ...
My company signed the contribution agreement and I would like to contribute
this work.
I have not worked with geoserver\geotools since (+/-) my last post in this
mailing list
and I probably missed some important changes ...
I did a new patch (attached) for the current
I separated it out its a procedure page as the steps to sign were being lost in
the details:
- http://docs.geotools.org/latest/developer/procedures/contribution_license.html
I also echo Andrea's words that we need to be sure you are comfortable donating
your code to the OSGeo Foundation before w
On Sun, Nov 3, 2013 at 12:19 PM, Andrea Aime
wrote:
>
> Can you also point me to the actual OSGEO contribution agreement ?
>>
>
> It's here:
> http://docs.geotools.org/latest/developer/roles/contribute.html#code-contribution-license
>
Nuno, mind one important detail: if you don't sign the contr
On Thu, Oct 17, 2013 at 4:12 PM, Nuno Oliveira <
[email protected]> wrote:
> Hi Aime,
>
> Sorry for the delay in my response and thanks for your tips.
>
> The version juggling was expected. I think it is a small price to pay to
> have a coherent
> release cycle.
>
Nice. Sorry fo
On Mon, Oct 14, 2013 at 10:15 PM, Nuno Oliveira <
[email protected]> 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 donat
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 ?
After reading some code I come to the conclusion that the only
restriction is defined
by the Stroke interfaces, i.e. org.open
25 matches
Mail list logo
