Hey Jody, hey all

Well, thanks for the feedback (also, thanks Stefan for your reply).

Unfortunately, over here *nothing* seems to work for decoding EPSG CRS's 
with longitude first when using 2.6-M2
I tried:
- Deleting the HSQL database directory in tmp/Geotools/Databases/HSQL 
(as Stefan suggested)
- Setting the "org.geotools.referencing.forceXY" system property
- Setting the FORCE_LONGITUDE_FIRST_AXIS_ORDER hint
- Using CRS.decode("EPSG:4326", true)

Yep, nothing worked, not even the last one, and not only with SAD69 
(EPSG:4618), but ALSO with WGS84 (4326). I also tried crazy things like 
setting everything, a combination of them, and all kinds of other hints 
that don't really have much to do with it.

Anyway, I started to debug this, and it looks like something happened 
from 2.6-M1 to 2.6-M2 that changed the behavior of 
DefaultAuthorityFactory.getBackingFactory(boolean longitudeFirst), which 
is now always returing a factory with the FORCE_LONGITUDE_FIRST hint set 
to false (at least over here, but I don't know what I could have messed up).
What seems to be happening in that method is that yes, the first factory 
is OK, with the hint set to true, while other factories (HTTP, URN) have 
the hint set to false. That's OK (and was kinda like that before too), 
but when calling the ManyAuthoritiesFactory constructor, there is a code 
that keeps calling hints.putAll() for all the factories from first to 
last, thus overriding it. I checked for the previous version I have, and 
for some reason that same code did NOT override the hint in that case: 
it used to create a new entry for those additional factories, but I 
didn't fully understand why.

Anyway, my guess is that something changed in the definition of the hint 
keys that made this hints.putAll command start to override the original 
setting. Now, this seems quite critical because as it is there is no way 
for the user to set longitude first to true anymore..

In my particular case here, I did a little hack in my patched GeoTools 
to make things work (I'm just preventing those additional factories to 
be added in DefaultAuthorityFactory.getBackingFactory, since I don't use 
them), and we'll go for that now. But this looks really odd, and I think 
it would be great if you guys could take a look as soon as possible (or 
tell me I messed up big time with my GeoTools and somehow managed to get 
this weird behavior). Oh, just to let you know, I'm running this on 
Windows XP, but I really don't think it has anything to do with it.

Thanks for all,
Milton


Jody Garnett wrote:
> Hi Milton:
> 
> I ran into these problems as well when I updated uDig. I ended up 
> setting a system property to get the same effect. 
> 
> Here is the code I use to set up uDig:
>     // System properites work for controlling referencing behavior
>     // not so sure about the geotools global hints
>     //
>     System.setProperty("org.geotools.referencing.forceXY", "true"); 
> //$NON-NLS-1$ //$NON-NLS-2$
>         Map<Key, Boolean> map = new HashMap<Key, Boolean> ();
>     // these commented out hints are covered by the forceXY system property
> //
> //map.put( Hints.FORCE_LONGITUDE_FIRST_AXIS_ORDER, true );
>     //map.put( Hints.FORCE_STANDARD_AXIS_DIRECTIONS, true );
> //map.put( Hints.FORCE_STANDARD_AXIS_UNITS, true );
>     map.put( Hints.LENIENT_DATUM_SHIFT, true );
> Hints global = new Hints(map);
> 
> 
> You can see that I initially used Hints; and gave up when it was not 
> working.
> Jody
> 
> On 05/09/2009, at 3:26 AM, Milton Jonathan wrote:
> 
>> Hello people
>>
>> I've switched to GeoTools 2.6-M2 recently and (almost) everything is
>> nice. However, I found a problem that may be related to changed in the
>> HSQL database (or referencing code somewhere)
>>
>> The issue is related to using some CRS's that apparently have axis order
>> issues. In particular, CRS code 4618 (South American Datum 1969) used to
>> be switched (e.g., everybody uses it in longitude-first order but the
>> EPSG standard states the opposite).
>> Up to now, things worked by setting the
>> FORCE_LONGITUDE_FIRST_AXIS_ORDER, as in:
>>
>>  Hints.putSystemDefault(Hints.FORCE_LONGITUDE_FIRST_AXIS_ORDER, true);
>>
>> However, in 2.6-M2, the following behavior happens:
>>
>> - If I simply create a MapContext with EPSG:4618, as below
>>    map = new DefaultMapContext(CRS.decode("EPSG:4618"));
>>
>>   then the map is displayed as if rotated 90 degrees (you can use any
>> WGS84 shapefile to see this)
>>
>> - If I set the hint to TRUE, all remains the same, still rotated (this
>> used to fix the map)
>>
>> - If I set the hint to FALSE, I get a NoSuchAuthorityCodeException:
>> "Authority "EPSG" is unknown or doesn't match the supplied hints. Maybe
>> it is defined in an unreachable JAR file?"
>>
>> I haven't debugged this yet, but this last behavior is really strange.
>> Does anybody have a clue about it?
>>
>> Thanks
>> Milton
>>
>>
>> ------------------------------------------------------------------------------
>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 
>> 30-Day
>> trial. Simplify your report design, integration and deployment - and 
>> focus on
>> what you do best, core application coding. Discover what's new with
>> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>> _______________________________________________
>> Geotools-devel mailing list
>> [email protected] 
>> <mailto:[email protected]>
>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
> 

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Reply via email to