Hi Chris - happy to test - otherwise will have to wait till after Christmas - busy up until then, to put it mildly...
Stuart has a work around for present (made it an interior polygon), so no huge urgency on our part - we also have to address the second part of my post (the question about BBOX srsNames), which will take much longer to sort out.
I'm fairly sure we have the BBOX right - eg Rob's client is hitting PostGIS with the same BBOX and its fine.
Cheers
Peter Barrs
Chris Holmes wrote:
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).
Ok, I dont have a huge gis background, so help me out here. In oracle you define the exterior and interior polygon rings by the order that you right them in. But in JTS they have explicit getExteriorRing and getInteriorRingN functions, so the order does not matter? Is that right?
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)
Looking at the code more, we use a 1003 for the exterior ring, as we should. We ignore the interior rings, which I suppose is fine for filtering?
So what your saying is that when we use a 1003, we are not always doing the proper counterclockwise order? We are just using whatever jts hands us, which we dont have that much control over.
Exactly.
Cool.
So what we should do is use the counterClockWise method in http://gtsvn.refractions.net/geotools/trunk/gt/plugin/oraclesp
atial/src/org/geotools/data/oracle/sdo/SDO.java
Which checks if the coordinate sequence is clockwise, and if it is turns it into counter clockwise. Easiest way might be to make that function public. Though this does kind of beg what should be public in the SDO class - I made the D method public so I could get the proper dimension with the filter encoder.Do you guys have time to do this fixed? My development environment is hosed, and I am way behind on work. You can have Rob commit it directly, or email the new file to me and I can get it in.
With Christmas looming I guess we're all sturggling for time. But we didn't
know about the counterclockwise method so that should help. But at the moment
it's more down to how much time the Social Change Online guys have at the
moment (and I suspect that at the moment that's basically none,
unfortunately).
Cool. I dont know that I will have a gt2 dev environment up tomorrow, but even if I dont I can try to write the code and have you all test it, if that helps. It should be pretty trivial, just make the counterClockWise method public visible, and then get the CoordinateSequence for the exterior ring and call the method on it. Its a static method so should work just fine.
Chris
Cheers,
Stuartbest regards,
Chris
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--
--
Peter Barrs
Web Map Team
Social Change Online
Brisbane:
Ph +61 (0)7 3354 1623
19 Ryland St
Grovely Qld 4054
Australia
Sydney Head Office:
Ph +61 (0)2 9692 5100
http://webmap.socialchange.net.au/
http://socialchange.net.au/