Hello all I'm back on the mailing list, but it will take a while before I become up to date with the ~300 geotools emails...
Adrian Custer a écrit : > I've been working on the 'Georeferencing' chapter for the user manual. Cool!!!! Thanks a lot for doing that. > I've gotten a long way towards an outline, something like: > > Background: > Overview: CRS's and Operations > Warnings: 2d only/ axis order issue/ Spatial error size > Resources: Standards / Literature / Web > Code: Layout / Packaging / FactorySystem+GeoAPI / > premade Note: The referencing module (as well as GeoAPI interfaces) are not 2D only. They can be 3D and 4D as well, with Z and time axis. What is not yet fully implemented is "ellipsoidal to geoidal height conversions". There is some partial work in the recently added referencing3D module, but this is not yet completed. However, some other kinds of 3D conversions like "ellipsoidal (lat,long,height) to geocentric (X,Y,Z)" already work. Time axis also work (at least a minimal time support - it could be more elaborated). > The Class Hierarchy: > Units: JSR-108 vs. JSR-275 (JScience) Note that JSR-275 is an evolution of JSR-108. Both of them were mostly written by the same author (Jean-Marie Dautelle). We will also replace JSR-108 by JSR-275, so it may not be worth to put too much emphasis about JSR-108 (which is officially dead anyway). One issue we may face is that JSR-275 target Java 1.5 (but a port to Java 1.4 would probably be possible if Java 1.5 still a blocker issue for Geotools). > Math Notation: > ------------- > EPSG uses the notation of JPSnyder's "Map Projections - A working > manual". Is this what Geotools uses as well? If we are talking about the projection code in the org.geotools.referencing.operation.projection.MapProjection class and subclasses, Rueben Schulz is the best person who can answer this. But I believe that the code is close the Snyder's notation at least for local variable. But the protected fields in MapProjection has been renamed (since they appears in the javadoc) with more explicit names. For example "a" and "b" have been renamed as "semiMajor" and "semiMinor". However, the javadoc give the Synder names. Example: http://javadoc.geotools.fr/snapshot/org/geotools/referencing/operation/projection/MapProjection.html#semiMajor > Is there any place where the equations which are used are presented? I'm > especially interested in how the dimension reduction happens going from > a geocentered XYZ coordinate to the geographic 2D. Does this happen by > defining special matrices to augment/diminish the dimension? The equation are not documented - we need to check in the source code, which is not really convenient. However, again Rueben Schulz is probably the best contact person for topic related to projection equation. However, in the specific case of XYZ to geographic 2D mapping, this issue is outside the scope of projection. It is rather implemented in the org.geotools.referencing.operation.transform.Geocentric class. There is the rule: - Geocentric (X,Y,Z) <--> Geographic 3D (latitude,longitude,height) where "height" is height above the ellipsoid (not height above the geoid) are implemented and should work accuratly. Important: this will work only if the GeographicCRS uses a 3D EllipsoidCS, not a CompoundCRS with a 2D-GeographicCRS and a VerticalCRS. In a 3D EllipsoidCS, the height is always the height above the ellipsoid - it can't be any other kind of height. - Geocentric (X,Y,Z) <--> Geographic 2D (latitude,longitude) work as in previous point (--> Geographic 3D), but drops the height *after* the computation (so the height were taken in account for latitude,longitude computation). - Geocentric (X,Y,Z) <--> Geographic 3D (latitude,longitude,height) where "height" is height above the *geoid*: the "Geographic 3D" is actually an instance of CompoundCRS made of a 2D-GeographicCRS with a VerticalCRS, where the VerticalDatumType is VerticalDatumType.GEOIDAL. Geotools should apply the following transformation chain: Geocentric (X,Y,Z) <--> Geographic 3D (latitude,longitude,height above the ellipsoid) <--> Geographic 3D (latitude,longitude,heigth above the geoid) This is only the last step which is not yet fully implemented in geotools (the "height above the ellipsoid" <--> "height above the geoid" transform). It is partially implemented in the referencing3D module, but the work is not finished. However the first transformation step (Geocentric <--> Geographic 3D with height above the ellipsoid) is fully implemented. > EPSG tech note 7 part 1 page 11 has a diagram of the general case of > different CRS's and the steps to convert between them. Since GT2.2.x > only has 2D DirectPositions, persumably GT has operations only for a > subset of that diagram. Geotools 2.3 (and 2.2 too I believe) has GeneralDirectPosition, which is nD. > (1) What subset of that diagram does Gt perform? Only the > coordinate operations which are actually 2D -> 2D? No. Geotools is really nD, as long as the height is "height above the ellipsoid". Other kind of heights are not fully implemented. The question is not really "which coordinate operations are implemented", but "which coordinate operation *methods* are implemented" (i.e. not CoordinateOperation, but CoordinateOperationMethod object). A list of the later is available. Try to enter the following instruction from the command line: java org.geotools.referencing.operation.DefaultMathTransformFactory Note: if you are on windows, try the following: java org.geotools.referencing.operation.DefaultMathTransformFactory -encoding Cp850 Where "Cp850" is actually the output of the "chcp" DOS command. This -encoding Cp850 argument need to specified only once; Geotools will remember it. The above should display a list of all available operation method. Make sure that yours DOS command windows is large enough (something like 120 characters). The exact output depends on the plugin in the classpath. For example, you should have one more method is "plugin/referencing3D" is in the classpath. In order to get more information about a specific operation method, give this operation method in argument. Example: java org.geotools.referencing.operation.DefaultMathTransformFactory Mercator > (2) Transforms seem to go through earth centered cartesian > coordinates but is this, for GT2.2.x, actually > geographic2D -> geocentric (point on ellipsoid surface) -> > geographic2D? Does this happen only for Bursa-Wolf transforms? Close but not exactly. There is at least 3 different way to use Bursa-Wolf parameters: using "Molodenski" transform, "Abridged Molodenski" and "Geographic to geocentric" method. It pass through Geocentric CRS for datum shift using the later methods. For the two former (using "Molodenski"), the transformation is applied directly on the geographic CRS without passing through Geocentric, but with a slight loose of precision. Lets say that conceptually, Bura-Wolf parameters are always applied on Geocentric CRS (so a Geographic to Geocentric transform is applied automatically when necessary), but the "Molodenski" transform is a shortcut allowing to apply the transformation directly on Geographic CRS, without the "Geographic to Geocentric" step, at the cost of a small accuracy lost. > How to create / obtain coordinate operations? > >>From the CRSTutorial and javadocs, it's easy to create a 'transform' > that goes from CRS to CRS. > (1) is this possible for any CRS in the EPSG database and any > user defined CRS that has a complete toWGS84 information? It is possible as long as the CoordinateOperationMethod is known to Geotools (ie. is in the list of CoordinateOperationMethod shown by the above-cited java command). If the CoordinateOperationMethod is a known one, then it should work with user-specified CRS as well. In TOWGS84 information is not required in all case - only when the datum are not the same. If the datum are identical (where "identical" means having the same name or at least one), then there is no need for TOWGS84 (and it is actually ignored). One additional note: there is a problem about detecting if two datum name are actually for the same datum. Different softwares may use different name for the same datum. For this reason, Geotools has a list of aliases: http://svn.geotools.org/geotools/trunk/gt/module/referencing/src/org/geotools/referencing/factory/DatumAliasesTable.txt > How do we get operations from Geotools? > > (1) The CRSTutorial.java has the following: > MathTransformFactory mtFactory = > FactoryFinder.getMathTransformFactory(null); > ParameterValueGroup params = > mtFactory.getDefaultParameters("Hotine_Oblique_Mercator"); > where do we get a list of valid string parameters to get > pre-named parameter groups? Are these pulled from the EPSG > database or from some Geotools class? The parameters list can be obtained from the console using the above-cited "java" command. They can also be obtained programmatically using the ParameterDescriptorGroup API. From memory (I don't have the API at hand right now): descriptor = params.getDescriptor(); List l = descriptor.getParameterList(); // or something like that > (2) Are there static, pre-made CoordinateOperations? The available parameter for each CoordinateOperationMethod are static, build in the Java code of the coordinate operation method implementation. However the coordinate operation parameter *value* are fetch from the EPSG database. > How do I create coordinate operations by hand? > > I'm interested in creating a conversion, a conversion which is a > projection, and a transformation. > > (1) The CRSTutorial.java has the following: > MathTransformFactory mtFactory = > FactoryFinder.getMathTransformFactory(null); > ParameterValueGroup params = > mtFactory.getDefaultParameters("Hotine_Oblique_Mercator"); > Where does the magic string value come from, and where are > others defined? MathTransformFactory.getOperationMethods(); // from memory, something like that. This is the list displayed by "java org..." above. This list is constructed from the class found in META-INF/services/org.geotools.referencing.operation.MathTransformProvider. The main ones are: http://svn.geotools.org/geotools/trunk/gt/module/referencing/src/META-INF/services/org.geotools.referencing.operation.MathTransformProvider > (2) For each operation (perhaps specifically projection) like > that above, where does Gt2 define the parameters that are in the > group? The parameter (not the value, just the parameter definition) are hard-coded in the class implementing the specific projection. In Geotools implementation, they are almost always implemented in a "Provider" inner class, in a "PARAMETERS" field. Example: http://svn.geotools.org/geotools/trunk/gt/module/referencing/src/org/geotools/referencing/operation/projection/PlateCarree.java Parameters descriptors are hard-coded because the projection algorithm (i.e. the formluas) is hard-coded anyway, as Java code. > > (3) Can I get operations from the EPSG database, as in the > currently not working: > CoordinateOperationAuthorityFactory coaf = > FactoryFinder.getCoordinateOperationAuthorityFactory("EPSG",null); > CoordinateOperation co = > coaf.createCoordinateOperation(""); > //TODO find an operation code Try (note sure about the method name): List<String> codes = coaf.getAuthorityCodes(CoordinateOperationMethod.class); for (String code : codes) { String description = coaef.getDescription(code); System.out.println(description); } Martin. ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
