Hi all,
Not sure if this should have gone to the users list, but it seems like some change to GeoServer is warranted so I’ll bring it up here. I ran into some surprising behavior while investigating some issues with the GeoNode demo site (http://demo.geonode.org/ is the demo, see http://geonode.org/ if you’re curious about the GeoNode project.)
A user (hi Chris) attempted to upload some data in Shapefile format including a .prj file (the data was downloaded from the web here: http://sfpark.org/resources/disabled-parking-census-gis-data/). When a user uploads data to GeoNode, the first thing GeoNode does with it is attempt an upload to GeoServer via the REST API. For this dataset, GeoServer is able to parse the .prj, but it doesn’t correspond to any known projection in GeoServer’s EPSG:database. In this case GeoServer leaves the lat/lon bounding box null but publishes the layer anyway - causing errors for the next user to try and access the WMS GetCapabilities response[1]. GeoNode attempts to apply some heuristics here, but they are not reliable and uploading in GeoNode really doesn’t work well. It would be nice to be able to trigger calculation of the lat/lon bounding box through the rest API.
While investigating I took the same dataset and loaded into a GeoServer instance without the GeoNode extensions. I found that GeoServer was still unable to find an EPSG: identifier for the projection (no surprise there) but when I chose to “reproject native to declared,” the “lat/lon bounding box” field continued to contain values from the “native bounding box”. (Yes, I did click the “calculate” link.) I’ve attached a screenshot of the projection and bounding box settings for the layer. Is the lat/lon bounding box supposed to contain native values in this case? (And if so, can we change the UI to reflect that?)
With this configuration, I found that the WMS capabilities document contained a Layer like this:
tiger:DisabledParking_09162011
DisabledParking_09162011
DisabledParking_09162011
features
EPSG:4326
CRS:84
5979728.115160578
6017766.6348263305
2087141.1629708656
2122186.380455502
point
Default Point
A sample style that draws a point
image/png
http://opengeo.org/
(attachments)
On Tue, Feb 21, 2012 at 5:22 PM, David Winslow <dwinslow@anonymised.com1…> wrote:
Hi all,
Not sure if this should have gone to the users list, but it seems like some change to GeoServer is warranted so I’ll bring it up here. I ran into some surprising behavior while investigating some issues with the GeoNode demo site (http://demo.geonode.org/ is the demo, see http://geonode.org/ if you’re curious about the GeoNode project.)
A user (hi Chris) attempted to upload some data in Shapefile format including a .prj file (the data was downloaded from the web here: http://sfpark.org/resources/disabled-parking-census-gis-data/). When a user uploads data to GeoNode, the first thing GeoNode does with it is attempt an upload to GeoServer via the REST API. For this dataset, GeoServer is able to parse the .prj, but it doesn’t correspond to any known projection in GeoServer’s EPSG:database. In this case GeoServer leaves the lat/lon bounding box null but publishes the layer anyway - causing errors for the next user to try and access the WMS GetCapabilities response[1]. GeoNode attempts to apply some heuristics here, but they are not reliable and uploading in GeoNode really doesn’t work well. It would be nice to be able to trigger calculation of the lat/lon bounding box through the rest API.
I agree. This seems like an error in the REST api, though I believe we also have a level of protection in
terms of catalog validation that should probably also trigger when adding new layers programmatically?
Justin should be the expert in both areas.
While investigating I took the same dataset and loaded into a GeoServer instance without the GeoNode extensions. I found that GeoServer was still unable to find an EPSG: identifier for the projection (no surprise there) but when I chose to “reproject native to declared,” the “lat/lon bounding box” field continued to contain values from the “native bounding box”. (Yes, I did click the “calculate” link.) I’ve attached a screenshot of the projection and bounding box settings for the layer. Is the lat/lon bounding box supposed to contain native values in this case? (And if so, can we change the UI to reflect that?)
In the case you’re reporting it definitely should not, it’s a bug. Patch appreciated 
With this configuration, I found that the WMS capabilities document contained a Layer like this:
tiger:DisabledParking_09162011
DisabledParking_09162011
DisabledParking_09162011
features
EPSG:4326
CRS:84
5979728.115160578
6017766.6348263305
2087141.1629708656
2122186.380455502
point
Default Point
A sample style that draws a point
image/png
–
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549
http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf
I don’t have much to add, just echo Andreas comments and indeed patches would be welcome.
On Sat, Feb 25, 2012 at 1:39 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:
On Tue, Feb 21, 2012 at 5:22 PM, David Winslow <dwinslow@anonymised.com> wrote:
Hi all,
Not sure if this should have gone to the users list, but it seems like some change to GeoServer is warranted so I’ll bring it up here. I ran into some surprising behavior while investigating some issues with the GeoNode demo site (http://demo.geonode.org/ is the demo, see http://geonode.org/ if you’re curious about the GeoNode project.)
A user (hi Chris) attempted to upload some data in Shapefile format including a .prj file (the data was downloaded from the web here: http://sfpark.org/resources/disabled-parking-census-gis-data/). When a user uploads data to GeoNode, the first thing GeoNode does with it is attempt an upload to GeoServer via the REST API. For this dataset, GeoServer is able to parse the .prj, but it doesn’t correspond to any known projection in GeoServer’s EPSG:database. In this case GeoServer leaves the lat/lon bounding box null but publishes the layer anyway - causing errors for the next user to try and access the WMS GetCapabilities response[1]. GeoNode attempts to apply some heuristics here, but they are not reliable and uploading in GeoNode really doesn’t work well. It would be nice to be able to trigger calculation of the lat/lon bounding box through the rest API.
I agree. This seems like an error in the REST api, though I believe we also have a level of protection in
terms of catalog validation that should probably also trigger when adding new layers programmatically?
Justin should be the expert in both areas.
While investigating I took the same dataset and loaded into a GeoServer instance without the GeoNode extensions. I found that GeoServer was still unable to find an EPSG: identifier for the projection (no surprise there) but when I chose to “reproject native to declared,” the “lat/lon bounding box” field continued to contain values from the “native bounding box”. (Yes, I did click the “calculate” link.) I’ve attached a screenshot of the projection and bounding box settings for the layer. Is the lat/lon bounding box supposed to contain native values in this case? (And if so, can we change the UI to reflect that?)
In the case you’re reporting it definitely should not, it’s a bug. Patch appreciated
With this configuration, I found that the WMS capabilities document contained a Layer like this:
tiger:DisabledParking_09162011
DisabledParking_09162011
DisabledParking_09162011
features
EPSG:4326
CRS:84
5979728.115160578
6017766.6348263305
2087141.1629708656
2122186.380455502
point
Default Point
A sample style that draws a point
image/png
http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
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.