Details
-
Type:
Bug
-
Status:
Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 2.4.1, 2.5-M0
-
Component/s: referencing
-
Labels:None
Description
We need explicitly add in the use of getHorizontalCRS throughout the library:
CoordinateReferenceSystem crs3d = CRS.decode("EPSG:4327");
CoordinateReferenceSystem crs2d = CRS.getHorizontalCRS( crs3d );
This functionality is needed in two places:
- In PostGISDataStore when the Hints.FEAUTRE_2D hint is applied we need to generate a CRS that matchs the data with the 3d axis dropped
Other applications that are used to the 2D assumption will need ot make use of this functionality:
- In GeoServer when we generate lat/lon bbox we need to reproject from 3d data to WGS84
Issue Links
- is depended upon by
-
GEOT-528
GetFeatureRequest of 3D Point from PostGIS not working
-
-
GEOS-1765
Generate GML with 3D coordinates from PostGIS
-
-
GEOT-1716
CoordinateWriter and FeatureTypeTransformer unable to Generate 3D
-
- relates to
-
GEOT-401
CompoundCRS[Geographic/ProjectedCRS, VerticalCRS] should be treated as 3D-Geographic/ProjectedCRS
-
The extractions seems to work fine, thought I have a couple of issues:
* I'm not sure if the above way to build up the CR and CRS is the suggested one (and yes, I should move the list of known flat directions to a static variable)
* The resulting CRS seems good, but it does not equate to 4326, not even using CRS.equalsIgnoreMetadata. For this, try out the following snippet:
{code}
CoordinateReferenceSystem threeDim = CRS.decode("EPSG:4327");
CoordinateReferenceSystem flat = CRS.getHorizontalCRS(threeDim);
System.out.println("2D portion of 4327:\n" + flat);
System.out.println("4326:\n" + CRS.decode("EPSG:4326"));
System.out.println("Looking up EPSG code: " + CRS.lookupEpsgCode(flat, true));
System.out.println("2D portion of 4327 equals to 4326: "
+ CRS.equalsIgnoreMetadata(CRS.decode("EPSG:4326"), flat));
{code}
Having them equate would be the icing on the cake, but it's not necessary.
I would like to commit the patch if possible.