[Geoserver-users] Outputformat SHAPE-ZIP in geoserver-1.5.3

GeoServer GeoServer User
1

Hello geoserver-users,

I'm trying to download a zipped shapefile using geoserver 1.5.3 with an
Oracle 10g2 database server, but the size of the resulting file is
always 0 byte. Unfortunately, geoserver does not throw any exceptions,
so I'm quite puzzled where the problem might be.

Has anybody experienced the same problems? Maybe it's related to the
Oracle datastore?

BR,

Tilman Klar
Software Developer Strategic Research
Gaston Crommenlaan 4, bus 0501
9050 Gent, Belgium
+32 (0) 9244 9033 direct
http://www.teleatlas.com

Email Confidentiality:
This email and any files transmitted with it are confidential and
intended solely for the use of the individual(s) or entity to whom they
are addressed. If you are not the intended recipient you should not
read, disseminate, distribute or copy this email. Please notify sender
immediately by email if you have received this email by mistake and
delete this email from your system. Thank you.

2

Tilman Klar ha scritto:

Hello geoserver-users,

I'm trying to download a zipped shapefile using geoserver 1.5.3 with an
Oracle 10g2 database server, but the size of the resulting file is
always 0 byte. Unfortunately, geoserver does not throw any exceptions,
so I'm quite puzzled where the problem might be.

Has anybody experienced the same problems? Maybe it's related to the
Oracle datastore?

I kind of remember seeing something similar, but no, I don't know
how to address this. Is the same request using GML2 format working fine?
Can you send me the result of the DescribeFeaturetype request on
the same layer?

Cheers
Andrea

3

Hi Andrea,

yes, both GML2 and GML2-GZIP work flawlessy. I'll attach the
DescribeFeatureType document and a GML2 export (with maxFeatures=1) to
this mail.

BR,
Tilman

PS.: Maybe you have seen this in the mail '[Geoserver-users] output
format SHAPe-ZIP corrupt' (dated Fri, 25 May 2007 10:32:21 +0200)?

On Mon, 2007-10-15 at 17:45 +0200, Andrea Aime wrote:

Tilman Klar ha scritto:
> Hello geoserver-users,
>
> I'm trying to download a zipped shapefile using geoserver 1.5.3 with an
> Oracle 10g2 database server, but the size of the resulting file is
> always 0 byte. Unfortunately, geoserver does not throw any exceptions,
> so I'm quite puzzled where the problem might be.
>
> Has anybody experienced the same problems? Maybe it's related to the
> Oracle datastore?

I kind of remember seeing something similar, but no, I don't know
how to address this. Is the same request using GML2 format working fine?
Can you send me the result of the DescribeFeaturetype request on
the same layer?

Cheers
Andrea

wfs_describe_featuretype.xml (4.3 KB)

wfs_maxfeatures_1.xml (1.46 KB)

4

Tilman Klar ha scritto:

Hi Andrea,

yes, both GML2 and GML2-GZIP work flawlessy. I'll attach the
DescribeFeatureType document and a GML2 export (with maxFeatures=1) to
this mail.

I think I know what's going on. In the describe feature type there is:
<xs:element name="GEOM" minOccurs="0" nillable="true" type="gml:GeometryAssociationType" />

So, Oracle does not have the metadata necessary to know what kind of
geometry is contained in the geometric column, and a generic "geometry"
shapefile cannot be created.

More info here:
http://jira.codehaus.org/browse/GEOS-1124

Cheers
Andrea

5

From reading the bug report (GEOS-1124) I'm a bit puzzled what this

could mean for the SHAPE-ZIP export. I recreated the spatial index on
the featuretype, adding 'LAYER_GTYPE=POINT' as parameter, but the
problem still persists. The entry inside USER_SDO_GEOM_METADATA is
correct and the table is unversioned.

BR,
Tilman

On Mon, 2007-10-15 at 18:00 +0200, Andrea Aime wrote:

Tilman Klar ha scritto:
> Hi Andrea,
>
> yes, both GML2 and GML2-GZIP work flawlessy. I'll attach the
> DescribeFeatureType document and a GML2 export (with maxFeatures=1) to
> this mail.

I think I know what's going on. In the describe feature type there is:
<xs:element name="GEOM" minOccurs="0" nillable="true"
type="gml:GeometryAssociationType" />

So, Oracle does not have the metadata necessary to know what kind of
geometry is contained in the geometric column, and a generic "geometry"
shapefile cannot be created.

More info here:
http://jira.codehaus.org/browse/GEOS-1124

Cheers
Andrea

6

Tilman Klar ha scritto:

From reading the bug report (GEOS-1124) I'm a bit puzzled what this

could mean for the SHAPE-ZIP export. I recreated the spatial index on
the featuretype, adding 'LAYER_GTYPE=POINT' as parameter, but the
problem still persists. The entry inside USER_SDO_GEOM_METADATA is
correct and the table is unversioned.

So if you do a describe feature now you're getting the proper
geometry type?
Cheers
Andrea

7

No, it’s exactly the same output as before.

BR,
Tilman

-----Original Message-----
From: Andrea Aime [mailto:aaime@anonymised.com]
Sent: Mon 10/15/2007 6:39 PM
To: Tilman klar
Cc: geoserver-users@lists.sourceforge.net
Subject: Re: [Geoserver-users] Outputformat SHAPE-ZIP in geoserver-1.5.3

Tilman Klar ha scritto:

From reading the bug report (GEOS-1124) I’m a bit puzzled what this
could mean for the SHAPE-ZIP export. I recreated the spatial index on
the featuretype, adding ‘LAYER_GTYPE=POINT’ as parameter, but the
problem still persists. The entry inside USER_SDO_GEOM_METADATA is
correct and the table is unversioned.

So if you do a describe feature now you’re getting the proper
geometry type?
Cheers
Andrea

8

Tilman klar ha scritto:

No, it's exactly the same output as before.

Can you force a reload of the Oracle datastore by doing
apply and save or, if there is nothing to save, just
"load" in the administrative interface, and check again?

Cheers
Andrea

9

Right after I made the changes, I hit and , but it still gives the same results in the DescribeFeatureType response. :confused:

BR,
Tilman

-----Original Message-----
From: Andrea Aime [mailto:aaime@anonymised.com]
Sent: Mon 10/15/2007 8:14 PM
To: Tilman klar
Cc: geoserver-users@lists.sourceforge.net
Subject: Re: [Geoserver-users] Outputformat SHAPE-ZIP in geoserver-1.5.3

Tilman klar ha scritto:

No, it’s exactly the same output as before.

Can you force a reload of the Oracle datastore by doing
apply and save or, if there is nothing to save, just
“load” in the administrative interface, and check again?

Cheers
Andrea

10

Tilman klar ha scritto:

Right after I made the changes, I hit <Apply> and <Save>, but it still gives the same results in the DescribeFeatureType response. :confused:

Any chance you can send me part of that table? 10 records would be
ok. As insert statements, including the create tables, if you have a tool doing that... or else, a dump made with "exp" or something similar... not sure what I can get, I just switched from 10.2 to
Oracle Express because the former was using too much resources
on my PC.

Cheers
Andrea

11

Okay, here we go: Find my SQL export attached to this email (I hope this
works on Oracle Express). I found out that the tables I imported did not
have primary keys, so I created them first to see if it changes
anything. Unfortunately, DescribeFeatureType still gives the same output
and the resulting shape-zip still is a file of 0 bytes.

BTW, I'm testing with these URLs:
/geoserver/wfs?request=DescribeFeatureType&typename=mona3d:SHAPEZIP_EXP
/geoserver/wfs?request=GetFeature&typename=mona3d:SHAPEZIP_EXP&service=wfs&outputformat=SHAPE-ZIP

BR,
Tilman

On Mon, 2007-10-15 at 21:25 +0200, Andrea Aime wrote:

Tilman klar ha scritto:
> Right after I made the changes, I hit <Apply> and <Save>, but it still
> gives the same results in the DescribeFeatureType response. :confused:

Any chance you can send me part of that table? 10 records would be
ok. As insert statements, including the create tables, if you have a
tool doing that... or else, a dump made with "exp" or something
similar... not sure what I can get, I just switched from 10.2 to
Oracle Express because the former was using too much resources
on my PC.

Cheers
Andrea

shapezipe_exp.sql (5.94 KB)

12

Tilman Klar ha scritto:

Okay, here we go: Find my SQL export attached to this email (I hope this
works on Oracle Express). I found out that the tables I imported did not
have primary keys, so I created them first to see if it changes
anything. Unfortunately, DescribeFeatureType still gives the same output
and the resulting shape-zip still is a file of 0 bytes.

BTW, I'm testing with these URLs:
/geoserver/wfs?request=DescribeFeatureType&typename=mona3d:SHAPEZIP_EXP
/geoserver/wfs?request=GetFeature&typename=mona3d:SHAPEZIP_EXP&service=wfs&outputformat=SHAPE-ZIP

Hi,
I think I've found out what was going on and fixed it.
If you want to try out you can wait for today's nightly at http://geo.openplans.org/nightly/1.5.x/.

Otherwise, if you just want to go on, the issue is triggered by the
spatial reference system you are using, 8307, which is not
an official epsg code. If you use an official epsg code in the same
table things should work ok even with 1.5.3.

Cheers
Andrea

13

Hi,

okay, I'll try to use the nightly build tomorrow.

BTW: I'm using SRS 4326 inside geoserver. The Tele Atlas oracle product
comes in SRID 8307 (which is not the official code, but the same
projection). When modifying the SQL export I sent you earlier today to
use SRS 4326 instead of 8307, the same problem still persists. Aside
from that, if this would work, I would still have to update every single
geometry stored inside the oracle database (a few hundred GB) - or would
it be enough to recreate the entries in USER_SDO_GEOM_METADATA with SRS
4326?

BR,
Tilman

On Tue, 2007-10-16 at 11:41 +0200, Andrea Aime wrote:

Tilman Klar ha scritto:
> Okay, here we go: Find my SQL export attached to this email (I hope this
> works on Oracle Express). I found out that the tables I imported did not
> have primary keys, so I created them first to see if it changes
> anything. Unfortunately, DescribeFeatureType still gives the same output
> and the resulting shape-zip still is a file of 0 bytes.
>
> BTW, I'm testing with these URLs:
> /geoserver/wfs?request=DescribeFeatureType&typename=mona3d:SHAPEZIP_EXP
> /geoserver/wfs?request=GetFeature&typename=mona3d:SHAPEZIP_EXP&service=wfs&outputformat=SHAPE-ZIP

Hi,
I think I've found out what was going on and fixed it.
If you want to try out you can wait for today's nightly at
http://geo.openplans.org/nightly/1.5.x/.

Otherwise, if you just want to go on, the issue is triggered by the
spatial reference system you are using, 8307, which is not
an official epsg code. If you use an official epsg code in the same
table things should work ok even with 1.5.3.

Cheers
Andrea

14

Tilman Klar ha scritto:

Hi,

okay, I'll try to use the nightly build tomorrow.

BTW: I'm using SRS 4326 inside geoserver. The Tele Atlas oracle product
comes in SRID 8307 (which is not the official code, but the same
projection). When modifying the SQL export I sent you earlier today to
use SRS 4326 instead of 8307, the same problem still persists.

Strange... or maybe not. Can you try restart geoserver and test again?

> Aside

from that, if this would work, I would still have to update every single
geometry stored inside the oracle database (a few hundred GB) - or would
it be enough to recreate the entries in USER_SDO_GEOM_METADATA with SRS
4326?

The fixed version should work with whatever SRID you have declared
in Oracle, provided you force 4326 in the GeoServer UI.
Let me know if it works for you.
Cheers
Andrea

15

Hi Andrea,

sorry for the delay on that - I haven't been in the office yesterday.

I fetched the newest nightly build and installed it some minutes ago.
When recreating the spatial indexes, specifying LAYER_GTYPE as geometry,
this build works for shapezip-export when dealing with the types POINT
and POLYGON. Great work, thanks!

However, when trying to export data with the type LINESTRING, I'm
running into the same problems as before (empty file).

I'm attaching a very simple testcase which should cause this behaviour.

BR,
Tilman

On Tue, 2007-10-16 at 14:09 +0200, Andrea Aime wrote:

Tilman Klar ha scritto:
> Hi,
>
> okay, I'll try to use the nightly build tomorrow.
>
> BTW: I'm using SRS 4326 inside geoserver. The Tele Atlas oracle product
> comes in SRID 8307 (which is not the official code, but the same
> projection). When modifying the SQL export I sent you earlier today to
> use SRS 4326 instead of 8307, the same problem still persists.

Strange... or maybe not. Can you try restart geoserver and test again?

> Aside
> from that, if this would work, I would still have to update every single
> geometry stored inside the oracle database (a few hundred GB) - or would
> it be enough to recreate the entries in USER_SDO_GEOM_METADATA with SRS
> 4326?

The fixed version should work with whatever SRID you have declared
in Oracle, provided you force 4326 in the GeoServer UI.
Let me know if it works for you.
Cheers
Andrea

linestring.sql (661 Bytes)

16

Tilman Klar ha scritto:

Hi Andrea,

sorry for the delay on that - I haven't been in the office yesterday.

I fetched the newest nightly build and installed it some minutes ago.
When recreating the spatial indexes, specifying LAYER_GTYPE as geometry,
this build works for shapezip-export when dealing with the types POINT
and POLYGON. Great work, thanks!

However, when trying to export data with the type LINESTRING, I'm
running into the same problems as before (empty file).

I'm attaching a very simple testcase which should cause this behaviour.

It seems to be causing a different one here.
I cannot even compute the bbox, what I get is:

SELECT MDSYS.SDO_AGGR_MBR(GEOM) FROM "LINESTRING"

Error: java.sql.SQLException: ORA-06502: PL/SQL: errore di numero o valore
ORA-06512: a "MDSYS.SDO_CONSTRUCT_DIM_ARRAY", line 33
ORA-06512: a "MDSYS.SDOAGGR", line 24
ORA-06512: a "MDSYS.AGGRMBR", line 14
, SQL State: 65000, Error Code: 6502

I tried to modify the table creation statement a bit but I keep on getting the same errors no matter what, it seems SDO_AGGR_MBR does
not like this linestring...

Yet, I have other linestring data and I think I've spotted another
couple of bugs related to the Oracle/shapezip output combination,
both having to do with CRS handling:
http://jira.codehaus.org/browse/GEOT-1521
http://jira.codehaus.org/browse/GEOS-1413

I'm fixing both of them as I write this mail. Can you grab today's
nightly (generated during the european afternoon) and see if this
one works for you?
Cheers
Andrea

17

Sure, will grab the nightly this evening and test it.
BTW, SDO_AGGR_MBR works like a charm over here:

---cut---
SQL> SELECT SDO_UTIL.TO_WKTGEOMETRY(MDSYS.SDO_AGGR_MBR(GEOM)) FROM
      "LINESTRING"

SDO_UTIL.TO_WKTGEOMETRY(MDSYS.SDO_AGGR_MBR(GEOM))
-------------------------------------------------------
POLYGON ((1.0 1.0, 2.0 1.0, 2.0 2.0, 1.0 2.0, 1.0 1.0))
---cut---

Tilman

On Thu, 2007-10-18 at 11:36 +0200, Andrea Aime wrote:

Tilman Klar ha scritto:
> Hi Andrea,
>
> sorry for the delay on that - I haven't been in the office yesterday.
>
> I fetched the newest nightly build and installed it some minutes ago.
> When recreating the spatial indexes, specifying LAYER_GTYPE as geometry,
> this build works for shapezip-export when dealing with the types POINT
> and POLYGON. Great work, thanks!
>
> However, when trying to export data with the type LINESTRING, I'm
> running into the same problems as before (empty file).
>
> I'm attaching a very simple testcase which should cause this behaviour.

It seems to be causing a different one here.
I cannot even compute the bbox, what I get is:

SELECT MDSYS.SDO_AGGR_MBR(GEOM) FROM "LINESTRING"

Error: java.sql.SQLException: ORA-06502: PL/SQL: errore di numero o valore
ORA-06512: a "MDSYS.SDO_CONSTRUCT_DIM_ARRAY", line 33
ORA-06512: a "MDSYS.SDOAGGR", line 24
ORA-06512: a "MDSYS.AGGRMBR", line 14
, SQL State: 65000, Error Code: 6502

I tried to modify the table creation statement a bit but I keep on
getting the same errors no matter what, it seems SDO_AGGR_MBR does
not like this linestring...

Yet, I have other linestring data and I think I've spotted another
couple of bugs related to the Oracle/shapezip output combination,
both having to do with CRS handling:
http://jira.codehaus.org/browse/GEOT-1521
http://jira.codehaus.org/browse/GEOS-1413

I'm fixing both of them as I write this mail. Can you grab today's
nightly (generated during the european afternoon) and see if this
one works for you?
Cheers
Andrea

18

Tilman Klar ha scritto:

Sure, will grab the nightly this evening and test it. BTW, SDO_AGGR_MBR works like a charm over here:

---cut---
SQL> SELECT SDO_UTIL.TO_WKTGEOMETRY(MDSYS.SDO_AGGR_MBR(GEOM)) FROM
      "LINESTRING"

SDO_UTIL.TO_WKTGEOMETRY(MDSYS.SDO_AGGR_MBR(GEOM)) ------------------------------------------------------- POLYGON ((1.0 1.0, 2.0 1.0, 2.0 2.0, 1.0 2.0, 1.0 1.0)) ---cut---

It may be the different Oracle versions. I'm using Oracle Express,
full Oracle was taking way too much resources for my developer enviornment (I have other memory hungry apps around).

Cheers
Andrea

19

The SHAPE-ZIP export works perfect now.
Thank you for the help with that issue, Andrea.

BR,
Tilman

On Thu, 2007-10-18 at 12:51 +0200, Andrea Aime wrote:

Tilman Klar ha scritto:
> Sure, will grab the nightly this evening and test it.
> BTW, SDO_AGGR_MBR works like a charm over here:
>
> ---cut---
> SQL> SELECT SDO_UTIL.TO_WKTGEOMETRY(MDSYS.SDO_AGGR_MBR(GEOM)) FROM
> "LINESTRING"
>
> SDO_UTIL.TO_WKTGEOMETRY(MDSYS.SDO_AGGR_MBR(GEOM))
> -------------------------------------------------------
> POLYGON ((1.0 1.0, 2.0 1.0, 2.0 2.0, 1.0 2.0, 1.0 1.0))
> ---cut---

It may be the different Oracle versions. I'm using Oracle Express,
full Oracle was taking way too much resources for my developer
enviornment (I have other memory hungry apps around).

Cheers
Andrea