[Geoserver-devel] Woes with missing projections

GeoServer GeoServer Developer
1

As part of a project I'm working on I'm attempting to create a layer from a shapefile via GeoServer's REST API. Ostensibly the .prj file is optional, but if I upload a shapefile without the .prj I get a 500 error:

java.lang.NullPointerException
     at org.geoserver.gwc.GWCCatalogListener.getGrids(GWCCatalogListener.java:388)

but on subsequent requests the layer is visible via the REST API. Certain requests such as WMS GetCapabilities also fail with NullPointerExceptions.

I think the sequence of events is something like:

1. I upload a Shapefile without the .prj info
2. GeoServer attempts to autoconfigure it, but stops halfway through since without knowing the native projection, it cannot determine the lat/long bounding box.
3. GeoServer saves the partially configured layer.
4. GeoServer fires an event to all catalog listeners, some of which (in this specific case, the GWC cache updater) assume that layers will be fully configured. An exception is thrown and converted to a 500 status. However, the layer is already saved so it sticks around in the catalog to cause more havoc where GeoServer depends on having a known projection or latlon bounding box.

This seems like undesired behavior, but I'm not totally sure what would be correct. Should GeoServer just leave the layer disabled, or make a guess at some "generic" projection, or reject the upload entirely?

I think a better sequence would be:

1. I upload a Shapefile without the .prj info
2. GeoServer attempts to autoconfigure it, but stops halfway since it cannot determine the lat/long bounding box.
3. GeoServer saves the datastore, and leaves the partially configured layer disabled. A message reflecting this is sent back to the client (bonus points if said message includes the partial configuration so the client can simply tweak the broken bits).
4. The client makes up something for the missing fields (ideally by asking the user) and sends back a complete configuration.
5. Now, and only now, the listeners are notified of the new layer.

I can put some time into constructing a patch, but would like some feedback on my proposal before I get my hands too dirty. For my specific use case, all that would be really required would be to return a more specific error message so I can distinguish partial configurations from outright failures.

--
David Winslow
OpenGeo - http://opengeo.org/

2

Always a tricky problem. While there is code that is lenient and will not force that a projection or srs be specified, it usually ends up screwing over the user since as soon as they do use a projected coordinate system they are left wondering as they stare at a blank map.

I would throw an exception in cases where the crs can be determined. And since not having a .prj present is common allow for the user to specify a query string parameter to specify the crs manually.

This same problems comes up with POSTing a new feature type to an existing datastore. WHile I think the issue is still open the concensus was to check for a crs and throw an exception if not there.

2c.

-Justin

On 4/5/10 3:15 PM, David Winslow wrote:

As part of a project I'm working on I'm attempting to create a layer
from a shapefile via GeoServer's REST API. Ostensibly the .prj file is
optional, but if I upload a shapefile without the .prj I get a 500 error:

java.lang.NullPointerException
      at
org.geoserver.gwc.GWCCatalogListener.getGrids(GWCCatalogListener.java:388)

but on subsequent requests the layer is visible via the REST API.
Certain requests such as WMS GetCapabilities also fail with
NullPointerExceptions.

I think the sequence of events is something like:

1. I upload a Shapefile without the .prj info
2. GeoServer attempts to autoconfigure it, but stops halfway through
since without knowing the native projection, it cannot determine the
lat/long bounding box.
3. GeoServer saves the partially configured layer.
4. GeoServer fires an event to all catalog listeners, some of which (in
this specific case, the GWC cache updater) assume that layers will be
fully configured. An exception is thrown and converted to a 500
status. However, the layer is already saved so it sticks around in the
catalog to cause more havoc where GeoServer depends on having a known
projection or latlon bounding box.

This seems like undesired behavior, but I'm not totally sure what would
be correct. Should GeoServer just leave the layer disabled, or make a
guess at some "generic" projection, or reject the upload entirely?

I think a better sequence would be:

1. I upload a Shapefile without the .prj info
2. GeoServer attempts to autoconfigure it, but stops halfway since it
cannot determine the lat/long bounding box.
3. GeoServer saves the datastore, and leaves the partially configured
layer disabled. A message reflecting this is sent back to the client
(bonus points if said message includes the partial configuration so the
client can simply tweak the broken bits).
4. The client makes up something for the missing fields (ideally by
asking the user) and sends back a complete configuration.
5. Now, and only now, the listeners are notified of the new layer.

I can put some time into constructing a patch, but would like some
feedback on my proposal before I get my hands too dirty. For my
specific use case, all that would be really required would be to return
a more specific error message so I can distinguish partial
configurations from outright failures.

--
David Winslow
OpenGeo - http://opengeo.org/

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.