[geotk] Out of memory error when decoding CRS

[Martin Desruisseaux]

Le 25/05/11 11:47, Riou Olivier a écrit :
> The CRS I try to instantiate are WGS84 (epsg code 4326), WGS72 (epsg code 
> 4322), ED1950 (epsg code 4230), OSGB36 (epsg code 4277), OSSN80 (epsg code 
> 4279) and all UTM (epsg codes starting at 32600 and 32700) (epsg.properties in 
> attachment).
They look like "ordinary" CRS, and the epsg.properties file is not very big. I 
would expect the memory consumption to be reasonable in such case...
> I also have a mistake in my code because I was expecting that geotoolkit was 
> loading only my epsg.properties file but since I use the CRS.decode(...) 
> function, it also initialize the embedded database. When I remove the call to 
> this method and load a CRS through the PropertyEpsgFactory it does not 
> initialize the embedded database and use less memory.
Note that if you are using Maven, you can also avoid geotk-epsg dependency, in 
which case the database will not be created (but if it already exists, it will 
still be used). You can also remove Derby (a.k.a. JavaDB) dependencies if you 
don't use it, in which case you are sure that the embedded EPSG database will 
not be used.

If you are already using a database anyway, it may be worth to store the EPSG 
schema on that database. You can use the EpsgInstaller class for that purpose. 
Once the EPSG database has been installed, you can create a DataSource to that 
database and specify it to Geotk as below:

Hints.putSystemDefault(Hints.EPSG_DATA_SOURCE, datasource);


Alternatively you can also edit a epsg.properties file as documented here:
http://www.geotoolkit.org/apidocs/org/geotoolkit/referencing/factory/epsg/ThreadedEpsgFactory.html#CONFIGURATION_FILE

     Martin

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/geotoolkit/attachments/20110525/402fda99/attachment.html