Looking into this further with the debugger, the
ProjectiveTransform.create( Matrix ) method is going astray looking at the
matrix:
Type = dense , numRows = 3 , numCols = 3
1.000 0.000 -0.000
0.000 1.000 0.000
0.000 0.000 1.000
Internally though the mat.data array looks like:
[1.0000000000000002, 0.0, -1.1641532182693481E-10,
0.0, 1.0000000000000002, 0.0,
0.0, 0.0, 1.0]
The GeneralMatrix.isIdentity() test is looking for strictly 0 or 1:
for (int j=0; j<numRow; j++) {
for (int i=0; i<numCol; i++) {
if (getElement(j,i) != (i==j ? 1 : 0)) {
return false;
}
}
}
While I could introduce an epislon, I doubt it is the right approach.
So where is the matrix created? DefaultCoordinateOperationFactory is
calling:
final Matrix linear = createLinearConversion(sourceCRS, targetCRS, EPS);
With EPS providing a tolerance of 1.0E-10.
The createLinearConversion matrix should be returning an identity matrix -
but is not. The following check appears to be failing:
targetScale = target.applyProjectedScale(targetScale);
sourceScale = source.applyProjectedScale(sourceScale);
sourceScale.invert();
targetScale.multiply(sourceScale);
if (targetScale.isIdentity(errorTolerance)) {
targetScale.setIdentity();
}
return targetScale;
The value -1.1641532182693481E-10 is out side of our error tollerance
of 1.0E-10.
Knocking back to 1.0E-9 has our test pass - although I am not sure if that
is a great idea.
--
Jody
--
Jody Garnett
On 28 April 2015 at 23:32, Jody Garnett <jody.garn...@gmail.com> wrote:
> I pushed up what I have so far, it all compiles.
>
> However I am getting test failures that highlight differences - as example
> MathTransformBuilderTest
>
> code = "2027";
> crs0 = factory0.createCoordinateReferenceSystem(code);
> crs1 = factory1.createCoordinateReferenceSystem(code);
> assertNotSame(crs0, crs1);
> assertSame(crs0.getCoordinateSystem(), crs1.getCoordinateSystem());
> assertSame(((SingleCRS) crs0).getDatum(), ((SingleCRS)
> crs1).getDatum());
> assertNotSame(((ProjectedCRS) crs0).getBaseCRS(), ((ProjectedCRS)
> crs1).getBaseCRS());
> assertFalse(crs0.getIdentifiers().isEmpty());
> if (METADATA_ERASED) {
> assertTrue(crs1.getIdentifiers().isEmpty());
> } else {
> assertEquals(crs0.getIdentifiers(), crs1.getIdentifiers());
> }
> mt = opFactory.createOperation(crs0, crs1).getMathTransform();
> assertTrue(mt.isIdentity());
>
> On master the resulting transform is the identity matrix ...
>
> but on the matrix branch it is coming out as:
>
> PARAM_MT["Affine",
>
> PARAMETER["num_row", 3],
>
> PARAMETER["num_col", 3],
>
> PARAMETER["elt_0_0", 1.0000000000000002],
>
> PARAMETER["elt_0_2", -0.00000000011641532183],
>
> PARAMETER["elt_1_1", 1.0000000000000002]]
>
>
> I am hoping we have a simple mistake ... somewhere and would love it if
> you have a chance to review.
>
>
> Jody
>
> --
> Jody Garnett
>
> On 28 April 2015 at 22:02, Jim Hughes <jn...@ccri.com> wrote:
>
>> Jody,
>>
>> Thanks! Shout if there's something else I can help with.
>>
>> Jim
>>
>>
>> On 04/28/2015 11:36 AM, Jody Garnett wrote:
>>
>> Thanks Jim, I have merged your pull request - and rebased that branch (so
>> you have a tricky git fetch to perform). I am going to go retrace tyler's
>> steps on removing all references to Vecmath and cleaning up any stray class
>> references.
>>
>>
>>
>> --
>> Jody Garnett
>>
>> On 20 April 2015 at 15:12, Jody Garnett <jody.garn...@gmail.com> wrote:
>>
>>> I think we have implemented XMatrix now, placed checkboxes on the tasks
>>> to indicate how far we are along.
>>>
>>> --
>>> Jody Garnett
>>>
>>> On 20 April 2015 at 11:10, Jim Hughes <jn...@ccri.com> wrote:
>>>
>>>> Jody,
>>>>
>>>> Thanks. If I'm reading it right, the code sprint and my PR should
>>>> finish up 3.
>>>>
>>>> Jim
>>>>
>>>>
>>>> On 04/20/2015 02:07 PM, Jody Garnett wrote:
>>>>
>>>> We have tracked down the other vecmath use (see earlier email).
>>>>
>>>> I have updated the tasks section on the proposal:
>>>> https://github.com/geotools/geotools/wiki/change-from-vecmath-to-ejml
>>>>
>>>> --
>>>> Jody Garnett
>>>>
>>>> On 20 April 2015 at 11:04, Jim Hughes <jn...@ccri.com> wrote:
>>>>
>>>>> 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> 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> 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> 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> wrote:
>>>>>>>>
>>>>>>>>> On Fri, Mar 13, 2015 at 7:57 PM, Jody Garnett <
>>>>>>>>> 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
>>>>>>>>> fax: +39 0584 1660272
>>>>>>>>> mob: +39 339 8844549
>>>>>>>>>
>>>>>>>>> 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
>>>>>>>> listGeoTools-Devel@lists.sourceforge.nethttps://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
>>>>>>>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>
------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
