OK then, I'll use that for the correction then
But just for noting: the method CRS.lookupEpsgCode() did work fine with
all .prj files I have (and none of them contain the code, they're quite
like the one you described). But it only works when performing a full
scan, as happens with CRS.lookupIdentifier
Milton
Andrea Aime wrote:
>> SRID = CRS.lookupIdentifier(refSys, true);
>> if (SRID != null)
>> SRID = SRID.substring(SRID.indexOf(':')+1);
>>
>> If I understand it well, the advantage is that this will work even if
>> the authority being used (or the authority that has a matching code
>> for the refSys) is not the EPSG one, right?
>
> Yeah, but that's not the main advantage I see. If you have a feature
> type coming from a shapefile whose .prj contains:
> GEOGCS["GCS_WGS_1984",DATUM["WGS_1984",SPHEROID["WGS_1984",6378137,298.257223563]],PRIMEM["Greenwich",0],UNIT["Degree",0.017453292519943295]]
>
>
> the resulting CRS will have no identifier whatsoever, yet
> the above method should be able to identify it as 4326 anyways
> (provided "WGS_1984" is a valid EPSG datum identifier).
>
--
Milton Jonathan
Grupo GIS e Meio Ambiente
Tecgraf/PUC-Rio
Tel: +55-21-3527-2502
-------------------------------------------------------------------------
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
