History | Log In     View a printable version of the current page.  
Issue Details (XML | Word | Printable)

Key: GEOT-928
Type: Improvement Improvement
Status: Open Open
Priority: Major Major
Assignee: Andrea Aime
Reporter: Andrea Aime
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
GeoTools

Handle projections validity area in Decimator and StreamingRenderer classes

Created: 20/Aug/06 07:49 AM   Updated: 20/Aug/06 07:49 AM
Component/s: core render
Affects Version/s: 2.3.0
Fix Version/s: None


 Description  « Hide
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_______________________________________________________________________



 All   Comments   Change History      Sort Order: Ascending order - Click to sort in descending order
There are no comments yet on this issue.