We really need to fix epsg-wkt since WMS is using it heavily (DBLASBY
AM I RIGHT?). Me or alessio could that but we need a bit of help and
maybe directions.
Geoserver currently uses the epsg-wkt jar. Its actually very easy to
use; I suggest you use the CRS class - you'll love the
CRS.decode(<wkt>) function.
CoordinateReferenceSystem crs = CRS.decode("EPSG:4326");
It'll automagically find your epsg-wkt.jar and read the .properties file
inside.
Lately I've been caching CRS's because decode() can be very expensive.
dave
----------------------------------------------------------
This mail sent through IMP: https://webmail.limegroup.com/
dblasby@anonymised.com a écrit :
CoordinateReferenceSystem crs = CRS.decode("EPSG:4326");
It'll automagically find your epsg-wkt.jar and read the .properties file
inside.
I have not yet reviewed the CRS decode method (it was not wrote by me), but I believe that it use the normal FactoryFinder mechanism. This means that it will use whatever EPSG factory it find, which may (or may not) be epsg-wkt.jar. Issues are:
- If more than one EPSG factories is present, epsg-wkt.jar appears in a
random order (other factories have deterministic order between them,
but epsg-wkt.jar was wrote by someone else than me prior the factory
ordering mechanism; I have not yet retroffited it into the ordering
mechanism). So sometime you get epsg-wkt.jar, sometime you get the
other JAR (e.g. epsg-access.jar).
- The problem is that there is a discrepencies between axis order in
epsg-wkt.jar and epsg-access.jar. Axis order in epsg-wkt.jar are
interchanged for some CRS, while epsg-access.jar have the right axis
order (if no bug on my side). So rendering may be flipped in any
direction depending which factory you got. CRS.decode(...) do not
changes anything to that.
Lately I've been caching CRS's because decode() can be very expensive.
It should be CRS.decode(...) work. Again, I will try to do that as part of my review when I will have the time.
Martin.