Package org.osgeo.proj
Usage example
Coordinate operations can be performed as below (a more complete example is available
here).
In this example, only the calls to Proj
static methods are specific to this implementation.
All other lines should work in the same way with any GeoAPI implementation.
Note that geographic coordinates are in latitude, longitude order,
as specified in the EPSG database and in agreement with centuries of practice.
CRSAuthorityFactory factory = Proj.getAuthorityFactory("EPSG"); CoordinateOperationFactory regops = Proj.getOperationFactory(null); CoordinateReferenceSystem sourceCRS = factory.createCoordinateReferenceSystem("4326"); // WGS 84 CoordinateReferenceSystem targetCRS = factory.createCoordinateReferenceSystem("3395"); // WGS 84 / World Mercator CoordinateOperation operation = regops.createOperation(sourceCRS, targetCRS); double[] coordinates = { 45.500, -73.567, // Montreal 49.250, -123.100, // Vancouver 35.653, 139.839, // Tokyo 48.865, 2.349 // Paris }; operation.getMathTransform().transform( coordinates, 0, // Source coordinates. coordinates, 0, // Target coordinates (in this case, overwrite sources). 4); // Number of points to transform. System.out.printf("Montreal: %11.1f %11.1f%n", coordinates[0], coordinates[1]); System.out.printf("Vancouver: %11.1f %11.1f%n", coordinates[2], coordinates[3]); System.out.printf("Tokyo: %11.1f %11.1f%n", coordinates[4], coordinates[5]); System.out.printf("Paris: %11.1f %11.1f%n", coordinates[6], coordinates[7]);
Performance considerations
Calls to createCoordinateOperation(…)
methods may be costly.
Developers should get a CoordinateOperation
instance only once
for a given pair of CoordinateReferenceSystem
s and keep that reference
as long as they may need it.
Calls to MathTransform.transform(…)
methods may also be costly.
Developers should avoid invoking those methods repeatedly for each point to transform.
For example it is much more efficient to invoke transform(double[], …)
only once
for an array of 4 points than to invoke that method 4 times (once for each point).
Above example shows the recommended way to use a transform.
Multi-threading
Unless otherwise noted in Javadoc, all classes are safe for use in multi-thread environment.
However there is a limit in the number of concurrent threads which can use efficiently the same
MathTransform
instance.
This limit can be controlled by assigning an integer to the
"org.osgeo.proj.maxThreadsPerInstance
" system property at startup time.
A low value does not necessarily block more threads from using a
MathTransform
concurrently,
but the extra threads may observe a performance degradation.
Conversely a too high value may retain more resources than necessary.
The current default value is 4.
Note that there is no limit on Java side in the amount of threads that can use different
MathTransform
instances concurrently.
String representation
Referencing objects such as CRS, datum, etc.
implement the IdentifiedObject.toWKT()
method,
which can be used for getting a string representation in Well Known Text (WKT) version 2 format.
The Object.toString()
method can also be used for getting a similar string representation,
but in a slightly simplified version.
Note that those string representations do not perform database access, and consequently may be less
complete than the formatting done by ReferencingFormat
.
Referencing objects also implement the Formattable
interface.
The "%s"
flag formats the object name, while the alternative form "%#s"
formats the authority (typically EPSG) code.
Unsupported features
The following method calls will cause an exception to be thrown:
CRSFactory.createFromXML(String)
— XML support requires GDAL.AuthorityFactory.getAuthorityCodes(Class)
— not yet implemented in this binding.CoordinateOperationFactory.createDefiningConversion(…)
— not yet implemented in this binding.DerivedCRS
— not yet implemented in this binding.MathTransform.derivative(DirectPosition)
— Jacobian matrix calculation is not yet supported by PROJ.ConcatenatedOperation
— not yet implemented explicitly in this binding (but concatenated operations created by PROJ still work).
- Since:
- 1.0
-
ClassDescriptionThe criterion to use for comparing PROJ objects.Optional information about the context in which a coordinate operation will be used.Describes how grid availability is used.Describes if and how intermediate CRS should be used.Thrown when an unit operation is requested but no JSR-385 implementation is found on the classpath.Static methods for coordinate reference systems and operations.Parses and format referencing objects in Well Known Text, JSON or PROJ format.Controls some aspects in formatting referencing objects as Well Known Text (WKT), JSON or PROJ strings.Specifies how source and target CRS extents should be used to restrict candidate operations.Spatial criterion to restrict candidate operations.Thrown when a PROJ object can not be formatted to Well Known Text (WKT), JSON or PROJ string.A set of predefined units of measurements used by PROJ.Thrown when a PROJ object can not be parsed from a Well Known Text (WKT), JSON or PROJ string.Thrown when a method can not execute because a given argument value is not a PROJ implementation.