Hi,
I hope this is a simple one to answer, but my searches of mailing list archives have not yielded the answer yet.
I have a custom data source that contains layers with CRS WGS84(DD), which is actually provided by Geotools org.geotools.referencing.crs.DefaultGeographicCRS.WGS84. As you can see in the attached GeoServer screenshot, the Native SRS field is set to ‘UNKNOWN’ while just to the right of that we can see a link to ‘WGS84(DD)’. We have tried to trace the code in GeoServer, GeoTools and our own custom data source, and what we can see is that we are storing the CRS in a SimpleFeatureType, and it appears that GeoServer uses this to put the WGS84(DD) on the screen, but is not able to map this to the SRS, which I believe should be ‘EPSG:4326’ (http://spatialreference.org/ref/epsg/4326/).
If I type EPSG:4326 into the ‘Declared SRS’ field, then things work, otherwise we get NullPointerExceptions. However, I believe we should not have to do this. The layer returns the correct CRS, so thing should ‘just work’, right?
Regards, Craig
(attachments)
Hey Craig,
This is a common case in GeoServer/GeoTools when you have a CRS that doesn’t have any EPSG identifier metadata attached to it, such as DefaultGeographicCRS.WGS84. If you inspect DefaultGeographicCRS.WGS84.toWKT() you will see no EPSG identifier. Compare that to org.geotools.referencing.CRS.decode(“EPSG:4326”).toWKT() which is the same CRS essentially, but with the EPSG metadata.
This is a common case. Many data sources like shapefiles are often accompanied by a projection definition that doesn’t have the EPSG metadata. Which is why in geoserver declaring the CRS manually is necessary.
The CRS class has a method on it named lookupEpsgCode. It takes a parameter named “fullScan” which when set to true will try to match a CRS to the epsg database.
Hope that helps.
-Justin
On Sat, Sep 8, 2012 at 10:40 AM, Craig Taverner <craig@anonymised.com> wrote:
Hi,
I hope this is a simple one to answer, but my searches of mailing list archives have not yielded the answer yet.
I have a custom data source that contains layers with CRS WGS84(DD), which is actually provided by Geotools org.geotools.referencing.crs.DefaultGeographicCRS.WGS84. As you can see in the attached GeoServer screenshot, the Native SRS field is set to ‘UNKNOWN’ while just to the right of that we can see a link to ‘WGS84(DD)’. We have tried to trace the code in GeoServer, GeoTools and our own custom data source, and what we can see is that we are storing the CRS in a SimpleFeatureType, and it appears that GeoServer uses this to put the WGS84(DD) on the screen, but is not able to map this to the SRS, which I believe should be ‘EPSG:4326’ (http://spatialreference.org/ref/epsg/4326/).
If I type EPSG:4326 into the ‘Declared SRS’ field, then things work, otherwise we get NullPointerExceptions. However, I believe we should not have to do this. The layer returns the correct CRS, so thing should ‘just work’, right?
Regards, Craig
Live Security Virtual Conference
Exclusive live event will cover all the ways today’s security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.