[Geoserver-users] Maven compile error

GeoServer GeoServer User
1

I’m trying to compile geoserver from a fresh SVN checkout and I’m getting this error:

F:\Dev\geoserver\platform\src\main\java\org\geoserver\platform\util\VersionPrope

rtyEditor.java:[7,24] cannot find symbol

symbol : class Version

location: package org.geotools.util

F:\Dev\geoserver\platform\src\main\java\org\geoserver\platform\Service.java:[7,2

4] cannot find symbol

symbol : class Version

location: package org.geotools.util

F:\Dev\geoserver\platform\src\main\java\org\geoserver\platform\Service.java:[38,

10] cannot find symbol

symbol : class Version

location: class org.geoserver.platform.Service

F:\Dev\geoserver\platform\src\main\java\org\geoserver\platform\Service.java:[47,

46] cannot find symbol

symbol : class Version

location: class org.geoserver.platform.Service

F:\Dev\geoserver\platform\src\main\java\org\geoserver\platform\Service.java:[65,

11] cannot find symbol

symbol : class Version

location: class org.geoserver.platform.Service

F:\Dev\geoserver\platform\src\main\java\org\geoserver\platform\util\VersionPrope

rtyEditor.java:[30,21] cannot find symbol

symbol : class Version

location: class org.geoserver.platform.util.VersionPropertyEditor

F:\Dev\geoserver\platform\src\main\java\org\geoserver\platform\Service.java:[99,

21] operator + cannot be applied to int,Version.hashCode

F:\Dev\geoserver\platform\src\main\java\org\geoserver\platform\Service.java:[99,

35] incompatible types

found :

required: int

If I look at org.geoserver.platform.Service, it says;

import org.geotools.util.Version;

If I’m understand this correctly, in util I only see VersionPropertyEditor. If I search the only Version I can find is in Mortbay. I assume I’m missing a different Version, but I’m still new to this level of java programming so I thought I’d ask for some hand-holding first.

Thanks,

Marc

n
Marc Pfister
Geospatial Data Manager
ENPLAN
mpfister@anonymised.com
530/221-0440 x108
530/221-6963 Fax

2

Hi Marc,

It sounds like you don't have a recent copy of geotools trunk installed. However i did post a recent snapshot so maven should have downloaded it... Do you you perhaps have an old version of geotools built in your repository?

-Justin

Marc Pfister wrote:

I’m trying to compile geoserver from a fresh SVN checkout and I’m getting this error:

F:\Dev\geoserver\platform\src\main\java\org\geoserver\platform\util\VersionPrope

rtyEditor.java:[7,24] cannot find symbol

symbol : class Version

location: package org.geotools.util

F:\Dev\geoserver\platform\src\main\java\org\geoserver\platform\Service.java:[7,2

4] cannot find symbol

symbol : class Version

location: package org.geotools.util

F:\Dev\geoserver\platform\src\main\java\org\geoserver\platform\Service.java:[38,

10] cannot find symbol

symbol : class Version

location: class org.geoserver.platform.Service

F:\Dev\geoserver\platform\src\main\java\org\geoserver\platform\Service.java:[47,

46] cannot find symbol

symbol : class Version

location: class org.geoserver.platform.Service

F:\Dev\geoserver\platform\src\main\java\org\geoserver\platform\Service.java:[65,

11] cannot find symbol

symbol : class Version

location: class org.geoserver.platform.Service

F:\Dev\geoserver\platform\src\main\java\org\geoserver\platform\util\VersionPrope

rtyEditor.java:[30,21] cannot find symbol

symbol : class Version

location: class org.geoserver.platform.util.VersionPropertyEditor

F:\Dev\geoserver\platform\src\main\java\org\geoserver\platform\Service.java:[99,

21] operator + cannot be applied to int,Version.hashCode

F:\Dev\geoserver\platform\src\main\java\org\geoserver\platform\Service.java:[99,

35] incompatible types

found : <nulltype>

required: int

If I look at org.geoserver.platform.Service, it says;

  import org.geotools.util.Version;

If I’m understand this correctly, in util I only see VersionPropertyEditor. If I search the only Version I can find is in Mortbay. I assume I’m missing a different Version, but I’m still new to this level of java programming so I thought I’d ask for some hand-holding first.

Thanks,

Marc

n
Marc Pfister
Geospatial Data Manager
ENPLAN
mpfister@anonymised.com
530/221-0440 x108
530/221-6963 Fax

!DSPAM:4007,46436665109078362916074!

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

-------------------------------------------------------------------------
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/

!DSPAM:4007,46436665109078362916074!

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

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

!DSPAM:4007,46436665109078362916074!

--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org

3

Hi,

What kind of logic there is in how Geoserver creates fids for Oracle feature types? Some of my featuretypes get short and handy fids, but some others very long and cryptic which cannot be parsed by all WFS clients. Is there any means to change this in Geoserver configuration, or should I do something for the Oracle tables? I imagine that having a short numeric primary key in all Oracle tables could be an answer.

Regards,

-Jukka Rahkonen-

4

Rahkonen Jukka wrote:

Hi,

What kind of logic there is in how Geoserver creates fids for Oracle feature types? Some of my featuretypes get short and handy fids, but some others very long and cryptic which cannot be parsed by all WFS clients. Is there any means to change this in Geoserver configuration, or should I do something for the Oracle tables? I imagine that having a short numeric primary key in all Oracle tables could be an answer.

Yes, primary keys are where we mostly derive our fids. If it's not there we try as best we can, but often the results are less than desirable. Declaring a serial integer as the primary key generally works well, and insures that all will go well if you use WFS-T.

Chris

Regards,

-Jukka Rahkonen-

-------------------------------------------------------------------------
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

!DSPAM:4005,464388f5150833327367457!

--
Chris Holmes
The Open Planning Project
http://topp.openplans.org

5

Hello Rahkonen,

"Rahkonen Jukka" <Jukka.Rahkonen@anonymised.com>, [20070511-00:04:33]:

Hi,

What kind of logic there is in how Geoserver creates fids for Oracle
feature types? Some of my featuretypes get short and handy fids, but
some others very long and cryptic which cannot be parsed by all WFS
clients. Is there any means to change this in Geoserver
configuration, or should I do something for the Oracle tables? I
imagine that having a short numeric primary key in all Oracle tables
could be an answer.

I have looked deeper as well.
Caused by: Error creating feature instance from element 'GIS_POLYGONS':
"GIS_POLYGONS.-32a8b85e:1127580094a:-7d21" is not a valid gml:id

In the above the ":" is not allowed, so creating a primary key should be
a solution for this kind of problem?

Best

  Stephan

--
Stephan Holl <stephan.holl@anonymised.com>, http://intevation.de/~stephan
Tel: +49 (0)541-33 50 8 32 | Intevation GmbH | AG Osnabrück - HR B 18998
Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner

6

Stephan Holl wrote:

Hello Rahkonen,

"Rahkonen Jukka" <Jukka.Rahkonen@anonymised.com>, [20070511-00:04:33]:

Hi,

What kind of logic there is in how Geoserver creates fids for Oracle
feature types? Some of my featuretypes get short and handy fids, but
some others very long and cryptic which cannot be parsed by all WFS
clients. Is there any means to change this in Geoserver
configuration, or should I do something for the Oracle tables? I
imagine that having a short numeric primary key in all Oracle tables
could be an answer.

I have looked deeper as well.
Caused by: Error creating feature instance from element 'GIS_POLYGONS':
"GIS_POLYGONS.-32a8b85e:1127580094a:-7d21" is not a valid gml:id

In the above the ":" is not allowed, so creating a primary key should be
a solution for this kind of problem?

What version of GeoServer are you using? I believe we have a fix in to turn all ':'s to '_', exactly for this problem of creating invalid GML. Of course, we still highly recommend primary keys, because the fids created this way aren't proper FIDs since they aren't constant, so don't follow the spec and aren't that useful.

Chris

Best

  Stephan

--
Chris Holmes
The Open Planning Project
http://topp.openplans.org

7

Stephan Holl ha scritto:

Hello Rahkonen,

"Rahkonen Jukka" <Jukka.Rahkonen@anonymised.com>, [20070511-00:04:33]:

Hi,

What kind of logic there is in how Geoserver creates fids for Oracle
feature types? Some of my featuretypes get short and handy fids, but
some others very long and cryptic which cannot be parsed by all WFS
clients. Is there any means to change this in Geoserver
configuration, or should I do something for the Oracle tables? I
imagine that having a short numeric primary key in all Oracle tables
could be an answer.

I have looked deeper as well.
Caused by: Error creating feature instance from element 'GIS_POLYGONS':
"GIS_POLYGONS.-32a8b85e:1127580094a:-7d21" is not a valid gml:id

Hum, in fact 1.5.0 should not show this behaviour, invalid GML id generation should have been fixed shortly before releasing it.
What version of Geoserver are you using?

In the above the ":" is not allowed, so creating a primary key should be
a solution for this kind of problem?

Yeah, it would.
Cheers
Andrea

8

Hi,

Caused by: Error creating feature instance from element 'GIS_POLYGONS':
"GIS_POLYGONS.-32a8b85e:1127580094a:-7d21" is not a valid gml:id

Hum, in fact 1.5.0 should not show this behaviour, invalid GML id
generation should have been fixed shortly before releasing it.
What version of Geoserver are you using?

In the above the ":" is not allowed, so creating a primary key should be
a solution for this kind of problem?

I'm sorry about being too lazy in updating, but my Geoserver 1.3 had worked so well that I did not dare to do that untill now. Updating was not so hard and maybe did not break anything so I guess I should have done it before. Unfortunately, meanwhile I was lifting the Geoserver version the primary key was created for me into the database as well. Therefore I can only say that that this problem has gone now, but I can't say which procedure was needed, or if either of them would have been enough.

When updating I noticed that Oracle DataStore document in not totally up to date. At least path where to drop the special Oracle stuff needed seems not to be "geoserver/server/geoserver/WEB-INF/lib/" any more, but is now like "/GeoServer 1.5.0/webapps/geoserver/WEB-INF/lib" when Geoserver is installed with Windows installer defaults.

I run in to another problem when making an existing column into primary key. The column that I used contains unique numeric parcel IDs which are key information for us. However, once that column was made into primary key it does not appear any more as a property for that Oracle feature type. Therefore IDs cannot be read through WFS. In a way they do come with the WFS response, as a part of the fids which are now contructed like this:
<gml:GIS_POLYGONS fid="GIS_POLYGONS.19971800104475">

Is there any way to configure Geoserver so that I could get the primary key column as a property as well, perhaps by editing the corresponding schema.xml file?

One client software which used to read my polygons from Oracle when server by Geoserver 1.3 WFS does not do that anymore with version 1.5 but I have look at this more deeply later.

Regards,

-Jukka Rahkonen-

9

Rahkonen Jukka ha scritto:

Hi,

Caused by: Error creating feature instance from element
'GIS_POLYGONS': "GIS_POLYGONS.-32a8b85e:1127580094a:-7d21" is not
a valid gml:id

Hum, in fact 1.5.0 should not show this behaviour, invalid GML id generation should have been fixed shortly before releasing it. What
version of Geoserver are you using?

In the above the ":" is not allowed, so creating a primary key
should be a solution for this kind of problem?

I'm sorry about being too lazy in updating, but my Geoserver 1.3 had
worked so well that I did not dare to do that untill now. Updating
was not so hard and maybe did not break anything so I guess I should
have done it before. Unfortunately, meanwhile I was lifting the
Geoserver version the primary key was created for me into the
database as well. Therefore I can only say that that this problem
has gone now, but I can't say which procedure was needed, or if
either of them would have been enough.

I bet that the primary key is the difference.

When updating I noticed that Oracle DataStore document in not totally
up to date. At least path where to drop the special Oracle stuff
needed seems not to be "geoserver/server/geoserver/WEB-INF/lib/" any
more, but is now like "/GeoServer
1.5.0/webapps/geoserver/WEB-INF/lib" when Geoserver is installed with
Windows installer defaults.

Thanks for spotting this, I updated the page.

I run in to another problem when making an existing column into
primary key. The column that I used contains unique numeric parcel
IDs which are key information for us. However, once that column was
made into primary key it does not appear any more as a property for
that Oracle feature type. Therefore IDs cannot be read through WFS.
In a way they do come with the WFS response, as a part of the fids
which are now contructed like this: <gml:GIS_POLYGONS
fid="GIS_POLYGONS.19971800104475">

Is there any way to configure Geoserver so that I could get the
primary key column as a property as well, perhaps by editing the
corresponding schema.xml file?

19971800104475 is your numeric primary key. The geotools library
do in fact allow us to include the primary key among the attributes
too, but we don't allow it now. I guess we could add it as a feature
type configuration, or as a datastore wide option.
One workaround for you would to be create a view that duplicates that
colum, register it against the spatial geometry tables, give it
a primary key and so on, shortly, make Geoserver believe there is a
new spatial table around, and register that one.

One client software which used to read my polygons from Oracle when
server by Geoserver 1.3 WFS does not do that anymore with version 1.5
but I have look at this more deeply later.

May it be this one?
http://docs.codehaus.org/display/GEOSDOC/My+WFS+request+in+Java+does+not+work.

Cheers
Andrea

10

Andrea Aime wrote:

I run in to another problem when making an existing column into
primary key. The column that I used contains unique numeric parcel
IDs which are key information for us. However, once that column was
made into primary key it does not appear any more as a property for
that Oracle feature type. Therefore IDs cannot be read through WFS.
In a way they do come with the WFS response, as a part of the fids
which are now contructed like this: <gml:GIS_POLYGONS
fid="GIS_POLYGONS.19971800104475">

Is there any way to configure Geoserver so that I could get the
primary key column as a property as well, perhaps by editing the
corresponding schema.xml file?

19971800104475 is your numeric primary key. The geotools library
do in fact allow us to include the primary key among the attributes
too, but we don't allow it now. I guess we could add it as a feature
type configuration, or as a datastore wide option.
One workaround for you would to be create a view that duplicates that
colum, register it against the spatial geometry tables, give it
a primary key and so on, shortly, make Geoserver believe there is a
new spatial table around, and register that one.

I think I can find the information I need from another place in the database. But for the future needs and WFS-T I would like to ask what might be the best practice to guarantee proper fid generation so that transactions, including inserts, against Oracle datastore will succeed? Having a dedicated primary key taking values from sequence, perhaps?

Regards,

-Jukka Rahkonen-

11

Rahkonen Jukka ha scritto:

Andrea Aime wrote:

I think I can find the information I need from another place in the
database. But for the future needs and WFS-T I would like to ask
what might be the best practice to guarantee proper fid generation so
that transactions, including inserts, against Oracle datastore will
succeed? Having a dedicated primary key taking values from sequence,
perhaps?

Yeah, that would work. Please note that we still have serious problems
doing WFS-T against Oracle, due to its non standard way to deal with
reference systems (wkt strings in Oracle installs are both sintactically and semantically wrong...).
Unfortunately so far no-one stepped up to try and fix this, or to sponsor some developer to do it.

Cheers
Andrea

12

Hello,

While testing a WFS client software against Geoserver 1.5.0 I faced a problem in using DWithin filter. I believe that the same filter did work with version 1.3, but I do not have it anymore for checking. Anyway, here is an example of the filter for the states WFS type:

<?xml version="1.0" encoding="ISO-8859-1"?>
<wfs:GetFeature xmlns:ogc="http://www.opengis.net/ogc&quot; xmlns:gml="http://www.opengis.net/gml&quot; xmlns:wfs="http://www.opengis.net/wfs&quot; service="WFS" version="1.0.0" maxFeatures="1000" outputFormat="GML2">
<wfs:Query xmlns:topp="http://www.openplans.org/topp&quot; typeName="topp:states">
<ogc:Filter>
<ogc:DWithin xmlns:gml='http://www.opengis.net/gml’ >
<ogc:PropertyName xmlns:topp="http://www.openplans.org/topp&quot;&gt;
topp:the_geom</ogc:PropertyName>
<gml:Point srsName="EPSG:4326">
<gml:coordinates cs="," decimal="." ts=" ">
-108.75639833499999,42.55730412507463</gml:coordinates>
</gml:Point>
<ogc:Distance units="m">
1000.0</ogc:Distance>
<ogc:Distance unit='http://www.uomdict.com/uom.html#meters’>
1000.0</ogc:Distance>
</ogc:DWithin>
</ogc:Filter>
</wfs:Query>
</wfs:GetFeature>

This is the exception report that Geoserver 1.5 sends back:

<ServiceExceptionReport version="1.2.0" xsi:schemaLocation="http://www.opengis.net/ogc http://localhost:8080/geoserver/schemas//wfs/1.0.0/OGC-exception.xsd&quot;&gt;
?
<ServiceException locator="org.vfny.geoserver.util.requests.readers.XmlRequestReader">
      org.geotools.filter.IllegalFilterException: Got distance for Geometry Distance Filter in illegal state: complete, geometry and property should be set first
</ServiceException>
</ServiceExceptionReport>

Might it be the filter that is wrong, or is the error on Geoserver side?

-Jukka Rahkonen-

13

Hi,

I believe the problem is that you have 2 "Distance" element when the
schema of the type only specifies one. I suspect that the filter parser
has undergone some changes since 1.3. But simply removing the duplicate
element should make the request work fine.

-Justin

Rahkonen Jukka wrote:

Hello,

While testing a WFS client software against Geoserver 1.5.0 I faced a problem in using DWithin filter. I believe that the same filter did work with version 1.3, but I do not have it anymore for checking. Anyway, here is an example of the filter for the states WFS type:

<?xml version="1.0" encoding="ISO-8859-1"?>
<wfs:GetFeature xmlns:ogc="http://www.opengis.net/ogc&quot; xmlns:gml="http://www.opengis.net/gml&quot; xmlns:wfs="http://www.opengis.net/wfs&quot; service="WFS" version="1.0.0" maxFeatures="1000" outputFormat="GML2">
<wfs:Query xmlns:topp="http://www.openplans.org/topp&quot; typeName="topp:states">
<ogc:Filter>
<ogc:DWithin xmlns:gml='http://www.opengis.net/gml’ >
<ogc:PropertyName xmlns:topp="http://www.openplans.org/topp&quot;&gt;
topp:the_geom</ogc:PropertyName>
<gml:Point srsName="EPSG:4326">
<gml:coordinates cs="," decimal="." ts=" ">
-108.75639833499999,42.55730412507463</gml:coordinates>
</gml:Point>
<ogc:Distance units="m">
1000.0</ogc:Distance>
<ogc:Distance unit='http://www.uomdict.com/uom.html#meters’>
1000.0</ogc:Distance>
</ogc:DWithin>
</ogc:Filter>
</wfs:Query>
</wfs:GetFeature>

This is the exception report that Geoserver 1.5 sends back:

<ServiceExceptionReport version="1.2.0" xsi:schemaLocation="http://www.opengis.net/ogc http://localhost:8080/geoserver/schemas//wfs/1.0.0/OGC-exception.xsd&quot;&gt;
?
<ServiceException locator="org.vfny.geoserver.util.requests.readers.XmlRequestReader">
      org.geotools.filter.IllegalFilterException: Got distance for Geometry Distance Filter in illegal state: complete, geometry and property should be set first
</ServiceException>
</ServiceExceptionReport>

Might it be the filter that is wrong, or is the error on Geoserver side?

-Jukka Rahkonen-

-------------------------------------------------------------------------
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

!DSPAM:4007,464b0dfa245901439371379!

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

14

Thanks Justin, that was simple. The request works if I remove the following:

<ogc:Distance unit='http://www.uomdict.com/uom.html#meters’>
1000.0</ogc:Distance>

I will ask the WFS client developers if meters really have to be defined twise.

Regards,

-Jukka-

________________________________

Lähettäjä: geoserver-users-bounces@lists.sourceforge.net puolesta: Justin Deoliveira
Lähetetty: ke 16.5.2007 18:09
Vastaanottaja: Rahkonen Jukka
Kopio: geoserver-users@lists.sourceforge.net
Aihe: Re: [Geoserver-users] Problem with WFS DWithin filter in Geoserver 1.5.0

Hi,

I believe the problem is that you have 2 "Distance" element when the
schema of the type only specifies one. I suspect that the filter parser
has undergone some changes since 1.3. But simply removing the duplicate
element should make the request work fine.

-Justin

Rahkonen Jukka wrote:

Hello,

While testing a WFS client software against Geoserver 1.5.0 I faced a problem in using DWithin filter. I believe that the same filter did work with version 1.3, but I do not have it anymore for checking. Anyway, here is an example of the filter for the states WFS type:

<?xml version="1.0" encoding="ISO-8859-1"?>
<wfs:GetFeature xmlns:ogc="http://www.opengis.net/ogc&quot; xmlns:gml="http://www.opengis.net/gml&quot; xmlns:wfs="http://www.opengis.net/wfs&quot; service="WFS" version="1.0.0" maxFeatures="1000" outputFormat="GML2">
<wfs:Query xmlns:topp="http://www.openplans.org/topp&quot; typeName="topp:states">
<ogc:Filter>
<ogc:DWithin xmlns:gml='http://www.opengis.net/gml’ >
<ogc:PropertyName xmlns:topp="http://www.openplans.org/topp&quot;&gt;
topp:the_geom</ogc:PropertyName>
<gml:Point srsName="EPSG:4326">
<gml:coordinates cs="," decimal="." ts=" ">
-108.75639833499999,42.55730412507463</gml:coordinates>
</gml:Point>
<ogc:Distance units="m">
1000.0</ogc:Distance>
<ogc:Distance unit='http://www.uomdict.com/uom.html#meters’>
1000.0</ogc:Distance>
</ogc:DWithin>
</ogc:Filter>
</wfs:Query>
</wfs:GetFeature>

This is the exception report that Geoserver 1.5 sends back:

<ServiceExceptionReport version="1.2.0" xsi:schemaLocation="http://www.opengis.net/ogc http://localhost:8080/geoserver/schemas//wfs/1.0.0/OGC-exception.xsd&quot;&gt;
?
<ServiceException locator="org.vfny.geoserver.util.requests.readers.XmlRequestReader">
      org.geotools.filter.IllegalFilterException: Got distance for Geometry Distance Filter in illegal state: complete, geometry and property should be set first
</ServiceException>
</ServiceExceptionReport>

Might it be the filter that is wrong, or is the error on Geoserver side?

-Jukka Rahkonen-

-------------------------------------------------------------------------
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

!DSPAM:4007,464b0dfa245901439371379!

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

-------------------------------------------------------------------------
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

15

Hi,

This time I have the following problem: Original data are in Oracle statial, features there are of Oracle Gtype 2003, that is two-dimensional polygons. Now, when polygons with islands go through WFS they are changing to multipolygons in the resulting gml. Polygons without islands remain as polygons. Is this correct behaviour?

-Jukka Rahkonen-

16

Rahkonen Jukka ha scritto:

Hi,

This time I have the following problem: Original data are in Oracle
statial, features there are of Oracle Gtype 2003, that is
two-dimensional polygons. Now, when polygons with islands go through
WFS they are changing to multipolygons in the resulting gml.
Polygons without islands remain as polygons. Is this correct
behaviour?

No, does not look like correct behavior.
Can you draw a map with WMS to make sure the holes are treated as holes?
Trying to understand if the issue is with the Oracle data store or
the GML encoder.

Cheers
Andrea

17

There should be no reason for the holes in the polygons would force a
MultiPolygon, I would think it should remain a normal Polygon. Sounds
like a bug in the oracle datastore. Unfortunately oracle is not all that
well maintained ... Feel free to schedule a bug in the tracker for this
and hopefully someone will get the time to set up an oracle instance and
check it out.

-Justin

Rahkonen Jukka wrote:

Hi,

This time I have the following problem: Original data are in Oracle statial, features there are of Oracle Gtype 2003, that is two-dimensional polygons. Now, when polygons with islands go through WFS they are changing to multipolygons in the resulting gml. Polygons without islands remain as polygons. Is this correct behaviour?

-Jukka Rahkonen-

-------------------------------------------------------------------------
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

!DSPAM:4007,464b29d2285741804284693!

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

18

I know Oracle has problems with multi-polygons vs. regular ones, since the spatial type isn't specific enough, afaik. I remember it being like shapefiles, you can store 1 or more polygons, so we generally cast it to a multipolygon to be safe, in case some of the data is actually multi-polygons. That said, things may have changed, but treating each hole as a separate polygon in a multipolygon is obviously wrong, if that's what it's doing.

Chris

Justin Deoliveira wrote:

There should be no reason for the holes in the polygons would force a
MultiPolygon, I would think it should remain a normal Polygon. Sounds
like a bug in the oracle datastore. Unfortunately oracle is not all that
well maintained ... Feel free to schedule a bug in the tracker for this
and hopefully someone will get the time to set up an oracle instance and
check it out.

-Justin

Rahkonen Jukka wrote:

Hi,

This time I have the following problem: Original data are in Oracle statial, features there are of Oracle Gtype 2003, that is two-dimensional polygons. Now, when polygons with islands go through WFS they are changing to multipolygons in the resulting gml. Polygons without islands remain as polygons. Is this correct behaviour?

-Jukka Rahkonen-

-------------------------------------------------------------------------
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

--
Chris Holmes
The Open Planning Project
http://topp.openplans.org

19

Hi,

Things are not so badly that holes were made to separate polygons. The resulting multipolygon is topologically valid with one outer ring and one or more inner rings. Therefore it for sure looks OK in WMS. Problem is that multipolygons, even if they contain just one polygon with holes, are not valid in our feature model. We have defined that parcels may have islands but they must not be in many parts and therefore they are stored as polygons (Gtype=2003) in Oracle. Multipolygons are using Gtype=2007 and I guess that they could be presented as geometry collections as well with Gtype=2004.

I think that Geoserver should have at least an option to respect the Gtypes used in Oracle. It is possible to store objects with all possible Gtypes into the same spatial table in Oracle spatial, even with all geometries stored into the same geometry column, and I can imagine it might be tricky to handle those when creating new FeatureTypes, for example. However, we have tried to made things as easy as possible so that each spatial table contains only objects of the same geometry type.

Do you think that changing polygons with holes to multipolygons is a bug or not? How do other datastores than Oracle handle those?

-Jukka-

-----Original Message-----
From: Chris Holmes [mailto:cholmes@anonymised.com]

I know Oracle has problems with multi-polygons vs. regular ones, since
the spatial type isn't specific enough, afaik. I remember it being like
shapefiles, you can store 1 or more polygons, so we generally cast it to
a multipolygon to be safe, in case some of the data is actually
multi-polygons. That said, things may have changed, but treating each
hole as a separate polygon in a multipolygon is obviously wrong, if
that's what it's doing.

Chris

Justin Deoliveira wrote:

There should be no reason for the holes in the polygons would force a
MultiPolygon, I would think it should remain a normal Polygon. Sounds
like a bug in the oracle datastore. Unfortunately oracle is not all that
well maintained ... Feel free to schedule a bug in the tracker for this
and hopefully someone will get the time to set up an oracle instance and
check it out.

-Justin

Rahkonen Jukka wrote:

Hi,

This time I have the following problem: Original data are in Oracle statial, features there are of Oracle Gtype 2003, that is two-dimensional polygons. Now, when polygons with islands go through WFS they are changing to multipolygons in the resulting gml. Polygons without islands remain as polygons. Is this correct behaviour?

-Jukka Rahkonen-

20

Rahkonen Jukka ha scritto:

Hi,

Things are not so badly that holes were made to separate polygons.
The resulting multipolygon is topologically valid with one outer ring
and one or more inner rings. Therefore it for sure looks OK in WMS.
Problem is that multipolygons, even if they contain just one polygon
with holes, are not valid in our feature model. We have defined that
parcels may have islands but they must not be in many parts and
therefore they are stored as polygons (Gtype=2003) in Oracle.
Multipolygons are using Gtype=2007 and I guess that they could be
presented as geometry collections as well with Gtype=2004.

I think that Geoserver should have at least an option to respect the
Gtypes used in Oracle. It is possible to store objects with all
possible Gtypes into the same spatial table in Oracle spatial, even
with all geometries stored into the same geometry column, and I can
imagine it might be tricky to handle those when creating new
FeatureTypes, for example. However, we have tried to made things as
easy as possible so that each spatial table contains only objects of
the same geometry type.

Do you think that changing polygons with holes to multipolygons is a
bug or not? How do other datastores than Oracle handle those?

Seems to be a valid read side issue.
I created an jira issue to avoid forgetting this, you may want to
add yourself a watcher of the issue:
http://jira.codehaus.org/browse/GEOS-1091

Cheers
Andrea