Opened 14 years ago
Closed 14 years ago
#3681 closed enhancement (wontfix)
Oracle GeoRaster is not setting setModelSRID
Reported by: | pastabolognese | Owned by: | ilucena |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | GDAL_Raster | Version: | 1.6.3 |
Severity: | normal | Keywords: | GeoRaster, SRID, setModelSRID |
Cc: | pastabolognese |
Description
The coordinates system can be read with gdalinfo "C:\mymodel"
Coordinate System is: PROJCS["OSGB 1936 / British National Grid",
The raster is imported into oracle without any warnings with
gdal_translate -of georaster "C:\mymodel" georaster:user/password,db,geoserver.ARCVIEWGRID,georaster
(and then the XML is fixed manually )
for some reason, ModelSRID is not set, it supouse to be set as the SRID of British National Grid. Therefore it needs to be set manually with sdo_geor.setModelSRID(grobj, 81989).
C:\>gdalinfo --version GDAL 1.6.3, released 2009/11/19
C:\>gdalinfo "C:\f75" Driver: AIG/Arc/Info Binary Grid Files: C:\f75
C:\f75.aux C:\f75.rrd C:\f75\dblbnd.adf C:\f75\f75.dbf C:\f75\f75.fix C:\f75\f75.prj C:\f75\f75.properties C:\f75\f75.shp C:\f75\f75.shx C:\f75\hdr.adf C:\f75\metadata.xml C:\f75\prj.adf C:\f75\sample_image C:\f75\sta.adf C:\f75\vat.adf C:\f75\w001000.adf C:\f75\w001000x.adf C:\f75\w001001.adf C:\f75\w001001x.adf C:\f75\z001001.adf C:\f75\z001001x.adf C:\f75\z001002.adf C:\f75\z001002x.adf C:\f75\z001003.adf C:\f75\z001003x.adf C:\f75\z001004.adf C:\f75\z001004x.adf C:\f75\z001005.adf C:\f75\z001005x.adf C:\f75\z001006.adf C:\f75\z001006x.adf C:\f75\z001007.adf C:\f75\z001007x.adf
Size is 103392, 158523 Coordinate System is: PROJCS["OSGB 1936 / British National Grid",
GEOGCS["OSGB 1936",
DATUM["OSGB_1936",
SPHEROID["Airy 1830",6377563.396,299.3249646]],
PRIMEM["Greenwich",0], UNIT["degree",0.0174532925199433]],
PROJECTIONTransverse_Mercator, PARAMETER["latitude_of_origin",49], PARAMETER["central_meridian",-2], PARAMETER["scale_factor",0.999601272], PARAMETER["false_easting",400000], PARAMETER["false_northing",-100000], UNIT["METERS",1]]
Origin = (138695.000000000000000,811785.000000000000000) Pixel Size = (5.000000000000000,-5.000000000000000) Corner Coordinates: Upper Left ( 138695.000, 811785.000) ( 6d19'4.00"W, 57d 7'21.73"N) Lower Left ( 138695.000, 19170.000) ( 5d38'52.73"W, 50d 0'52.68"N) Upper Right ( 655655.000, 811785.000) ( 2d13'28.96"E, 57d 7'33.16"N) Lower Right ( 655655.000, 19170.000) ( 1d34'9.36"E, 50d 1'1.50"N) Center ( 397175.000, 415477.500) ( 2d 2'33.82"W, 53d38'8.08"N) Band 1 Block=256x4 Type=Byte, ColorInterp=Undefined
Min=1.000 Max=4.000 NoData Value=255 Overviews: 25848x39631, 12924x19816, 6462x9908, 3231x4954, 1616x2477, 808x1239, 404x620, 202x310, 101x155, 51x78 Metadata:
LAYER_TYPE=athematic
<GDALRasterAttributeTable>
<FieldDefn index="0">
<Name>VALUE</Name> <Type>0</Type> <Usage>5</Usage>
</FieldDefn> <FieldDefn index="1">
<Name>COUNT</Name> <Type>0</Type> <Usage>1</Usage>
</FieldDefn> <FieldDefn index="2">
<Name>DEPTHBAND</Name> <Type>2</Type> <Usage>0</Usage>
</FieldDefn> <Row index="0">
<F>1</F> <F>53583450</F> <F>0-0.1m</F>
</Row> <Row index="1">
<F>2</F> <F>74427317</F> <F>0.1-0.3m</F>
</Row> <Row index="2">
<F>3</F> <F>135527844</F> <F>0.3-1m</F>
</Row> <Row index="3">
<F>4</F> <F>99585093</F> <F>1m+</F>
</Row>
</GDALRasterAttributeTable>
Change History (9)
comment:1 by , 14 years ago
Version: | unspecified → 1.6.3 |
---|
comment:2 by , 14 years ago
Cc: | added |
---|---|
Keywords: | GeoRaster SRID setModelSRID added |
comment:4 by , 14 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:5 by , 14 years ago
That WKT doesn't have a EPSG code what makes thing really difficult to identify a correspondent code in Oracle CS_SRS table.
I tried to replicate your case by create a file x.prj with your WKT and that is what I got:
gdal_translate -of georaster pasta.tif geor:scott/tiger@orcl,RDT_172$,172 -a_srs x.prj Input file size is 2867, 2867 Warning 9: Insufficient privileges to insert reference system to MDSYS.CS_SRS table. 0...10...20...30...40...50...60...70...80...90...100 - done. Ouput dataset: (geor:scott/tiger@orcl,RDT_172$,172) on SCOTT.TAB2,RST
That means that the GDAL driver tried to insert that WKT as a new row in the CS_SRS table but the user "scott" didn't have permission to do that. One solution is to run that statement with another user with permission to do that, like "system" for example.
That will create a new row in the table with a new SRID.
SQL> select wktext from cs_srs where srid = 1000003006; WKTEXT -------------------------------------------------------------------------------- PROJCS["British National Grid",GEOGCS["Ordnance Survey Great Brit",DATUM["Ordnan ce Survey Great Brit",SPHEROID["Airy 1830",6377563.396,299.3249646],375,-111,431 ,0,0,0,1],PRIMEM["Greenwich",0.000000],UNIT["Decimal Degree",0.0174532925199433] ],PROJECTION["Transverse Mercator"],PARAMETER["Scale_Factor",0.9996012717],PARAM ETER["Central_Meridian",-2.000000],PARAMETER["Latitude_Of_Origin",49.000000],PAR AMETER["False_Easting",400000.000000],PARAMETER["False_Northing",-100000.000000] ,UNIT["Meter",1.000000000000]]
But I don't think you want to do that, because GDAL will have problems to read from that GeoRaster.
So unfortunately I think you still need to do some kind of intervention. You can use the "-co SRID=81989" option on your gdal_translate command or even better, you can find an correspondent EPSG code to that WKT that also exists on CS_SRS and use a "-a_srs EPSG:27700" gdal_translate option.
See more at http://spatialreference.org/ref/?search=British+National&srtext=Search.
comment:6 by , 14 years ago
WKT doesn't have a EPSG code what makes thing really difficult to identify a >correspondent code in Oracle CS_SRS table
as I do not understand about the code in gdal, I am not sure what that means.
In my case, using the same user that I have used to reproduce this ticket, I can run
select * from mdsys.cs_srs
and therefore get the codes. And thus, I can create a script that get the code and use the -co option. But, as anyboddy that needs to use GeoRaster with a coordinate system, will need also to do that script, cannot GDAL do it for him self ?
comment:7 by , 14 years ago
What I means is that during the execution of gdal_translate, the output driver (georaster) ask the input driver (in your case AIG) for projection and reference information and receives the answer as a WKT string. That is the "code" I meant, not source code. Sorry for the misunderstanding.
The WKT string in your case is that one here:
PROJCS["British National Grid",GEOGCS["Ordnance Survey Great Brit",DATUM["Ordnan ce Survey Great Brit",SPHEROID["Airy 1830",6377563.396,299.3249646],375,-111,431 ,0,0,0,1],PRIMEM["Greenwich",0.000000],UNIT["Decimal Degree",0.0174532925199433] ],PROJECTION["Transverse Mercator"],PARAMETER["Scale_Factor",0.9996012717],PARAM ETER["Central_Meridian",-2.000000],PARAMETER["Latitude_Of_Origin",49.000000],PAR AMETER["False_Easting",400000.000000],PARAMETER["False_Northing",-100000.000000] ,UNIT["Meter",1.000000000000]]
If the AIG driver had delivered a WKT code with EPSG code (that looks like this: "AUTHORITY["EPSG","7485"]") then it will be possible for any other driver to understand it very easily.
The question is if the georaster driver could find a perfect match for that WKT on the CS_SRS table and apply the SRID automatically with no warnings, no mistake.
It could be, but it is not easy. The current status of the GDAL/GeoRaster driver does not contemplate that. If there is a big demand for WKT matching function that could be done but in most of the cases the WKT string received from other drivers contains EPSG authority codes and Oracle support and update EPSG codes.
By other hand, any GIS user can build their own reference system to better suit their data. In that case there is no EPGS code on the WKT and they would need to add a new row to CS_SRS. That is already supported by GDAL/GeoRaster but I think I found a bug on that process. A second load is not finding the WKT from the previous load and it is creating a new row on CS_SRS each time for the same WKT. I am going to work on that.
I hope that this all makes sense.
Regards.
References:
GeoRaster's projection/reference system import method:
http://trac.osgeo.org/gdal/browser/trunk/gdal/frmts/georaster/georaster_dataset.cpp#L1219
Examples of importFrom/exportTo reference systems match functions:
http://trac.osgeo.org/gdal/browser/trunk/gdal/ogr/ogr_srs_pci.cpp
http://trac.osgeo.org/gdal/browser/trunk/gdal/ogr/ogr_srs_usgs.cpp
http://trac.osgeo.org/gdal/browser/trunk/gdal/ogr/ogr_srs_esri.cpp
http://trac.osgeo.org/gdal/browser/trunk/gdal/ogr/ogr_srs_erm.cpp
http://trac.osgeo.org/gdal/browser/trunk/gdal/frmts/idrisi/IdrisiDataset.cpp#L2064
comment:8 by , 14 years ago
Type: | defect → enhancement |
---|
comment:9 by , 14 years ago
Resolution: | → wontfix |
---|---|
Status: | assigned → closed |