[Geoserver-devel] Geoserver REST API with FeatureTypes

Hi

I’m using the Geoserver REST API to upload a shapefile and later update the FeatureType information with some metadata.

After uploading the shapefile sucessfully, I can retrieve the related FeatureType (As stated in manual: “By default when a Shapefile is uploaded a feature type is automatically created.”) but updates to FeatureType using REST API seem not persisted.

The problem is that I can update the FeatureType using REST API and retrieve it again, getting the changes, but this FeatureType don’t appear in Geoserver Gui application and also restarting Geoserver and trying to retrieve again the FeatureType with the REST API returns an error indicating that the FeatureType don’t exists.

I’m forgeting any step?

The Geoserver version used is 1.7.6 with REST plugin on a Windows XP computer.

Thanks and regards,
Jose Garcia

My guess it is misconfigured in someway. Can you include the requests you are making in order to see the issue. What client are you using? cURL?

If you could send the shapefile that would be even better. One thing to check for is that it has a .prj file that defines the spatial reference system.

-Justin

jose garcia wrote:

Hi

I'm using the Geoserver REST API to upload a shapefile and later update the FeatureType information with some metadata.

After uploading the shapefile sucessfully, I can retrieve the related FeatureType (As stated in manual: "By default when a Shapefile is uploaded a feature type is automatically created.") but updates to FeatureType using REST API seem not persisted.

The problem is that I can update the FeatureType using REST API and retrieve it again, getting the changes, but this FeatureType don't appear in Geoserver Gui application and also restarting Geoserver and trying to retrieve again the FeatureType with the REST API returns an error indicating that the FeatureType don't exists.

I'm forgeting any step?

The Geoserver version used is 1.7.6 with REST plugin on a Windows XP computer.

Thanks and regards,
Jose Garcia

------------------------------------------------------------------------

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf

------------------------------------------------------------------------

_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Hi Justin

I used a custom .NET client, but also with curl happens (Attached is the shapefile used). It’s seems that the shapefile’s SRS is not recognized (i tested with other shapefiles using EPSG:4326 and it’s working ok). When try to load the file:

curl -u admin:geoserver -XPUT -H ‘Content-type: application/zip’ --data-binary @points.zip http://localhost:8080/geoserver/rest/workspaces/acme/datastores/points2/file.shp

The next exception is launched:

java.lang.NullPointerException
at org.geotools.referencing.CRS.decode(CRS.java:419)
at org.geotools.referencing.CRS.decode(CRS.java:348)
at org.vfny.geoserver.global.FeatureTypeInfo.getSRS(FeatureTypeInfo.java:1008)
at org.vfny.geoserver.global.FeatureTypeInfo.toDTO(FeatureTypeInfo.java:522)
at org.vfny.geoserver.global.Data.toDTO(Data.java:1604)
at org.geoserver.catalog.rest.CatalogResourceBase.saveCatalog(CatalogResourceBase.java:79)
at org.geoserver.catalog.rest.DataStoreFileResource.handlePut(DataStoreFileResource.java:289)

The datastore is created correctly (http://localhost:8080/geoserver/rest/workspaces/acme/datastores/points2.xml):


points2
true

acme
<atom:link xmlns:atom=“http://www.w3.org/2005/Atom” rel=“alternate” href=“http://localhost:8080/geoserver/rest/workspaces/acme.xml” type=“application/xml”/>


file:/usr/local/share/applications/geoserver-1.7.6/bin/…/data_dir/data/points2/points.shp
http://acme


<atom:link xmlns:atom=“http://www.w3.org/2005/Atom” rel=“alternate” href=“http://localhost:8080/geoserver/rest/workspaces/acme/datastores/points2/featuretypes.xml” type=“application/xml”/>

And also FeatureType seems created (http://localhost:8080/geoserver/rest/workspaces/acme/datastores/points2/featuretypes.xml):



points
<atom:link xmlns:atom=“http://www.w3.org/2005/Atom” rel=“alternate” href=“http://localhost:8080/geoserver/rest/workspaces/acme/datastores/points2/featuretypes/points.xml” type=“application/xml”/>

Consulting FeatureType, returns the information but nativeBoundingBox has a non valid CRS.
http://localhost:8080/geoserver/rest/workspaces/acme/datastores/points2/featuretypes/points.xml


points
points

acme
<atom:link xmlns:atom=“http://www.w3.org/2005/Atom” rel=“alternate” href=“http://localhost:8080/geoserver/rest/namespaces/acme.xml” type=“application/xml”/>


1559871.9815396431
2418958.5550883478
665893.1289851245
1250252.5336537217
EPSG:null


Indeed, when consulting the FeatureTypes using Geoserver GUI this FeatureType is not avalaible to edit (only is shown when you try to create a new FeatureType) and also restarting Geoserver is no longer avalaible.

Could be returned an error code when uploading the shapefile if it’s not reconigzed the CRS?

Regards,
Jose Garcia

On Mon, Sep 21, 2009 at 2:19 PM, Justin Deoliveira <jdeolive@anonymised.com.> wrote:

My guess it is misconfigured in someway. Can you include the requests you are making in order to see the issue. What client are you using? cURL?

If you could send the shapefile that would be even better. One thing to check for is that it has a .prj file that defines the spatial reference system.

-Justin

jose garcia wrote:

Hi

I’m using the Geoserver REST API to upload a shapefile and later update the FeatureType information with some metadata.

After uploading the shapefile sucessfully, I can retrieve the related FeatureType (As stated in manual: “By default when a Shapefile is uploaded a feature type is automatically created.”) but updates to FeatureType using REST API seem not persisted.

The problem is that I can update the FeatureType using REST API and retrieve it again, getting the changes, but this FeatureType don’t appear in Geoserver Gui application and also restarting Geoserver and trying to retrieve again the FeatureType with the REST API returns an error indicating that the FeatureType don’t exists.

I’m forgeting any step?

The Geoserver version used is 1.7.6 with REST plugin on a Windows XP computer.

Thanks and regards,
Jose Garcia



Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf



Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

(attachments)

points.zip (1.43 KB)

Hmmm... this is a tough one. The issue is not that the CRS is not understood it is just there is no matching epsg code for it. I could not find one that matches exactly the specified crs (state plan for ohio in feet). Do you have one you use.

If you do have an srs that you know can be used you can simply update the feature type after you upload the shapefile with a PUT. Something like:

<featureType>
   <srs>EPSG:...</srs>
</featureType>

But yeah... we could just have restconfig not allow the shapefile upload unless an epsg code can be obtained. It would be interesting to hear what others think of this.

jose garcia wrote:

Hi Justin

I used a custom .NET client, but also with curl happens (Attached is the shapefile used). It's seems that the shapefile's SRS is not recognized (i tested with other shapefiles using EPSG:4326 and it's working ok). When try to load the file:

curl -u admin:geoserver -XPUT -H 'Content-type: application/zip' --data-binary @points.zip http://localhost:8080/geoserver/rest/workspaces/acme/datastores/points2/file.shp

The next exception is launched:

java.lang.NullPointerException
    at org.geotools.referencing.CRS.decode(CRS.java:419)
    at org.geotools.referencing.CRS.decode(CRS.java:348)
    at org.vfny.geoserver.global.FeatureTypeInfo.getSRS(FeatureTypeInfo.java:1008)
    at org.vfny.geoserver.global.FeatureTypeInfo.toDTO(FeatureTypeInfo.java:522)
    at org.vfny.geoserver.global.Data.toDTO(Data.java:1604)
    at org.geoserver.catalog.rest.CatalogResourceBase.saveCatalog(CatalogResourceBase.java:79)
    at org.geoserver.catalog.rest.DataStoreFileResource.handlePut(DataStoreFileResource.java:289)

The datastore is created correctly (*http://localhost:8080/geoserver/rest/workspaces/acme/datastores/points2.xml*):

/<dataStore>
  <name>points2</name>
  <enabled>true</enabled>
  <workspace>
    <name>acme</name>
    <atom:link xmlns:atom="http://www.w3.org/2005/Atom&quot; rel="alternate" href="http://localhost:8080/geoserver/rest/workspaces/acme.xml&quot; type="application/xml"/>
  </workspace>
  <connectionParameters>
    <url>file:/usr/local/share/applications/geoserver-1.7.6/bin/../data_dir/data/points2/points.shp</url>
    <namespace>http://acme</namespace>
  </connectionParameters>
  <featureTypes>
    <atom:link xmlns:atom="http://www.w3.org/2005/Atom&quot; rel="alternate" href="http://localhost:8080/geoserver/rest/workspaces/acme/datastores/points2/featuretypes.xml&quot; type="application/xml"/>
  </featureTypes>
</dataStore>/

And also FeatureType seems created *(http://localhost:8080/geoserver/rest/workspaces/acme/datastores/points2/featuretypes.xml*):

/<featureTypes>
  <featureType>
    <name>points</name>
    <atom:link xmlns:atom="http://www.w3.org/2005/Atom&quot; rel="alternate" href="http://localhost:8080/geoserver/rest/workspaces/acme/datastores/points2/featuretypes/points.xml&quot; type="application/xml"/>
  </featureType>
</featureTypes>
/

Consulting FeatureType, returns the information but nativeBoundingBox has a non valid CRS.
*http://localhost:8080/geoserver/rest/workspaces/acme/datastores/points2/featuretypes/points.xml*

/<featureType>
  <name>points</name>
  <nativeName>points</nativeName>
  <namespace>
    <name>acme</name>
    <atom:link xmlns:atom="http://www.w3.org/2005/Atom&quot; rel="alternate" href="http://localhost:8080/geoserver/rest/namespaces/acme.xml&quot; type="application/xml"/>
  </namespace>
  <nativeBoundingBox>
    <minx>1559871.9815396431</minx>
    <maxx>2418958.5550883478</maxx>
    <miny>665893.1289851245</miny>
    <maxy>1250252.5336537217</maxy>
   * <crs class="projected">EPSG:null</crs>*
  </nativeBoundingBox>
  <latLonBoundingBox>
  ...
</featureType>
/

Indeed, when consulting the FeatureTypes using Geoserver GUI this FeatureType is not avalaible to edit (only is shown when you try to create a new FeatureType) and also restarting Geoserver is no longer avalaible.

Could be returned an error code when uploading the shapefile if it's not reconigzed the CRS?

Regards,
Jose Garcia

On Mon, Sep 21, 2009 at 2:19 PM, Justin Deoliveira <jdeolive@anonymised.com <mailto:jdeolive@anonymised.com>> wrote:

    My guess it is misconfigured in someway. Can you include the
    requests you are making in order to see the issue. What client are
    you using? cURL?

    If you could send the shapefile that would be even better. One thing
    to check for is that it has a .prj file that defines the spatial
    reference system.

    -Justin

    jose garcia wrote:

        Hi

        I'm using the Geoserver REST API to upload a shapefile and later
        update the FeatureType information with some metadata.

        After uploading the shapefile sucessfully, I can retrieve the
        related FeatureType (As stated in manual: "By default when a
        Shapefile is uploaded a feature type is automatically created.")
        but updates to FeatureType using REST API seem not persisted.

        The problem is that I can update the FeatureType using REST API
        and retrieve it again, getting the changes, but this FeatureType
        don't appear in Geoserver Gui application and also restarting
        Geoserver and trying to retrieve again the FeatureType with the
        REST API returns an error indicating that the FeatureType don't
        exists.

        I'm forgeting any step?

        The Geoserver version used is 1.7.6 with REST plugin on a
        Windows XP computer.

        Thanks and regards,
        Jose Garcia

        ------------------------------------------------------------------------

        ------------------------------------------------------------------------------
        Come build with us! The BlackBerry&reg; Developer Conference in
        SF, CA
        is the only developer event you need to attend this year.
        Jumpstart your
        developing skills, take BlackBerry mobile applications to market
        and stay ahead of the curve. Join us from November 9&#45;12,
        2009. Register now&#33;
        http://p.sf.net/sfu/devconf

        ------------------------------------------------------------------------

        _______________________________________________
        Geoserver-devel mailing list
        Geoserver-devel@lists.sourceforge.net
        <mailto: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.

Justin Deoliveira ha scritto:

Hmmm... this is a tough one. The issue is not that the CRS is not understood it is just there is no matching epsg code for it. I could not find one that matches exactly the specified crs (state plan for ohio in feet). Do you have one you use.

If you do have an srs that you know can be used you can simply update the feature type after you upload the shapefile with a PUT. Something like:

<featureType>
   <srs>EPSG:...</srs>
</featureType>

But yeah... we could just have restconfig not allow the shapefile upload unless an epsg code can be obtained. It would be interesting to hear what others think of this.

I think it's a good way to go, since otherwise the uploaded shapefile
is unusable.

In the web UI we assume the user knows, and delegate to him the specification of a good SRS, for the REST api, we should do the
same with the clients invoking it, either the CRS can be turned
into an official EPSG code, or the client will have to tell us.

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.