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
>
>
------------------------------------------------------------------------------
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
