Hi all,

I know the release and moving from Codehaus are likely taking lots of folks' cycles... I wanted to bump this thread. What kind of timeline are we on for getting the matrix branch merged into master?

I've got a pr for fixing the outstanding build issues right around GeneralMatrix here: https://github.com/geotools/geotools/pull/813. Jody mentioned that Tyler might have some time to track down other vecmath usage.

After that, is there anything outstanding?

Thanks in advance,

Jim

On 04/10/2015 01:43 AM, Jody Garnett wrote:
IllegalArgumentException is good (and the message is descriptive enough).

We are generally okay with adding new features to master, and then after a month back porting (as long as the change is additive and does not effect compatibility). This is however a pretty major change, which does effect API for downstream apps.

I have no ability to predict LocationTech IP timelines (sigh) - if needed we can make a 14-M1 milestone release to the maven repository.



--
Jody Garnett

On 9 April 2015 at 15:08, Jim Hughes <jn...@ccri.com <mailto:jn...@ccri.com>> wrote:

    Hi Jody,

    Yeah, I'm glad that I'm caught up enough to work on this again!

    EJML throws an IllegalArgumentException rather than a
    MismatchedSizeException when trying to invert an n x m matrix
    (where n != m).  If that change is sensible, we can use it;
    otherwise, there's already a NoninvertibleTransformException.

    Do we think we're in a good spot for this to make it into GeoTools
    13.1?

    Cheers,

    Jim


    On 04/09/2015 05:56 PM, Jody Garnett wrote:
    Great to hear from you Jim :) Proposal is being transferred to
    github
    (https://github.com/geotools/geotools/wiki/change-from-vecmath-to-ejml)
    so you could not update it right now anyways :)

    There were a couple more tasks in the proposal, Tyler was working
    on removing the vecmath dependency (providing us with some
    exceptions and data structures to replace).

    From earlier in this email thread - we need to find replacements
    for the following:

    * Point3d - can probably use one of the java classes or roll our
    own here
    * MismatchedSizeException - IllegalStateException may work or
    perhaps we have a CRS exception we can recycle...

    Example of broken files:

    * org.geotools.math.Line
    * org.geotools.math.Plane



    --
    Jody Garnett

    On 9 April 2015 at 13:50, Jim Hughes <jn...@ccri.com
    <mailto:jn...@ccri.com>> wrote:

        Hi all,

        I finally grabbed a few minutes to bang away on the vecmath
        transition; check out a PR into the matrix branch here:
        https://github.com/geotools/geotools/pull/813. I tracked down
        the existing test failures; 3 changes to GeneralMatrix.java
        and an update of the exception to catch in
        ProjectiveTransform.java made everything go.

        Additionally, I started a GeneralMatrixTest file.  It isn't
        complete, and I'm hoping that its current state is
        beneficial.  I am quite happy for someone else to pitch in
        some more test cases; it was a helpful exercise is
        understanding some of the details of the constructors and
        various functions.

        As an amusement, I noticed that getRow is private and getCol
        is public.

        Anyhow, apologies for not updating the proposal to reflect
        the idea of adding test coverage for GeneralMatrix.

        What else remains to get all this merged in?  If there are
        any formatting concerns, lemme know.

        Thanks,

        Jim


        On 03/14/2015 09:24 PM, Jody Garnett wrote:
        I think you are doing the coordination right now on this
        email thread ( the tasks section of the proposal is also good).

        I like your idea to make a general matrix testing master -
        add that to the tasks section of the proposal and stick your
        initials next to it if you are in position to volunteer.

        I hope other PMC members can review the plan and vote.
        On Sat, Mar 14, 2015 at 3:12 PM Jim Hughes <jn...@ccri.com
        <mailto:jn...@ccri.com>> wrote:

            Hi all,

            Jody, Tyler, and I hacked at this on Friday during a
            code sprint.  The partial results are here:
            https://github.com/geotools/geotools/commits/matrix

            There are a few remaining errors to track down, and the
            cautious part of me wants to go back and cook up a set
            of unit tests for GeneralMatrix.

            Anyhow, since we are all traveling for the next few
            days, I wanted to ask what the best way to coordinate
            future effort is?

            If anyone else is interested pitching in, let us know.

            Thanks,

            Jim

            p.s.  The commits from an 'Alex Tatusko' are from me.  I
            goofed up and didn't change the Git info on a loaner laptop.


            On 03/13/2015 03:55 PM, Jody Garnett wrote:
            A bit more research shows we should support the
            geotools Matrix and XMatrix methods (giving us a
            limited set of methods to implement). Proposal updated
            accordingly ...

            --
            Jody Garnett

            On 13 March 2015 at 12:31, Andrea Aime
            <andrea.a...@geo-solutions.it
            <mailto:andrea.a...@geo-solutions.it>> wrote:

                On Fri, Mar 13, 2015 at 7:57 PM, Jody Garnett
                <jody.garn...@gmail.com
                <mailto:jody.garn...@gmail.com>> wrote:

                    At the foss4gna code sprint, here is a proposal
                    to make this change:
                    
http://docs.codehaus.org/display/GEOTOOLS/Change+from+vecmath+to+EJML


                    Looking at this with Jim, the library has
                    DenseMatrix64F (which does the work) and an
                    example of wrapping this up for normal use
                    called SimpleMatrix.

                    Each operation in SimpleMatrix makes a copy, an
                    overhead we could avoid by using DenseMatrix64F
                    ourself. So the proposal is to delegate to
                    DenseMatrix64F, using SimpleMatrix (and its
                    friend BaseMatrix) as a guide.

                    Alternatively we could kill our GeneralMatrix
                    class and use SimpleMatrix directly in the rest
                    of the GeoTools codebase, it would be more an
                    an API change - which is okay if people only
                    see this stuff inside MathTransforms. Anyone
                    got an idea on how visible GeneralMatrix is?


                I don't... and guess we should try to keep it
                around. Anyways, the direction appears to be sound,
                no objections.

                Cheers
                Andrea


-- ==
                GeoServer Professional Services from the experts! Visit
                http://goo.gl/NWWaa2 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 <tel:%2B39%200584%20962313>
                fax: +39 0584 1660272 <tel:%2B39%200584%201660272>
                mob: +39  339 8844549 <tel:%2B39%20%C2%A0339%208844549>

                http://www.geo-solutions.it
                http://twitter.com/geosolutions_it

                *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

                Le informazioni contenute in questo messaggio di
                posta elettronica e/o nel/i file/s allegato/i sono
                da considerarsi strettamente riservate. Il loro
                utilizzo è consentito esclusivamente al
                destinatario del messaggio, per le finalità
                indicate nel messaggio stesso. Qualora riceviate
                questo messaggio senza esserne il destinatario, Vi
                preghiamo cortesemente di darcene notizia via
                e-mail e di procedere alla distruzione del
                messaggio stesso, cancellandolo dal Vostro sistema.
                Conservare il messaggio stesso, divulgarlo anche in
                parte, distribuirlo ad altri soggetti, copiarlo, od
                utilizzarlo per finalità diverse, costituisce
                comportamento contrario ai principi dettati dal
                D.Lgs. 196/2003.

                The information in this message and/or attachments,
                is intended solely for the attention and use of the
                named addressee(s) and may be confidential or
                proprietary in nature or covered by the provisions
                of privacy act (Legislative Decree June, 30 2003,
                no.196 - Italy's New Data Protection Code).Any use
                not in accord with its purpose, any disclosure,
                reproduction, copying, distribution, or either
                dissemination, either whole or partial, is strictly
                forbidden except previous formal approval of the
                named addressee(s). If you are not the intended
                recipient, please contact immediately the sender by
                telephone, fax or e-mail and delete the information
                in this message that has been received in error.
                The sender does not give any warranty or accept
                liability as the content, accuracy or completeness
                of sent messages and accepts no responsibility for
                changes made after they were sent or for other
                risks which arise as a result of e-mail
                transmission, viruses, etc.


                -------------------------------------------------------




            
------------------------------------------------------------------------------
            Dive into the World of Parallel Programming The Go Parallel 
Website, sponsored
            by Intel and developed in partnership with Slashdot Media, is your 
hub for all
            things parallel software development, from weekly thought 
leadership blogs to
            news, videos, case studies, tutorials and more. Take a look and 
join the
            conversation now.http://goparallel.sourceforge.net/


            _______________________________________________
            GeoTools-Devel mailing list
            GeoTools-Devel@lists.sourceforge.net  
<mailto:GeoTools-Devel@lists.sourceforge.net>
            https://lists.sourceforge.net/lists/listinfo/geotools-devel

            
------------------------------------------------------------------------------
            Dive into the World of Parallel Programming The Go
            Parallel Website, sponsored
            by Intel and developed in partnership with Slashdot
            Media, is your hub for all
            things parallel software development, from weekly
            thought leadership blogs to
            news, videos, case studies, tutorials and more. Take a
            look and join the
            conversation now.
            
http://goparallel.sourceforge.net/_______________________________________________
            GeoTools-Devel mailing list
            GeoTools-Devel@lists.sourceforge.net
            <mailto:GeoTools-Devel@lists.sourceforge.net>
            https://lists.sourceforge.net/lists/listinfo/geotools-devel





------------------------------------------------------------------------------
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
_______________________________________________
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Reply via email to