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 for my delayed response, when I have spare time to look in
community stuff I normally
look at pull requests and jira tickets, lost track of this one.


> I have to implement the dash-array expression support for 9.5 version of
> Geotools.
> So basically I create a patch for 9.5 version and another for 11-SNAPSHOT
> version (I send them in attach). I create a fork from 9.5 version and
> apply the patch
> and so on ...
>
> Talking about the patch. The main change was that the stroke dash-array
> property is now represented
> as an expression instead of an array of floats, this mostly implies a lot
> of direct refactoring. However
> two not so direct situations occurs:
>
> * The first is related with the parsing\writing of SLDs. Since the
> dash-array is now an expression
> I think the parsing and writing of its value should follow the same
> principle of the other expressions,
> i.e. at some point it should be delegated to a ConverterFactory. Based on
> this I create a new ConverterFactory
> that produces two converters one from String to float[] and another from
> float[] to String. I don't
> know if this is the best solution, but having to handle explicitly all
> conversions from float[] to string
> and vice-versa seems a little sloppy.
>
>
Yes, I agree, seems like a good approach to me.


>
> * The second situation occurs in the rescale visitor. At some point we
> have to multiply
> the dash-array property by a scale factor. I keep the original solution
> i.e. we explicitly handle
> the float[] array and multiply it by the scale factor, however this
> approach have some problems.
> The main issue (in my opinion) is, since we don't produce a multiply
> expression, this will only work
> if the scale expression and the dash-array expression are both literals,
> otherwise the dash-array
> expression is returned as is. The only solution I find for this is to
> implement for add/div/sub/mul
> expressions the support for arrays of numerical values. What is your
> opinion about this ?
>
>
I'd create a filter function that knows how to multiply an array of floats
by a constant, and pass the
array and the scale factor as arguments to it. This should work regardless
of where the float array
is coming from (e.g., can be a Literal, or can be coming from a feature
attribute, another function,
and so on).

>
>  Talking about formally contributing this code.
> I think I would need some help to do the proposition to the PMC.
>

The proposals (current and past) are stored here:
http://docs.codehaus.org/display/GEOTOOLS/Proposals

In order to write one you'll need access to the wiki, which you have to
request:
* create an account on xircles.codehaus.org, if you don't have one already
* go to the geotools page on xircles, ask to become a developer of
geotools, tell us when you
  have done the request so that we can accept you (we don't get automatic
notifications)

Once you have the account, go to this page,
http://docs.codehaus.org/display/GEOTOOLS/11.x, click
on the create button, use the "proposal" template and fill it in with yours.
Then ask for a discussion/vote on this mailing list.



> 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

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

-------------------------------------------------------
------------------------------------------------------------------------------
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
_______________________________________________
GeoTools-Devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Reply via email to