[gdal-dev] srs definition for wgs84
Hi list, I`m trying to export a shape file to oracle, however when I view my oracle table I find that the SRS has not been set. I tried to add the -a_srs paramter to the command line and gave it 4326 which EPSG from Geographical WGS84 ogr2ogr -f OCI OCI:mdsys/mediat...@10.0.80.31:1521/attmsd rural.shp -a_srs EPSG:4326 but SDO_SRID in the table is set to 8192 whereas it should be 4326 ORA_GEOMETRY(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z), SDO_ELEM_INFO, SDO_ORDINAT SDO_GEOMETRY(3001, 8192, SDO_POINT_TYPE(69.4, 27.55, 0), NULL, NULL) SDO_GEOMETRY(3001, 8192, SDO_POINT_TYPE(72.28, 29.07, 0), NULL, NULL) SDO_GEOMETRY(3001, 8192, SDO_POINT_TYPE(65.6, 27.116667, 0), NULL, NULL) SDO_GEOMETRY(3001, 8192, SDO_POINT_TYPE(71.38, 29.48, 0), NULL, NULL) SDO_GEOMETRY(3001, 8192, SDO_POINT_TYPE(70.18, 28.016667, 0), NULL, NULL) what am i doing -- I.R ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] srs definition for wgs84
Imran, the Oracle SRID value of 8192 *is* WGS84. Oracle does not store the EPSG values, but has its own set. Best wishes, Peter Imran Rajjad wrote: Hi list, I`m trying to export a shape file to oracle, however when I view my oracle table I find that the SRS has not been set. I tried to add the -a_srs paramter to the command line and gave it 4326 which EPSG from Geographical WGS84 ogr2ogr -f OCI OCI:mdsys/mediat...@10.0.80.31:1521/attmsd rural.shp -a_srs EPSG:4326 but SDO_SRID in the table is set to 8192 whereas it should be 4326 ORA_GEOMETRY(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z), SDO_ELEM_INFO, SDO_ORDINAT SDO_GEOMETRY(3001, 8192, SDO_POINT_TYPE(69.4, 27.55, 0), NULL, NULL) SDO_GEOMETRY(3001, 8192, SDO_POINT_TYPE(72.28, 29.07, 0), NULL, NULL) SDO_GEOMETRY(3001, 8192, SDO_POINT_TYPE(65.6, 27.116667, 0), NULL, NULL) SDO_GEOMETRY(3001, 8192, SDO_POINT_TYPE(71.38, 29.48, 0), NULL, NULL) SDO_GEOMETRY(3001, 8192, SDO_POINT_TYPE(70.18, 28.016667, 0), NULL, NULL) what am i doing -- Peter J Halls, GIS Advisor, University of York Telephone: 01904 433806 Fax: 01904 433740 Snail mail: Computing Service, University of York, Heslington, York YO10 5DD This message has the status of a private and personal communication ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Re: srs definition for wgs84
Peter J Halls P.Halls at york.ac.uk writes: Imran, the Oracle SRID value of 8192 *is* WGS84. Oracle does not store the EPSG values, but has its own set. Starting from Oracle 10g or something it supports also EPSG codes. Old codes are still supported by Oracle but other programs usually do not understand Oracle SRID codes. Fortunately they are no more needed. But I think that the correct way to give target SRID with ogr Oracle driver is not to use -a_srs but the Layer Creation Option -lco SRID=4326. -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Re: srs definition for wgs84
Hi, I tried the following command , i guess I`m not getting the correct syntax here regards, Imran ogr2ogr -f OCI OCI:mdsys/mediat...@10.0.80.31:1521/attmsd parceldata.shp -skipfailures -lco SRID=4326 DIM=2 GEOMETRY_NAME=GEOM -lnl TABLE_NAME_IN_ORACLE=Parcel1 On Thu, May 13, 2010 at 5:02 PM, Jukka Rahkonen jukka.rahko...@mmmtike.fi wrote: Peter J Halls P.Halls at york.ac.uk writes: Imran, the Oracle SRID value of 8192 *is* WGS84. Oracle does not store the EPSG values, but has its own set. Starting from Oracle 10g or something it supports also EPSG codes. Old codes are still supported by Oracle but other programs usually do not understand Oracle SRID codes. Fortunately they are no more needed. But I think that the correct way to give target SRID with ogr Oracle driver is not to use -a_srs but the Layer Creation Option -lco SRID=4326. -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- I.R ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Re: srs definition for wgs84
Jukka, Jukka Rahkonen wrote: Peter J Halls P.Halls at york.ac.uk writes: Imran, the Oracle SRID value of 8192 *is* WGS84. Oracle does not store the EPSG values, but has its own set. Starting from Oracle 10g or something it supports also EPSG codes. Old codes are still supported by Oracle but other programs usually do not understand Oracle SRID codes. Fortunately they are no more needed. But I think that the correct from the (11g) Oracle Spatial reference manual: The Oracle Spatial coordinate system support is based on, but is not always identical to, the European Petroleum Survey Group (EPSG) data model and dataset. Methods are provided to express the Oracle SRID as EPSG WKT and to translate between Oracle SRID values and EPSG values. These are needed for programs which do not understand the Oracle SRID values. This means that, without care, Oracle reports will specify the Oracle SRID values, which are those stored and used internally, rather than the EPSG values. Oracle also supports projections additional to the EPSG schema. This seems to be what Imran saw. Yes, this change was introduced at 10g and replaced something rather different (and which I have never used), but the current system does not simply use EPSG as you imply. way to give target SRID with ogr Oracle driver is not to use -a_srs but the Layer Creation Option -lco SRID=4326. Agreed, although up to and including GDAL 1.6.n I have failed to get this method to work when using the API. The problem is more than likely something I've done wrong and I have not yet tried 1.7.n. Best wishes, Peter -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- Peter J Halls, GIS Advisor, University of York Telephone: 01904 433806 Fax: 01904 433740 Snail mail: Computing Service, University of York, Heslington, York YO10 5DD This message has the status of a private and personal communication ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Re: srs definition for wgs84
Hi, -lco must be repeated and typos are no good. Try ogr2ogr -f OCI OCI:mdsys/mediat...@10.0.80.31:1521/attmsd parceldata.shp -skipfailures -lco SRID=4326 -lco DIM=2 -lco GEOMETRY_NAME=GEOM -nln Parcel1 I do not have Oracle available so I am not 100% sure but it must be close to working command. -Jukka- -Alkuperäinen viesti- Lähettäjä: Imran Rajjad [mailto:raj...@gmail.com] Lähetetty: to 13.5.2010 15:44 Vastaanottaja: Rahkonen Jukka Kopio: gdal-dev@lists.osgeo.org Aihe: Re: [gdal-dev] Re: srs definition for wgs84 Hi, I tried the following command , i guess I`m not getting the correct syntax here regards, Imran ogr2ogr -f OCI OCI:mdsys/mediat...@10.0.80.31:1521/attmsd parceldata.shp -skipfailures -lco SRID=4326 DIM=2 GEOMETRY_NAME=GEOM -lnl TABLE_NAME_IN_ORACLE=Parcel1 On Thu, May 13, 2010 at 5:02 PM, Jukka Rahkonen jukka.rahko...@mmmtike.fi wrote: Peter J Halls P.Halls at york.ac.uk writes: Imran, the Oracle SRID value of 8192 *is* WGS84. Oracle does not store the EPSG values, but has its own set. Starting from Oracle 10g or something it supports also EPSG codes. Old codes are still supported by Oracle but other programs usually do not understand Oracle SRID codes. Fortunately they are no more needed. But I think that the correct way to give target SRID with ogr Oracle driver is not to use -a_srs but the Layer Creation Option -lco SRID=4326. -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- I.R ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Re: srs definition for wgs84
Hi, I believe that Imran is willing to use Oracle data, once they are in, through Geoserver. On the other hand, I do not believe that Geoserver supports those Oracle SRIDs but it wants to see SRID=4326 for WGS84 data in Oracle. Therefore even the Oracle codes may be better in some way in this case they could be unusable. I have not tried ever with SRID=4326 in Oracle, but using SRID=2393 in Oracle works fine together with our EPSG:2393 data and Geoserver. -Jukka- -Alkuperäinen viesti- Lähettäjä: Peter J Halls [mailto:p.ha...@york.ac.uk] Lähetetty: to 13.5.2010 16:02 Vastaanottaja: Rahkonen Jukka Kopio: gdal-dev@lists.osgeo.org Aihe: Re: [gdal-dev] Re: srs definition for wgs84 Jukka, Jukka Rahkonen wrote: Peter J Halls P.Halls at york.ac.uk writes: Imran, the Oracle SRID value of 8192 *is* WGS84. Oracle does not store the EPSG values, but has its own set. Starting from Oracle 10g or something it supports also EPSG codes. Old codes are still supported by Oracle but other programs usually do not understand Oracle SRID codes. Fortunately they are no more needed. But I think that the correct from the (11g) Oracle Spatial reference manual: The Oracle Spatial coordinate system support is based on, but is not always identical to, the European Petroleum Survey Group (EPSG) data model and dataset. Methods are provided to express the Oracle SRID as EPSG WKT and to translate between Oracle SRID values and EPSG values. These are needed for programs which do not understand the Oracle SRID values. This means that, without care, Oracle reports will specify the Oracle SRID values, which are those stored and used internally, rather than the EPSG values. Oracle also supports projections additional to the EPSG schema. This seems to be what Imran saw. Yes, this change was introduced at 10g and replaced something rather different (and which I have never used), but the current system does not simply use EPSG as you imply. way to give target SRID with ogr Oracle driver is not to use -a_srs but the Layer Creation Option -lco SRID=4326. Agreed, although up to and including GDAL 1.6.n I have failed to get this method to work when using the API. The problem is more than likely something I've done wrong and I have not yet tried 1.7.n. Best wishes, Peter -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- Peter J Halls, GIS Advisor, University of York Telephone: 01904 433806 Fax: 01904 433740 Snail mail: Computing Service, University of York, Heslington, York YO10 5DD This message has the status of a private and personal communication ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Re: srs definition for wgs84
Jukka, I do not have Geoserver, however, if it will support use of the SDO_CS.MAP_EPSG_SRID_TO_ORACLE and SDO_CS.MAP_ORACLE_SRID_TO_EPSG methods, then it should not matter what Oracle is doing internally. I use these on those occasions where I receive data with the EPSG definition or am exporting to EPSG. By the way, the details are in Chapter 6 of the Oracle Spatial Developer's Guide, code B28400, which is freely available for download from the Oracle 11g documentation web pages. Best wishes, Peter Rahkonen Jukka wrote: Hi, I believe that Imran is willing to use Oracle data, once they are in, through Geoserver. On the other hand, I do not believe that Geoserver supports those Oracle SRIDs but it wants to see SRID=4326 for WGS84 data in Oracle. Therefore even the Oracle codes may be better in some way in this case they could be unusable. I have not tried ever with SRID=4326 in Oracle, but using SRID=2393 in Oracle works fine together with our EPSG:2393 data and Geoserver. -Jukka- -Alkuperäinen viesti- Lähettäjä: Peter J Halls [mailto:p.ha...@york.ac.uk] Lähetetty: to 13.5.2010 16:02 Vastaanottaja: Rahkonen Jukka Kopio: gdal-dev@lists.osgeo.org Aihe: Re: [gdal-dev] Re: srs definition for wgs84 Jukka, Jukka Rahkonen wrote: Peter J Halls P.Halls at york.ac.uk writes: Imran, the Oracle SRID value of 8192 *is* WGS84. Oracle does not store the EPSG values, but has its own set. Starting from Oracle 10g or something it supports also EPSG codes. Old codes are still supported by Oracle but other programs usually do not understand Oracle SRID codes. Fortunately they are no more needed. But I think that the correct from the (11g) Oracle Spatial reference manual: The Oracle Spatial coordinate system support is based on, but is not always identical to, the European Petroleum Survey Group (EPSG) data model and dataset. Methods are provided to express the Oracle SRID as EPSG WKT and to translate between Oracle SRID values and EPSG values. These are needed for programs which do not understand the Oracle SRID values. This means that, without care, Oracle reports will specify the Oracle SRID values, which are those stored and used internally, rather than the EPSG values. Oracle also supports projections additional to the EPSG schema. This seems to be what Imran saw. Yes, this change was introduced at 10g and replaced something rather different (and which I have never used), but the current system does not simply use EPSG as you imply. way to give target SRID with ogr Oracle driver is not to use -a_srs but the Layer Creation Option -lco SRID=4326. Agreed, although up to and including GDAL 1.6.n I have failed to get this method to work when using the API. The problem is more than likely something I've done wrong and I have not yet tried 1.7.n. Best wishes, Peter -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- Peter J Halls, GIS Advisor, University of York Telephone: 01904 433806 Fax: 01904 433740 Snail mail: Computing Service, University of York, Heslington, York YO10 5DD This message has the status of a private and personal communication ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdalwarp's default nodata value
Joaquim, For the rec, VS2010 and a quite recent trunk version. Ah, this is the reason for the different results we got. On Windows, atof(nan) returns 0... but on Linux it returns a nan number. I've pushed quite a few changes to trunk to improve the situation on Windows and other changes for all platforms to fix the case when we compare pixel values to nodata value and the nodata value is nan. Indeed, the test value == dfNoDataValue that was generally used fails if value == nan and dfNoDataValue == nan, because nan != nan... See http://trac.osgeo.org/gdal/ticket/3576 Best regards, Even ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Python (2.6.5) GDAL module will not install with easy_install
Brice, Thank you. I removed the older version of gdal that came with RHEL, placed the correct path in ld.so.conf and now it installs properly and I can import the module in python! ~ Allen On May 11, 2010, at 3:57 PM, Brice Lambi wrote: There is really no reason to remove the 1.7.2 you've built. If you're going to install in the same location then all will be overwritten, if you install in a new location then it might be best to cleanup the unused stuff. I think you can do 'make uninstall' as well. Cheers, Brice ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdalwarp's default nodata value
On 13-05-2010 18:38, Even Rouault wrote: Joaquim, For the rec, VS2010 and a quite recent trunk version. Ah, this is the reason for the different results we got. On Windows, atof(nan) returns 0... but on Linux it returns a nan number. I've pushed quite a few changes to trunk to improve the situation on Windows and other changes for all platforms to fix the case when we compare pixel values to nodata value and the nodata value is nan. Indeed, the test value == dfNoDataValue that was generally used fails if value == nan and dfNoDataValue == nan, because nan != nan... Oui, c'est le danger des nains Thanks for the info (and work of course) Joaquim ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] OT: Need help with proj definition
Hi all, I have a shapefile with the following in the prj file: GEOGCS[GCS_ITRF_2000,DATUM[D_ITRF_2000,SPHEROID[GRS_1980,6378137.0,298.257222101]],PRIMEM[Greenwich,0.0],UNIT[Degree,0.0174532925199433]] Anyone know how to convert this to a proj4 definition? Thanks, -Steve ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] OT: Need help with proj definition
I quickly ran this in a python shell: from osgeo import osr wkt = 'GEOGCS[GCS_ITRF_2000,DATUM[D_ITRF_2000,SPHEROID[GRS_1980,6378137.0,298.257222101]],PRIMEM[Greenwich,0.0],UNIT[Degree,0.0174532925199433]]' srs = osr.SpatialReference() srs.ImportFromWkt(wkt) srs.ExportToProj4() '+proj=longlat +ellps=GRS80 +no_defs ' - Jamie On Thu, May 13, 2010 at 1:32 PM, Stephen Woodbridge wood...@swoodbridge.com wrote: Hi all, I have a shapefile with the following in the prj file: GEOGCS[GCS_ITRF_2000,DATUM[D_ITRF_2000,SPHEROID[GRS_1980,6378137.0,298.257222101]],PRIMEM[Greenwich,0.0],UNIT[Degree,0.0174532925199433]] Anyone know how to convert this to a proj4 definition? Thanks, -Steve ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
