Handle projections validity area in Decimator and StreamingRenderer classes
---------------------------------------------------------------------------
Key: GEOT-928
URL: http://jira.codehaus.org/browse/GEOT-928
Project: GeoTools
Issue Type: Improvement
Components: core render
Affects Versions: 2.3
Reporter: Andrea Aime
Assigned To: Andrea Aime
Geometries that go beyond the validity area of a map projection should be
handled instead of being dropped as done now.
The decimator and renderer classes should be modified to at least "cut" the
geometries inside the validity area.
This may be a direct cut, or may be done in a more clever way by:
- splitting geometries spanning beyond the date line and the poles
- offsetting the parts that go beyond so that the end on the other side of the
[-180,180,-90,90] envelope
- cutting the resulting geometries to stay inside the valid area.
Validity area is available for every projection that comes from an EPSG
database, Martin Desruisseax says:
___quote start
________________________________________________________________________
If all the following conditions are meet:
* epsg-hsql, epsg-access or epsg-postgresql is available in the classpath;
* The source and target CRS contain their EPSG code in their metadata (it
should always be the case if the CRS were created from an EPSG factory,
even if this factory was epsg-wkt);
* The "sourceCRS to targetCRS" transform is one of those that are explicitly
defined in the EPSG database (in the "Coordinate_Operation" table);
Then the "area of validity" should be defined as part of the
CoordinateOperation metadata. This area of validity can be defined in various
way, including string, geographic bounding box, envelope or arbitrary polygon
(all this flexibility is provided by the ISO 19115 "Extent" object). It sound
like that I didn't wrote a convenience method for extracting an envelope from a
CoordinateOperation - we should probably open a JIRA task as a remainder that
we should add such convenience method.
In the main time, there is a convenience method for extracting an envelope or a
geographic bounding box from a CRS. So the easier way to check the "area of
validity" of a transform is probably to invoke:
Envelope areaOfValidity = CRS.getEnvelope(operation.getTargetCRS());
Javadoc:
http://javadoc.geotools.fr/snapshot/org/geotools/referencing/CRS.html#getEnvelope(org.opengis.referencing.crs.CoordinateReferenceSystem)
Reminder: just in case you wonder what is the difference between an Envelope
(from ISO 19107) and a GeographicBoundingBox (from ISO 19115): the Envelope can
be in arbitrary CRS. The GeographicBoundingBox is garantee to be
(longitude,latitude) in something close to WGS84.
All the above work only for CRS or CoordinateOperation explicitly defined in
the EPSG database. If we want a general mechanism for computing the area of
validity of an unknown coordinate operation, this require some though. There is
no such general mechanism right now in Geotools.
___quote
end________________________________________________________________________
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-------------------------------------------------------------------------
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
