[Geoserver-users] [WFS-T] String length ignored in DescribeFeatureType for features stored in PostGIS?

Hi all,

I want to confirm if this is a bug, before I happily submit it to the issue tracker.

I’ve imported a shapefile into a PostGIS database. Here’s a part of the description:

Column | Type | Modifiers
------------±----------------------±---------------------------------------------------
gid | integer | not null default nextval(‘test_gid_seq’::regclass)
gm_code | character varying(16) |
gm_naam | character varying(30) |
postcode | character varying(11) |
dek_perc | bigint |
opp_tot | integer |
(omitted)
the_geom | geometry |
(My excuses for the bad formatting, if this occurs. I hope it will be readable enough.)

As you can see, there are a few strings, which have a maximum length.
Now, when I do a DescribeFeatureType on this feature (called pgtest:test), I’m gettting the following response:

<?xml version="1.0" encoding="UTF-8"?>

xs:complexContent
<xs:extension base=“gml:AbstractFeatureType”>
xs:sequence
<xs:element name=“gm_code” minOccurs=“0” nillable=“true”>
xs:simpleType
<xs:restriction base=“xs:string”>
<xs:maxLength value=“2147483647”/>
</xs:restriction>

</xs:simpleType>
</xs:element>
<xs:element name=“gm_naam” minOccurs=“0” nillable=“true”>
xs:simpleType
<xs:restriction base=“xs:string”>
<xs:maxLength value=“2147483647”/>
</xs:restriction>
</xs:simpleType>
</xs:element>

<xs:element name=“postcode” minOccurs=“0” nillable=“true”>
xs:simpleType
<xs:restriction base=“xs:string”>
<xs:maxLength value=“2147483647”/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element name=“dek_perc” minOccurs=“0” nillable=“true” type=“xs:long”/>
<xs:element name=“opp_tot” minOccurs=“0” nillable=“true” type=“xs:int”/>

<xs:element name=“the_geom” minOccurs=“0” nillable=“true” type=“gml:MultiPolygonPropertyType”/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:element name=‘test’ type=‘pgtest:test_Type’ substitutionGroup=‘gml:_Feature’/></xs:schema>

As you can see, the maxLength of the string properties (gm_code, gm_naam, postcode) are quite different from the values according to PostGIS. Is this a known issue? I couldn’t find any information on this in the issue tracker, and I had problems while searching this mailing list (but couldn’t find a hint either).

If I add the original shapefile as the datasource, the maxLength attributes contain the correct length.

This isn’t a problem while retrieving features, but it is for posting. I have entered a string which is too long (I didn’t think about the maxLength restriction), and Geoserver returned the following exception: wfs:Status<wfs:FAILED /></wfs:Status>wfs:MessageSome sort of database connection error: ERROR: value too long for type character varying(16)</wfs:Message>. Our software is able to cap the length of the entered string, based on the maxLength returned by DescribeFeatureType. The modifications are posted correctly, if the posted string value is short enough.

Regards,

Frank Steggink

Hi Frank,

I am not sure if this is a known issue or not but it definitely is an
issue. I suspect that the Postgis datastore is not relaying these
constraints properly and GeoServer is just throwing in some defaults.

I would say definitely open an issue in the tracker for it against
1.5.1. You can assign it to me.

-Justin

Frank.Steggink@anonymised.com wrote:

Hi all,

I want to confirm if this is a bug, before I happily submit it to the
issue tracker.

I've imported a shapefile into a PostGIS database. Here's a part of the
description:

   Column | Type | Modifiers
------------+-----------------------+----------------------------------------------------

gid | integer | not null default
nextval('test_gid_seq'::regclass)
gm_code | character varying(16) |
gm_naam | character varying(30) |
postcode | character varying(11) |
dek_perc | bigint |
opp_tot | integer |
(omitted)
the_geom | geometry |
(My excuses for the bad formatting, if this occurs. I hope it will be
readable enough.)

As you can see, there are a few strings, which have a maximum length.
Now, when I do a DescribeFeatureType on this feature (called
pgtest:test), I'm gettting the following response:

<?xml version="1.0" encoding="UTF-8"?><xs:schema
targetNamespace="http://www.example.org/pgtest&quot;
xmlns:pgtest="http://www.example.org/pgtest&quot;
xmlns:gml="http://www.opengis.net/gml&quot;
xmlns:xs="http://www.w3.org/2001/XMLSchema&quot;
elementFormDefault="qualified" attributeFormDefault="unqualified"
version="1.0"><xs:import namespace="http://www.opengis.net/gml&quot;
schemaLocation="http://127.0.0.1:8080/geoserver/schemas/gml/2.1.2/feature.xsd&quot;/&gt;&lt;xs:complexType
xmlns:xs="http://www.w3.org/2001/XMLSchema&quot; name="test_Type">

<xs:complexContent>
<xs:extension base="gml:AbstractFeatureType">
<xs:sequence>
<xs:element name="gm_code" minOccurs="0" nillable="true">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:maxLength value="2147483647"/>
</xs:restriction>

</xs:simpleType>
</xs:element>
<xs:element name="gm_naam" minOccurs="0" nillable="true">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:maxLength value="2147483647"/>
</xs:restriction>
</xs:simpleType>
</xs:element>

<xs:element name="postcode" minOccurs="0" nillable="true">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:maxLength value="2147483647"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element name="dek_perc" minOccurs="0" nillable="true" type="xs:long"/>
<xs:element name="opp_tot" minOccurs="0" nillable="true" type="xs:int"/>

<!-- Again, omitted a couple of properties -->

<xs:element name="the_geom" minOccurs="0" nillable="true"
type="gml:MultiPolygonPropertyType"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:element name='test' type='pgtest:test_Type'
substitutionGroup='gml:_Feature'/></xs:schema>

As you can see, the maxLength of the string properties (gm_code,
gm_naam, postcode) are quite different from the values according to
PostGIS. Is this a known issue? I couldn't find any information on this
in the issue tracker, and I had problems while searching this mailing
list (but couldn't find a hint either).

If I add the original shapefile as the datasource, the maxLength
attributes contain the correct length.

This isn't a problem while retrieving features, but it is for posting. I
have entered a string which is too long (I didn't think about the
maxLength restriction), and Geoserver returned the following exception:
<wfs:Status><wfs:FAILED /></wfs:Status><wfs:Message>Some sort of
database connection error: ERROR: value too long for type character
varying(16)</wfs:Message>. Our software is able to cap the length of the
entered string, based on the maxLength returned by DescribeFeatureType.
The modifications are posted correctly, if the posted string value is
short enough.

Regards,

Frank Steggink

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

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

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

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

--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com

Hi Justin,

Ok, I'll do that.
By the way, I forgot to add some version numbers. I'm using Geoserver
1.4.0 (should upgrade soon), and PostgreSQL 8.2.3 with PostGIS 1.2.1.

Frank

-----Original Message-----
From: Justin Deoliveira [mailto:jdeolive@anonymised.com]
Sent: Tuesday, April 17, 2007 13:29
To: Frank Steggink
Cc: geoserver-users@lists.sourceforge.net
Subject: Re: [Geoserver-users] [WFS-T] String length ignored in
DescribeFeatureType for features stored in PostGIS?

Hi Frank,

I am not sure if this is a known issue or not but it definitely is an
issue. I suspect that the Postgis datastore is not relaying these
constraints properly and GeoServer is just throwing in some defaults.

I would say definitely open an issue in the tracker for it against
1.5.1. You can assign it to me.

-Justin

Frank.Steggink@anonymised.com wrote:

Hi all,

I want to confirm if this is a bug, before I happily submit it to the
issue tracker.

I've imported a shapefile into a PostGIS database. Here's a part of
the
description:

   Column | Type | Modifiers
------------+-----------------------+---------------------------------
------------+-----------------------+-------------------

gid | integer | not null default
nextval('test_gid_seq'::regclass)
gm_code | character varying(16) |
gm_naam | character varying(30) |
postcode | character varying(11) |
dek_perc | bigint |
opp_tot | integer |
(omitted)
the_geom | geometry |
(My excuses for the bad formatting, if this occurs. I hope it will be
readable enough.)

As you can see, there are a few strings, which have a maximum length.
Now, when I do a DescribeFeatureType on this feature (called
pgtest:test), I'm gettting the following response:

<?xml version="1.0" encoding="UTF-8"?><xs:schema
targetNamespace="http://www.example.org/pgtest&quot;
xmlns:pgtest="http://www.example.org/pgtest&quot;
xmlns:gml="http://www.opengis.net/gml&quot;
xmlns:xs="http://www.w3.org/2001/XMLSchema&quot;
elementFormDefault="qualified" attributeFormDefault="unqualified"
version="1.0"><xs:import namespace="http://www.opengis.net/gml&quot;
schemaLocation="http://127.0.0.1:8080/geoserver/schemas/gml/2.1.2/feat
ure.xsd"/><xs:complexType xmlns:xs="http://www.w3.org/2001/XMLSchema&quot;
name="test_Type">

<xs:complexContent>
<xs:extension base="gml:AbstractFeatureType"> <xs:sequence>
<xs:element name="gm_code" minOccurs="0" nillable="true">
<xs:simpleType> <xs:restriction base="xs:string"> <xs:maxLength
value="2147483647"/> </xs:restriction>

</xs:simpleType>
</xs:element>
<xs:element name="gm_naam" minOccurs="0" nillable="true">
<xs:simpleType> <xs:restriction base="xs:string"> <xs:maxLength
value="2147483647"/> </xs:restriction> </xs:simpleType>
</xs:element>

<xs:element name="postcode" minOccurs="0" nillable="true">
<xs:simpleType> <xs:restriction base="xs:string"> <xs:maxLength
value="2147483647"/> </xs:restriction> </xs:simpleType>
</xs:element> <xs:element name="dek_perc" minOccurs="0"
nillable="true" type="xs:long"/> <xs:element name="opp_tot"
minOccurs="0" nillable="true" type="xs:int"/>

<!-- Again, omitted a couple of properties -->

<xs:element name="the_geom" minOccurs="0" nillable="true"
type="gml:MultiPolygonPropertyType"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:element name='test' type='pgtest:test_Type'
substitutionGroup='gml:_Feature'/></xs:schema>

As you can see, the maxLength of the string properties (gm_code,
gm_naam, postcode) are quite different from the values according to
PostGIS. Is this a known issue? I couldn't find any information on
this in the issue tracker, and I had problems while searching this
mailing list (but couldn't find a hint either).

If I add the original shapefile as the datasource, the maxLength
attributes contain the correct length.

This isn't a problem while retrieving features, but it is for posting.

I have entered a string which is too long (I didn't think about the
maxLength restriction), and Geoserver returned the following

exception:

<wfs:Status><wfs:FAILED /></wfs:Status><wfs:Message>Some sort of
database connection error: ERROR: value too long for type character
varying(16)</wfs:Message>. Our software is able to cap the length of
the entered string, based on the maxLength returned by

DescribeFeatureType.

The modifications are posted correctly, if the posted string value is
short enough.

Regards,

Frank Steggink

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

----------------------------------------------------------------------
--- This SF.net email is sponsored by DB2 Express Download DB2 Express

C - the FREE version of DB2 express and take control of your XML. No
limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

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

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

--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com