Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [udig-devel] net.refractions.udig.libs / geotools 2.6 issue
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 <gershwinou@xxxxxxxxx> wrote:
forgot the geootols list


---------- Forwarded message ----------
From: gershwinou <gershwinou@xxxxxxxxx>
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 <udig-devel@xxxxxxxxxxxxxxxxxxxxx>


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 <jody.garnett@xxxxxxxxx> 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 <gershwinou@xxxxxxxxx> 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 <jody.garnett@xxxxxxxxx> 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",
http://jira.codehaus.org/browse/UDIG-1686 > I have resolved it fixing the FeatureStoreResourceProperty.isTrue predicate. > Now the tools are enable when the layers have a FeatureStore as resource. But, > > I found that the creating and editing tools do not work. This is > http://jira.codehaus.org/browse/UDIG-1704 > Today, I will work in this issue, but my first idea is that the tools are using > the Ilayer.getResource method with parameter FeatureStore.class. Thus the > ShowViewInterceptor return a FeatureSource which is not compatible with > FeatrureStore.class. Finally getResource return null. > >> I >> would like to issue a second snapshot this week so we can be all >> sorted for when moovida returns and this I think was one of the high >> priofile issues left? > I agree. >> >> I also wanted to ask if this was a new problem or an old one. The >> reason I ask is that the "interceptors" responsible for applying the >> filter from the style blackboard are much more likely to be applied >> now that they have a user interface. This already caused trouble for >> WMS; I wonder if it may be the cause of some trouble for tools? > You are right, the interceptors are responsible of this bugs in the creating > and editing tools (the navigation tools look right). >> >> Jody > cheers > -- > Mauricio Pazos > www.axios.es

Back to the top