Disney not on your side Snowboarding in 1914
Programs will do It
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.
--
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.
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.
Thanks
Peter Barrs
On 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 geotoolsIn 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/oraclespatial/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
--