[Open.ogc] Response 500 error from GeoServer
Micah Wengren
micah.wengren at noaa.gov
Fri Sep 27 16:40:08 UTC 2013
Hi John,
Yes, renaming should just rename the layer name, and title (if you used
the script approach). I'm not sure actually what would happen with the
underlying featuretype. I think in the case of a SQL view it would
change, but probably not for a table itself, since those are static.
Anyway, you should be able to see exactly what the names of your
featuretypes are with these URLs:
https://services.ogc.noaa.gov/geoserver/rest/workspaces/nmfs_st/datastores/postgis/featuretypes.html
https://services.ogc.noaa.gov/geoserver/rest/workspaces/nmfs_st/datastores/postgis/featuretypes.xml
Then, you can see all the details on an individual featuretype by going
to it's XML representation, for ex:
https://services.ogc.noaa.gov/geoserver/rest/workspaces/nmfs_st/datastores/postgis/featuretypes/communities_pgs20130920.xml
That will include the SQL query definition if it is a SQL view layer.
You can modify these programmatically by doing a POST (or use
'modify_featuretype' in the hpcc_data_requests.py script, which requires
you to point to an XML config file on disk with your changes). The
script approach for modifying is a little tricky, but I've used it quite
a bit for scripting changes in layers.
Deleting a layer with the script will delete the layer only (and not
associated featuretype), which I think is what happened before. I
modified the script slightly so that now you can do a delete_featuretype
request and it will delete both the featuretype and the associated
layer(s) (which are built off of featuretype). In the case of SQL
views, layers to featuretypes are 1:1, for layers built off of tables
directly, can be many:1.
Whether you delete things with the script or the Web UI, the underlying
database table will still be there, with fixed schema as in before. The
table row values should still be there as well. The only way to see db
tables is by going to the 'New Layer' page, afaik.
Micah
On 9/27/2013 11:19 AM, John Kennedy - NOAA Affiliate wrote:
> Thanks Micah, that did the trick. I was able to upload a shape file
> and then rename the layer. What I noticed is that rename only changes
> the name and title of the layer, not the name of the source. Which I
> think I was confused about earlier. Do I dare try deleting the
> layer/source using hpcc_data_request and attempting a new upload of
> the shape file? I suspect I would get the same error as we dealt with
> earlier in the week.
>
> John F. Kennedy, PhD, CPG
> GIS Specialist
> Contractor: Caelum Corp.
> NOAA Fisheries Office of Science and Technology
> 1315 East-West Highway
> SSMC3 Rm 9518
> Silver Spring, MD 20910
> 301-427-8149
>
> Comments? Have I been of assistance? Please let my supervisors know. :~)
> Tim Haverland - NOAA Federal <Tim.Haverland at noaa.gov
> <mailto:Tim.Haverland at noaa.gov>>
> Hussain Jabalpurwala - NOAA Affiliate <hussain.jabalpurwala at noaa.gov
> <mailto:hussain.jabalpurwala at noaa.gov>>
>
>
> On Fri, Sep 27, 2013 at 10:53 AM, Micah Wengren
> <micah.wengren at noaa.gov <mailto:micah.wengren at noaa.gov>> wrote:
>
> John,
>
> I took a quick look in the logs, and I see something about a SQL
> query maybe based on a non-existant table (probably not likely the
> cause though):
>
> Caused by: java.io.IOException: Error occured calculating bounds
> at
> org.geotools.jdbc.JDBCDataStore.getBounds(JDBCDataStore.java:1173)
> at
> org.geotools.jdbc.JDBCFeatureSource.getBoundsInternal(JDBCFeatureSource.java:501)
> ... 96 more
> Caused by: org.postgresql.util.PSQLException: ERROR: relation
> "nmfs_st.communities_pgs20130920" does not exist
> Position: 82
> at
> org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2062)
> at
> org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1795)
> at
> org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:257)
>
> And also something about a database connection problem, that may
> be more likely the cause:
>
> Caused by: java.io.IOException: Error occured on rollback
> at
> org.geotools.jdbc.JDBCTransactionState.rollback(JDBCTransactionState.java:100)
> at
> org.geotools.data.DefaultTransaction.rollback(DefaultTransaction.java:225)
> at
> org.geoserver.catalog.rest.DataStoreFileResource.handlePut(DataStoreFileResource.java:365)
> ... 87 more
> Caused by: java.sql.SQLException: Connection is closed.
> at
> org.apache.commons.dbcp.PoolingDataSource$PoolGuardConnectionWrapper.checkOpen(PoolingDataSource.java:185)
> at
> org.apache.commons.dbcp.PoolingDataSource$PoolGuardConnectionWrapper.rollback(PoolingDataSource.java:322)
> at
> org.geotools.jdbc.JDBCTransactionState.rollback(JDBCTransactionState.java:97)
> ... 89 more
>
> Can you try the upload again? I disabled/re-enabled the data
> store, which might help.
>
> Micah
>
>
> On 9/27/2013 10:43 AM, John Kennedy - NOAA Affiliate wrote:
>> Hi Micah,
>>
>> I attempted to load a shape file this morning using
>> hpcc_data_request.py scritp and I'm getting a Response 500 error
>> from GeoServer. Any ideas?
>>
>> Cheers,
>> John
>>
>>
>>
>> John F. Kennedy, PhD, CPG
>> GIS Specialist
>> Contractor: Caelum Corp.
>> NOAA Fisheries Office of Science and Technology
>> 1315 East-West Highway
>> SSMC3 Rm 9518
>> Silver Spring, MD 20910
>> 301-427-8149 <tel:301-427-8149>
>>
>> Comments? Have I been of assistance? Please let my supervisors
>> know. :~)
>> Tim Haverland - NOAA Federal <Tim.Haverland at noaa.gov
>> <mailto:Tim.Haverland at noaa.gov>>
>> Hussain Jabalpurwala - NOAA Affiliate
>> <hussain.jabalpurwala at noaa.gov
>> <mailto:hussain.jabalpurwala at noaa.gov>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://list.woc.noaa.gov/pipermail/open.ogc/attachments/20130927/ab0d32ab/attachment-0001.html>
More information about the Open.ogc
mailing list