Chris,
Just for reference:
From the Oracle Spatial Users Guide 10g Release 1 (although this applies to
Oracle from I think release 8.1.6 onwards, for releases before that I
*think* coordinate order didn't matter):
Polygon data consists of coordinate pair values, one vertex pair for each
line segment of the polygon. Coordinates are defined in order around the
polygon (counterclockwise for an exterior polygon ring, clockwise for an
interior polygon ring).
And
For SDO_ETYPE values 1003 and 2003, the first digit indicates exterior (1) or
interior (2):
1003: exterior polygon ring (must be specified in counterclockwise order)
2003: interior polygon ring (must be specified in clockwise order)
Cheers,
Stuart
-----Original Message-----
From: geoserver-devel-admin@lists.sourceforge.net
[mailto:geoserver-devel-admin@lists.sourceforge.net] On
Behalf Of Chris Holmes
Sent: Wednesday, 15 December 2004 2:40
To: socialchange.net.au, pbarrs
Cc: geoserver-devel@lists.sourceforge.net; Thijs Brentjens;
David Zwiers
Subject: Re: [Geoserver-devel] Oracle polygon issue / srsName
questsionOn Mon, 13 Dec 2004, Peter Barrs wrote:
> Hi Chris and fellow Geoservers,
>
> Stuart Girvan and I have hit upon a little problem - with
respect the
> current head / trunk of geotools
>
> In class oracle-spatial.filter.SQLEncoderOracle
>
> in method private static String toSDOGeom(Polygon polygon,
int srid)
>
> we have buffer.append(",NULL,MDSYS.SDO_ELEM_INFO_ARRAY(1,1003,1),")
>
> and thence proceeded to write an ordinate array; however for a
> sdo_etype
> 1003, exterior polygon, the ordinates need to be enumerated
> *counterclockwise* (currently clockwise), or the etype code
could be
> changed to 2003 (interior polygon).
>
> the impact is not being able to use the BBOX filter, for example.
Really? Are you sure the bbox is specified correctly? I
dont know oracle
all that well, but it seems odd to me that this would not
have been raised
earlier. Does it never work, or just sometimes mess up? I
am fine to
change it, but want to be sure that it does not break any one
elses code.
Thijs, do you have any thoughts on this, have you encountered
any problems
with the wrong ordering in Box? I dont think that class has
changed from
2.0.x to head.Also, it looks like we maybe have some code replication,
between these toSDOGeom methods and the sdo/SDO class, as
they appear to me to do the same thing. And it seems to have
a bit more knowledge about counterclockwise and whatnot:
http://gtsvn.refractions.net/geotools/trunk/gt/plugin/oraclesp
atial/src/org/geotools/data/oracle/sdo/SDO.java>
> --
>
> The question is, when parsing a WFS filter, in particular
for a BBOX,
> a
> <gml:Box srsName .. attribute, is the srsName read and stored? I
> couldn't see straightaway that it is. If it is, some hint
as to how I
> can access it would be good.
No, its not in the current GML parser that GeoServer uses.
David, does
your new parser get you access to srsName? That alone may be
compelling
reason to try to make the switch.>
> This is in relation to a problem we have where currently
the SRID for
> a
> <gml:Box> element in a WFS filter is determined from the
table name. The
> work that Social Change has done on XML schema mapping, dissociates
> feature types from tables and so we can't easily obtain a
SRID for the
> BBOX - although it would be preferable to have a lookup
scheme, using a
> the BBOX's gml:Box srsName.
Well, even if you can get the gml:Box srsName I think you are
still going
to want to be able to figure out what the srid for the
geometry in your
dissociated featureType. Which is part of the reason the sco
work needs
to be rolled into geotools and refactored, to handle issues
like this.
In GeoTools 2.1 (trunk) we are working to get all datastores
to return
their coordinate reference system (which will allow geoserver to do
reprojecting). So when we slot in dissociated featureTypes that are
derived from real data structures, we are still going to need them to
return their crs.Chris
>
> Thanks
> Peter Barrs
>
>
>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real
> users. Discover which products truly live up to the hype. Start
> reading now. http://productguide.itmanagersjournal.com/
> _______________________________________________
> Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>--
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from
real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel