Martin wrote:
> You can still uses the above code by cheating with Java 5 generic type:
>
> Set<String> codes = csFactory.getAuthorityCodes((Class) Unit.class);
>
> You will get "unchecked cast" compiler warning, this is a deprecated
> practice, etc., but it will work for now.
Of course, should have thought of this myself. Indeed it still works. Thanks!
> We have no undeprecated methods for fetching the units at this time. The
> main
> reason is that the unit system is a totally independant library that we
> can't retrofit in the "IdentifiedObject" hierarchy.
I am well aware of this problem. My preferred solution would be following
method in the API:
csFactory.getAuthorityUnitCodes(Class<Quantity>Quantity)
This way I could also separately retrieve units of quantity "Length" or "Angle"
without having to filter them by EPSG number range afterwards.
> An other reason (maybe not a valid one) is that in current GeoTools
> implementation,
> the list of units that are really supported is hard-coded anyway.
Oh.
1. What's the reason for this? Can/should we do anything about it?
2. Where can I find this hardcoded list either in code or in the documentation?
Is it the set of units defined by JSR-275?
The point is that it would be irritating to give the user the choice for all
EPSG-supported units in a widget if GeoTools cannot handle some of them
afterwards.
--
Matthias Basler
[EMAIL PROTECTED]
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
