Eeek - I am a bit scared to remove the JAI included by Apple (since it
probably makes use of some native code on their side).

Perhaps we could set up that USE_HACK as a Hint or flag for the
library. Gresh I am not the module maintainer on referencing so we are
going to have to hang out for a couple of weeks until Andrea gets back
from holiday and then go over options with him.

Thanks for digging in and sorting out where this problem comes from;
it would of driven me nuts. If possible we should sort out some clear
options for Andrea to choose from; or if you feel strongly about one
solution you could create a patch+testcase for review.

At the very least we now have enough to create a detailed and clear bug report.

Jody

On Thu, Jul 22, 2010 at 2:48 AM, gershwinou <[email protected]> wrote:
> ok so i partially solved the problem in removing the jai_core.jar installed
> by default on macosx (in the jvm) and using the geotools one instead. Don't
> know if this is a macosx problem or a geotools problem.
> However i think the USE_HACK flag should be accessible by the end user, in
> case he has a better algorithm to guess which version of jai is buggy or not
> gersh
>
> On Wed, Jul 21, 2010 at 14:05, gershwinou <[email protected]> wrote:
>>
>> forgot the geootols list
>>
>> ---------- Forwarded message ----------
>> From: gershwinou <[email protected]>
>> Date: Wed, Jul 21, 2010 at 13:21
>> Subject: Re: [udig-devel] net.refractions.udig.libs / geotools 2.6 issue
>> To: User-friendly Desktop Internet GIS <[email protected]>
>>
>>
>> ok more on it, the last trunk version has something new:
>> 2.6.0 is using a hack because the JAI warp2d is buggy
>> 2.6-SNAPSHOT is testing JAI build version, and if <1.1.3 it is using the
>> hack
>> when i check my JAI build, it tells me that the build version is
>> unavailable (i am on MACOSX) so WarpTransform2D is NOT using the hack, which
>> is wrong.
>> First of all the static field USE_HACK should be accessible, or at least
>> not final so i can change it using reflection...
>> Anyway to have it changed...
>> below the hack code in the last version:
>>
>> private final static boolean USE_HACK;
>>     static{
>>      final String buildVersion=JAI.getBuildVersion();
>>      final SimpleDateFormat df=  new SimpleDateFormat("yyyy-MM-dd'
>> 'hh:mm:ss.SSSZ");
>>      final TimeZone tz= TimeZone.getTimeZone("UTC");
>>      df.setTimeZone(tz);
>>      boolean hack=false;
>>      try {
>>                      final Date date_ = 
>> buildVersion!=null?df.parse(buildVersion):new
>> java.util.Date();
>>                      //reduce granularity to minute
>>                      final GregorianCalendar tempCal = new 
>> GregorianCalendar(tz);
>>                      tempCal.setTime(date_);
>>                      tempCal.set(Calendar.HOUR_OF_DAY, 0);
>>                      tempCal.set(Calendar.MINUTE, 0);
>>                      tempCal.set(Calendar.SECOND, 0);
>>                      tempCal.set(Calendar.MILLISECOND, 0);
>>                      final Date date=tempCal.getTime();
>>                      
>>                      // 113 version
>>                      final GregorianCalendar version113= new 
>> GregorianCalendar(tz);
>>                      version113.set(2006, 8, 12,0,0,0);
>>                      version113.set(Calendar.MILLISECOND, 0);
>>                      // we need the hacke only if we are using 1.1.3
>>                      hack=!date.after(version113.getTime());
>>              } catch (ParseException e) {
>>                      hack=false;
>>              }
>>              USE_HACK=hack;
>>     }
>>
>> gersh
>> On Wed, Jul 21, 2010 at 13:00, Jody Garnett <[email protected]>
>> wrote:
>>>
>>> Not me personally; I thought Andrea updated the EPSG database however?
>>> Jody
>>> On 21/07/2010, at 8:49 PM, gershwinou wrote:
>>>
>>> ok got the issue, i guess this is critical.
>>> i was using geotools 2.6.0 and it worked ok in my class. Downloaded 2.6.4
>>> and got the same error as the udig bundle (using 2.6-SNAPSHOT)
>>> any chances you have made some changes of the WarpTransform2D class in
>>> the between?
>>> gersh
>>>
>>> On Tue, Jul 20, 2010 at 16:51, gershwinou <[email protected]> wrote:
>>>>
>>>> well i added this line at startup of my working version but no change. I
>>>> also commented out the net.refractions.udig.libs activator line and there 
>>>> is
>>>> no change...
>>>> my geotools 2.6 is using hsql database, populating with epsg version 7.1
>>>> i cannot say for the udig bundles, i did not see the logs saying the
>>>> classical message about populating the database.
>>>> i am digging in.
>>>> Thanks a lot for your hints
>>>> - gersh
>>>> On Tue, Jul 20, 2010 at 15:49, Jody Garnett <[email protected]>
>>>> wrote:
>>>>>
>>>>> uDig flips the forceXY preference setting[1]:
>>>>>
>>>>> System.setProperty("org.geotools.referencing.forceXY", "true");
>>>>>
>>>>> Is there a chance that is messing you up? You could try doing this
>>>>> yourself and see if your 2.6 code produce the same answer?
>>>>> Other then that udig is using epsg-h2 (rather then the more common and
>>>>> stable epsg-hsql).  What are you using when you test geotools 2.6?
>>>>>
>>>>> Jody
>>>>> [1] http://docs.codehaus.org/display/GEOTDOC/The+axis+order+issue
>>>>>
>>>>> On 20/07/2010, at 11:15 PM, gershwinou wrote:
>>>>>
>>>>> I am cross-posting to geotools and udig, because i think both are
>>>>> concerned.
>>>>> So in a nutschell, i try to use geotools Warp2DTransform to perform
>>>>> warping from pixels coordinate to geographic coordinate. I have been using
>>>>> geotools for a while, but now i need to move geotools library to osgi 
>>>>> bundle
>>>>> (here comes udig).
>>>>> So i used net.refractions.udig.libs that have already done the work. I
>>>>> am checking out the trunk, ie using geotools-2.6-SNAPSHOT version.
>>>>> Using directly the geotools 2.6 with my classes, Warp2DTransform Works
>>>>> ok. I input a set of GCPs and get a correct transformation, of degree 3.
>>>>> Using the same class in the udig bundles, the results is totally wrong,
>>>>> ie the coefficients are very low. See the difference below. The funny 
>>>>> thing
>>>>> is that is that when i divide the outputs with prescales factors, i got
>>>>> results of the right order (ie coordinates around (43,12) instead
>>>>> of(0.006,0,001), but there are still wrong in the sense that coordinates 
>>>>> are
>>>>> very close to each others (order of 0.0001 degrees instead of degrees).
>>>>> any hints?
>>>>> geotools 2.6-SNAPSHOT/udig eclipse bundle (Wrong coeffs)
>>>>>
>>>>> PARAM_MT["WarpPolynomial",
>>>>>  PARAMETER["degree", 3],
>>>>>  PARAMETER["xCoeffs", {0.006612524390220642, 0.00000001603510035864,
>>>>> -0.00000000411600664663, -0.00000000000000079568, -0.00000000000000710382,
>>>>> -0.00000000000000444428, -0.00000000000000000005, -0.00000000000000000003,
>>>>> 0.00000000000000000026, 0.00000000000000000104}],
>>>>>  PARAMETER["yCoeffs", {-0.0015807533636689186, 0.00000000305463854211,
>>>>> 0.00000001448123754244, 0.00000000000000241329, -0.00000000000000179796,
>>>>> 0.00000000000000177312, 0.00000000000000000001, -0.00000000000000000001,
>>>>> -0.00000000000000000005, -0.00000000000000000025}],
>>>>>  PARAMETER["preScaleX", 0.0001521606754977256],
>>>>>  PARAMETER["preScaleY", 0.00012525050260592252],
>>>>>  PARAMETER["postScaleX", 0.9410438537597656],
>>>>>  PARAMETER["postScaleY", 1.0499610900878906]]
>>>>>
>>>>>
>>>>> geotools 2.6 (right Coeffs)
>>>>>
>>>>> PARAM_MT["WarpPolynomial",
>>>>> PARAMETER["degree", 3],
>>>>>    PARAMETER["xCoeffs", {46.180110931396484, 0.7821832299232483,
>>>>> -0.21910369396209717, -0.0004944244283251464, -0.0024764996487647295,
>>>>> 0.00076442607678473, -0.00001066674121830147, 0.0000213175590033643,
>>>>> 0.0001045847893692553, 0.00009047376806847751}],
>>>>>   PARAMETER["yCoeffs", {-12.020193099975586, 0.16218608617782593,
>>>>> 0.8374767303466797, 0.0009584086365066469, -0.0007706039468757808,
>>>>> 0.0001044207310769707, -0.0000068093295340077, -0.00006432097870856524,
>>>>> 0.00001632759085623547, -0.00000976871160673909}],
>>>>>   PARAMETER["preScaleX", 0.0001521606754977256],
>>>>>   PARAMETER["preScaleY", 0.00012525050260592252],
>>>>>   PARAMETER["postScaleX", 0.9410438537597656],
>>>>>   PARAMETER["postScaleY", 1.0499610900878906]]
>>>>>
>>>>> _______________________________________________
>>>>> User-friendly Desktop Internet GIS (uDig)
>>>>> http://udig.refractions.net
>>>>> http://lists.refractions.net/mailman/listinfo/udig-devel
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> User-friendly Desktop Internet GIS (uDig)
>>>>> http://udig.refractions.net
>>>>> http://lists.refractions.net/mailman/listinfo/udig-devel
>>>>>
>>>>
>>>
>>> _______________________________________________
>>> User-friendly Desktop Internet GIS (uDig)
>>> http://udig.refractions.net
>>> http://lists.refractions.net/mailman/listinfo/udig-devel
>>>
>>>
>>> _______________________________________________
>>> User-friendly Desktop Internet GIS (uDig)
>>> http://udig.refractions.net
>>> http://lists.refractions.net/mailman/listinfo/udig-devel
>>>
>>
>>
>
>
> _______________________________________________
> User-friendly Desktop Internet GIS (uDig)
> http://udig.refractions.net
> http://lists.refractions.net/mailman/listinfo/udig-devel
>
>

------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
Geotools-gt2-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users

Reply via email to