This content has been marked as final. Show 6 replies
Yes, they are equivalent.
If memory serves, 8307 was an OGC definition from the WKT effort that Oracle used for lat/lon data in 8 or 8i before Oracle started recognizing the EPSG codes. It is still used in a lot of examples (and code) for that reason.
However, please note that the db won't recognize them as the same, so any data you compare will need to be "reprojected" either in-place or on-the-fly to do so. For in-place, you are safe to just swap the SRID's out which is a reasonably quick operation. So basically:
1. drop spatial indexes
2. modify the metadata
3. update the rows such as:
UPDATE tablename a
SET a.geometry.sdo_srid = 4326;
4. recreate your spatial indexes
Bryan's response is spot-on, they are the same. The one thing I might add is to emphasize what Bryan was alluding to, that 8307 dates back to the early days of Oracle Spatial while 4326 only comes along with 10gR2
So if you need to exchange spatial geometries with Oracle 8, 9 or 10gR1, you would probably want to use 8307 to avoid having to set up 4326 by hand yourself on the older instances. I would note they are not just synonyms of a single CS, they are completely separate CSs but equivalent.
Your post brought to mind some larger issues of if its a good idea to be using EPSG codes in Oracle Spatial. Note this isn't about whether the technology of EPSG codes inside Oracle Spatial works (no complaints) but rather whether the usage of EPSG codes in Oracle helps or hinders us in exchanging spatial information outside Oracle and promoting a common understanding of the coordinate systems used by our data.
Now a couple of years ago I would said you should avoid 8307 as old-school, oracle-centric and a marker of old-age. You should use 4326 as "everybody" knows that SRID is WGS84 geodetic 2D while only the Oracle wonks know that 8307 is. In other words, get on the EPSG bus. Lately though I have been fielding some interesting questions about EPSG codes, Oracle Spatial, ESRI and newer OGC standards that have me questioning that notion. If you read the link above announcing Oracle Spatial support for EPGS, you'll note that the text says that "the Oracle Spatial coordinate system support is based on, but is not always identical to, the European Petroleum Survey Group (EPSG) data model and data set". I do not know if the differences are officially elaborated anywhere but the glaring issue is one of axis ordering.
Basically EPSG has always stated that their coordinate systems all store their ordinates and walk and talk transforms and standards as first Latitude and then Longitude. Yet we all know Oracle Spatial, ESRI, PostGIS and pretty much every GIS I know of stores ordinates as longitude and then latitude in the classic X before Y. There are good computational reasons for this. So Oracle Spatial SRID 4326 could be defined as "EPSG SRID 4326 with the axes reversed". That is a little confusing, but as far as I know ESRI, PostGIS and numerous other GIS systems all do it this way. However, the new WMS 1.1 and WFS 1.3 (GML) web mapping standards all now enforce the "true" EPSG definitions so when you ask for "EPSG:4326" you will get Latitude first and Longitude second. This is slowly changing everyone's expectations for all kinds of GIS data interchange. If your WKT geometries are defined as EPSG 4326, some folks expect it to be in Lat/Long axes order. An good example is SQL Server's implementation of their geography data type (see grumbling at http://social.msdn.microsoft.com/Forums/en-US/sqlspatial/thread/41250c42-25e6-4de7-953e-a6c41ada383f) - they changed their WKT readers/writers to use Lat/Long. GeoJSON also is going the same route as WFS/GML, see http://wiki.geojson.org/GeoJSON_draft_version_5 where it will be just fine to have GeoJSON in Lat/Long axis ordering when you state EPSG:4326. The official OGC response to this confusion is to restate that EPSG definitions are and always have been Lat/Long and if you want the reverse, then you should start using the OGC defined alternatives, which for WGS84 would be "CRS84" (or in urn notation "urn:ogc:def:crs:OGC::CRS84").
Anyhow, so on one hand if you just live in the Oracle Spatial biodome then you've wasted your time reading all this. But if you need to receive and produce geometries using OGC (plus GeoJSON) specifications (or communicate effectively with folks who do), then there are some issues to contemplate. Basically the OGC says don't cite the EPSG definition unless its true lat/long. If you live in a long/lat world, use the alternative "CRS84". So if by chance you wanted to model some of this thinking inside Oracle Spatial (not convinced we want to), then you might want to shy away from using 4326 as long as Oracle Spatial remains firmly a long/lat system. You'd then need yourself a SRID number to represent "CRS84" - voila we come back full circle to 8307.
So I don't know exactly, what are the rest of you doing? What does the Oracle Spatial team plan? My impression so far is that not much is in the works. Inside the various Oracle, ESRI and PostGIS biodomes we just kind live the long/lat lifestyle and occasionally shake our fists at those pesky lat/long OGC folks cavorting about outside the glass.
So to try and wrap this up, in the beginning was 8307 and it was good. Then came 4326 and it seemed better. But now I'm not so sure and plan to stick with 8307. I am not 100% I have all this correct so feel free to jump in set me straight.
Thanks for your detailed post in response to my question. Your post was very helpful. The difference between EPSG 4326 and Oracle's version of 4326 (and that of PostGIS etc.) with switcharoo between lat/lon even though seems minor can create major confusion while exchanging data with others unless care is taken to provide correct data (lat/lon). Even though analogy is not perfect it reminds me of a lost satellite due to confusion between metric and american measurement units few years a go.
I will check out the latest specs for GeoJSON. BTW - we won't be using JSON.
But I am up indeed for some arguing :)
I think you are right, the GeoJSON folks do expressly state long always before lat and it sure seems like they are not planning to budge. Here is a good discussion:
Apologies for suggesting otherwise.
I think the advice here with GeoJSON is that the encoding MUST be long and then lat but then make sure to use the correct SRS reflecting this.
So for WGS84 GeoJSON it should have SRS of "urn:ogc:def:crs:OGC::CRS84" and never "urn:ogc:def:crs:EPSG::4326".
Which kind of rolls around the same idea I said before of us long/lat folks needing to shy away from EPSG codes or perhaps just learn the double-speak. We end up in a kind a bizarro EPSG reverse world where in the Oracle biodome we all say 4326 but then need to translate that to outside folks as CRS84 and remember that their 4326 needs to be flipped around to be our 4326. I am just not thrilled by the situation and if anyone has a better way to conceptualize the issues I am most interested to hear it.