Re: [gdal-dev] Ogr2ogr -dim and Oracle

2016-11-17 Thread Ivan Lucena 
Hi,


a) If you look at this code here [1] from the raster driver, there are two 
function, FIND_GEOG_CRS and FIND_PROJ_CRS, that uses the WKT string to find 
matches with inside SRS.


That runs independently from Authority code and returns a list of possible 
matches SRIDs. The driver takes the first one automatically.


Looking back on that code, there is a lot of property-name strings that need to 
be adjusted, adding or removing some "_" or uppercase here and there.


b) I believe that EPSG codes are supported since version 11.


c) The -lco SRID is still useful. The way the OCI driver code works now "-a_srs 
EPSG:4326" will be translated to SRID 8078 (or something like that).


That is how the driver was originally developed, when EPSG was not supported 
yet. By using -lco SRID 4326 users can overwrite that.



I am kind of thinking about merging the two Oracle driver into one 
"raster/vector" driver. Any advice on that will be gladly accepted.



Regards,

Ivan


[1] - 
https://trac.osgeo.org/gdal/browser/trunk/gdal/frmts/georaster/georaster_dataset.cpp#L1673



From: Rahkonen Jukka (MML) 
Sent: Thursday, November 17, 2016 9:18:43 AM
To: Even Rouault; Ivan Lucena
Cc: gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] Ogr2ogr -dim and Oracle

Hi,

Probably SDO_COORD_REF_SYS is what to use nowadays even I guess that it points 
to MDSYS tables. Looks like something has changed with Oracle 10.2 and I 
believe that it is very hard to use so old Oracle version without paying much 
extra.
https://docs.oracle.com/database/121/SPATL/GUID-7DEF5C91-777C-4023-AE2E-E2E29F5213D2.htm#SPATL652

-Jukka Rahkonen-


Even Rouault wrote:

Le jeudi 17 novembre 2016 14:19:10, Ivan Lucena a écrit :
> Hi Even,
>
>> Did you try your change?

>Yes

>>
> There has been a lot of changes in both sides over the years that are
> not reflected on the OCI driver code.
>
> That hard coded SRID conversion should be deleted since EPSG is fully
> supported now.

Do you know which since which version of OCI this "now" apply ?

With 11.2.0, I see things like :

OGRFeature(select * from MDSYS.CS_SRS):6
  CS_NAME (String) = NAD83(CSRS98) / UTM zone 17N
  SRID (Integer64) = 2150
  AUTH_SRID (Integer64) = 2150
  AUTH_NAME (String) = Geomatics Canada.
  WKTEXT (String) = PROJCS["NAD83(CSRS98) / UTM zone 17N", GEOGCS [ 
"NAD83(CSRS98)", DATUM ["NAD83 Canadian Spatial Reference System (EPSG ID 
6140)", SPHEROID ["GRS 1980 (EPSG ID 7019)", 6378137.0, 298.257222101]], PRIMEM 
[ "Greenwich", 0.00 ], UNIT ["degree minute second hemisphere", 
0.0174532925199433]], PROJECTION ["Transverse Mercator"], PARAMETER 
["Latitude_Of_Origin", 0.0], PARAMETER ["Central_Meridian", -81.0], PARAMETER 
["Scale_Factor", 0.9996], PARAMETER ["False_Easting", 50.0], PARAMETER 
["False_Northing", 0.0], UNIT ["Meter", 1.0]]
  WKTEXT3D (String) = PROJCS[
  "NAD83(CSRS98) / UTM zone 17N",
  GEOGCS["NAD83(CSRS98)",
DATUM["NAD83 Canadian Spatial Reference System",
  SPHEROID[
"GRS 1980",
6378137.0,
298.257222101,
AUTHORITY["EPSG", "7019"]],
  TOWGS84[0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0],
  AUTHORITY["EPSG", "6140"]],
PRIMEM["Greenwich", 0.00, AUTHORITY["EPSG","8901"]],
UNIT["degree minute second hemisphere", 0.0174532925199433, 
AUTHORITY["EPSG", "9108"]],
AXIS["Lat", NORTH],
AXIS["Long", EAST],
AUTHORITY["EPSG", "4140"]],
  PROJECTION ["Transverse Mercator"],
  PARAMETER ["Latitude_Of_Origin", 0.0],
  PARAMETER ["Central_Meridian", -81.0],
  PARAMETER ["Scale_Factor", 0.9996],
  PARAMETER ["False_Easting", 50.0],
  PARAMETER ["False_Northing", 0.0],
  UNIT["metre", 1.0, AUTHORITY["EPSG", "9001"]],
  AXIS["E", EAST],
  AXIS["N", NORTH],
  AUTHORITY["EPSG", "2150"]]

What surprises me is the AUTH_NAME which is not EPSG (for other codes it is 
null). So it is not entirely clear how you would find the SRID if you can't 
search by AUTH_NAME = 'EPSG' AND AUTH_SRID = epsg_code. Skimming through the 
list, it seems that SRID = AUTH_SRID for EPSG codes however.

>
> He georaster driver uses some PLSQL functions to try to match WKT to
> possible SRIDs. That could be added to the OCI. I think.

OK. Good to know

Even

--
Spatialys - Geospatial professional services
http://www.spatialys.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Ogr2ogr -dim and Oracle

2016-11-17 Thread Rahkonen Jukka (MML) 
Hi,

Probably SDO_COORD_REF_SYS is what to use nowadays even I guess that it points 
to MDSYS tables. Looks like something has changed with Oracle 10.2 and I 
believe that it is very hard to use so old Oracle version without paying much 
extra.
https://docs.oracle.com/database/121/SPATL/GUID-7DEF5C91-777C-4023-AE2E-E2E29F5213D2.htm#SPATL652
 

-Jukka Rahkonen- 


Even Rouault wrote:

Le jeudi 17 novembre 2016 14:19:10, Ivan Lucena a écrit :
> Hi Even,
> 
>> Did you try your change?

>Yes

>> 
> There has been a lot of changes in both sides over the years that are 
> not reflected on the OCI driver code.
> 
> That hard coded SRID conversion should be deleted since EPSG is fully 
> supported now.

Do you know which since which version of OCI this "now" apply ?

With 11.2.0, I see things like :

OGRFeature(select * from MDSYS.CS_SRS):6
  CS_NAME (String) = NAD83(CSRS98) / UTM zone 17N
  SRID (Integer64) = 2150
  AUTH_SRID (Integer64) = 2150
  AUTH_NAME (String) = Geomatics Canada.
  WKTEXT (String) = PROJCS["NAD83(CSRS98) / UTM zone 17N", GEOGCS [ 
"NAD83(CSRS98)", DATUM ["NAD83 Canadian Spatial Reference System (EPSG ID 
6140)", SPHEROID ["GRS 1980 (EPSG ID 7019)", 6378137.0, 298.257222101]], PRIMEM 
[ "Greenwich", 0.00 ], UNIT ["degree minute second hemisphere", 
0.0174532925199433]], PROJECTION ["Transverse Mercator"], PARAMETER 
["Latitude_Of_Origin", 0.0], PARAMETER ["Central_Meridian", -81.0], PARAMETER 
["Scale_Factor", 0.9996], PARAMETER ["False_Easting", 50.0], PARAMETER 
["False_Northing", 0.0], UNIT ["Meter", 1.0]]
  WKTEXT3D (String) = PROJCS[
  "NAD83(CSRS98) / UTM zone 17N",
  GEOGCS["NAD83(CSRS98)",
DATUM["NAD83 Canadian Spatial Reference System",
  SPHEROID[
"GRS 1980",
6378137.0,
298.257222101,
AUTHORITY["EPSG", "7019"]],
  TOWGS84[0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0],
  AUTHORITY["EPSG", "6140"]],
PRIMEM["Greenwich", 0.00, AUTHORITY["EPSG","8901"]],
UNIT["degree minute second hemisphere", 0.0174532925199433, 
AUTHORITY["EPSG", "9108"]],
AXIS["Lat", NORTH],
AXIS["Long", EAST],
AUTHORITY["EPSG", "4140"]],
  PROJECTION ["Transverse Mercator"],
  PARAMETER ["Latitude_Of_Origin", 0.0],
  PARAMETER ["Central_Meridian", -81.0],
  PARAMETER ["Scale_Factor", 0.9996],
  PARAMETER ["False_Easting", 50.0],
  PARAMETER ["False_Northing", 0.0],
  UNIT["metre", 1.0, AUTHORITY["EPSG", "9001"]],
  AXIS["E", EAST],
  AXIS["N", NORTH],
  AUTHORITY["EPSG", "2150"]]

What surprises me is the AUTH_NAME which is not EPSG (for other codes it is 
null). So it is not entirely clear how you would find the SRID if you can't 
search by AUTH_NAME = 'EPSG' AND AUTH_SRID = epsg_code. Skimming through the 
list, it seems that SRID = AUTH_SRID for EPSG codes however.

> 
> He georaster driver uses some PLSQL functions to try to match WKT to
> possible SRIDs. That could be added to the OCI. I think.

OK. Good to know

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Ogr2ogr -dim and Oracle

2016-11-17 Thread Even Rouault 
Le jeudi 17 novembre 2016 14:19:10, Ivan Lucena a écrit :
> Hi Even,
> 
> Did you try your change?

Yes

> 
> There has been a lot of changes in both sides over the years that are not
> reflected on the OCI driver code.
> 
> That hard coded SRID conversion should be deleted since EPSG is fully
> supported now.

Do you know which since which version of OCI this "now" apply ?

With 11.2.0, I see things like :

OGRFeature(select * from MDSYS.CS_SRS):6
  CS_NAME (String) = NAD83(CSRS98) / UTM zone 17N
  SRID (Integer64) = 2150
  AUTH_SRID (Integer64) = 2150
  AUTH_NAME (String) = Geomatics Canada.
  WKTEXT (String) = PROJCS["NAD83(CSRS98) / UTM zone 17N", GEOGCS [ 
"NAD83(CSRS98)", DATUM ["NAD83 Canadian Spatial Reference System (EPSG ID 
6140)", SPHEROID ["GRS 1980 (EPSG ID 7019)", 6378137.0, 298.257222101]], 
PRIMEM [ "Greenwich", 0.00 ], UNIT ["degree minute second hemisphere", 
0.0174532925199433]], PROJECTION ["Transverse Mercator"], PARAMETER 
["Latitude_Of_Origin", 0.0], PARAMETER ["Central_Meridian", -81.0], PARAMETER 
["Scale_Factor", 0.9996], PARAMETER ["False_Easting", 50.0], PARAMETER 
["False_Northing", 0.0], UNIT ["Meter", 1.0]]
  WKTEXT3D (String) = PROJCS[
  "NAD83(CSRS98) / UTM zone 17N",
  GEOGCS["NAD83(CSRS98)",
DATUM["NAD83 Canadian Spatial Reference System",
  SPHEROID[
"GRS 1980",
6378137.0,
298.257222101,
AUTHORITY["EPSG", "7019"]],
  TOWGS84[0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0],
  AUTHORITY["EPSG", "6140"]],
PRIMEM["Greenwich", 0.00, AUTHORITY["EPSG","8901"]],
UNIT["degree minute second hemisphere", 0.0174532925199433, 
AUTHORITY["EPSG", "9108"]],
AXIS["Lat", NORTH],
AXIS["Long", EAST],
AUTHORITY["EPSG", "4140"]],
  PROJECTION ["Transverse Mercator"],
  PARAMETER ["Latitude_Of_Origin", 0.0],
  PARAMETER ["Central_Meridian", -81.0],
  PARAMETER ["Scale_Factor", 0.9996],
  PARAMETER ["False_Easting", 50.0],
  PARAMETER ["False_Northing", 0.0],
  UNIT["metre", 1.0, AUTHORITY["EPSG", "9001"]],
  AXIS["E", EAST],
  AXIS["N", NORTH],
  AUTHORITY["EPSG", "2150"]]

What surprises me is the AUTH_NAME which is not EPSG (for other codes it is 
null). So it is not entirely clear how you would find the SRID if you can't 
search by AUTH_NAME = 'EPSG' AND AUTH_SRID = epsg_code. Skimming through the 
list, it seems that SRID = AUTH_SRID for EPSG codes however.

> 
> He georaster driver uses some PLSQL functions to try to match WKT to
> possible SRIDs. That could be added to the OCI. I think.

OK. Good to know

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Ogr2ogr -dim and Oracle

2016-11-17 Thread Ivan Lucena 
Hi Even,

Did you try your change?

There has been a lot of changes in both sides over the years that are not 
reflected on the OCI driver code.

That hard coded SRID conversion should be deleted since EPSG is fully supported 
now.

He georaster driver uses some PLSQL functions to try to match WKT to possible 
SRIDs. That could be added to the OCI. I think.

Regards 
Ivan


> On Nov 17, 2016, at 7:38 AM, Even Rouault  wrote:
> 
> Le jeudi 17 novembre 2016 12:49:09, Michael Smith a écrit :
>> Yes even the current version needs the layer creation option for dim. I
>> would be +1 for this change (never really understood why it was this way).
>> I think we are probably one of the biggest users of the oracle driver and
>> I think this would be a good improvement.
> 
> OK, I've just changed that in trunk to use the dimension of the passed 
> geometry type.
> 
> Regarding SRS / SRID, as far as I can see, there's a logic to try to guess 
> the 
> SRID from the SRS based first on a very small list of hard-coded EPSG SRS 
> (EPSG:4326,4322,4269,4277,27700), and then trying to find an entry with the 
> same WKTEXT in MDSYS.CS_SRS
> 
>> 
>> Sent from my iPhone
>> 
>>> On Nov 17, 2016, at 2:06 AM, Rahkonen Jukka (MML)
>>>  wrote:
>>> 
>>> Hi,
>>> 
>>> I noticed that Even was editing the ogr2ogr help about the –dim parameter
>>> and  remembered that I think that it does not have an effect on the OCI
>>> driver. For forcing a new Oracle table into 2D you must use the OCI
>>> drivers own layer creation option “DIM” instead
>>> http://www.gdal.org/drv_oci.html. I am not sure if that happens also
>>> with the current GDAL version.
>>> 
>>> -Jukka Rahkonen-
>>> ___
>>> gdal-dev mailing list
>>> gdal-dev@lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/gdal-dev
> 
> -- 
> Spatialys - Geospatial professional services
> http://www.spatialys.com
> ___
> 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

Re: [gdal-dev] Ogr2ogr -dim and Oracle

2016-11-17 Thread Even Rouault 
Le jeudi 17 novembre 2016 12:49:09, Michael Smith a écrit :
> Yes even the current version needs the layer creation option for dim. I
> would be +1 for this change (never really understood why it was this way).
> I think we are probably one of the biggest users of the oracle driver and
> I think this would be a good improvement.

OK, I've just changed that in trunk to use the dimension of the passed 
geometry type.

Regarding SRS / SRID, as far as I can see, there's a logic to try to guess the 
SRID from the SRS based first on a very small list of hard-coded EPSG SRS 
(EPSG:4326,4322,4269,4277,27700), and then trying to find an entry with the 
same WKTEXT in MDSYS.CS_SRS

> 
> Sent from my iPhone
> 
> > On Nov 17, 2016, at 2:06 AM, Rahkonen Jukka (MML)
> >  wrote:
> > 
> > Hi,
> > 
> > I noticed that Even was editing the ogr2ogr help about the –dim parameter
> > and  remembered that I think that it does not have an effect on the OCI
> > driver. For forcing a new Oracle table into 2D you must use the OCI
> > drivers own layer creation option “DIM” instead
> > http://www.gdal.org/drv_oci.html. I am not sure if that happens also
> > with the current GDAL version.
> > 
> > -Jukka Rahkonen-
> > ___
> > gdal-dev mailing list
> > gdal-dev@lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/gdal-dev

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Ogr2ogr -dim and Oracle

2016-11-17 Thread Michael Smith 
For the srid, I would say keep that as an srs doesn't always map cleanly to an 
srid. 

Sent from my iPhone

> On Nov 17, 2016, at 5:54 AM, Rahkonen Jukka (MML) 
>  wrote:
> 
> Hi,
>  
> I would also check how ogr2ogr options –a_srs and –t_srs  behave or if the 
> OCI driver option –lco SRID is still needed.
>  
> -Jukka-
>  
> Lähettäjä: Michael Smith [mailto:michael.smith.e...@gmail.com] 
> Lähetetty: 17. marraskuuta 2016 13:49
> Vastaanottaja: Rahkonen Jukka (MML) 
> Kopio: 'gdal-dev@lists.osgeo.org' (gdal-dev@lists.osgeo.org) 
> 
> Aihe: Re: [gdal-dev] Ogr2ogr -dim and Oracle
>  
> Yes even the current version needs the layer creation option for dim. I would 
> be +1 for this change (never really understood why it was this way). I think 
> we are probably one of the biggest users of the oracle driver and I think 
> this would be a good improvement. 
> 
> Sent from my iPhone
> 
> On Nov 17, 2016, at 2:06 AM, Rahkonen Jukka (MML) 
>  wrote:
> 
> Hi,
>  
> I noticed that Even was editing the ogr2ogr help about the –dim parameter and 
>  remembered that I think that it does not have an effect on the OCI driver. 
> For forcing a new Oracle table into 2D you must use the OCI drivers own layer 
> creation option “DIM” instead http://www.gdal.org/drv_oci.html. I am not sure 
> if that happens also with the current GDAL version.
>  
> -Jukka Rahkonen-
> ___
> 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

Re: [gdal-dev] Ogr2ogr -dim and Oracle

2016-11-17 Thread Rahkonen Jukka (MML) 
Hi,

I would also check how ogr2ogr options –a_srs and –t_srs  behave or if the OCI 
driver option –lco SRID is still needed.

-Jukka-

Lähettäjä: Michael Smith [mailto:michael.smith.e...@gmail.com]
Lähetetty: 17. marraskuuta 2016 13:49
Vastaanottaja: Rahkonen Jukka (MML) 
Kopio: 'gdal-dev@lists.osgeo.org' (gdal-dev@lists.osgeo.org) 

Aihe: Re: [gdal-dev] Ogr2ogr -dim and Oracle

Yes even the current version needs the layer creation option for dim. I would 
be +1 for this change (never really understood why it was this way). I think we 
are probably one of the biggest users of the oracle driver and I think this 
would be a good improvement.

Sent from my iPhone

On Nov 17, 2016, at 2:06 AM, Rahkonen Jukka (MML) 
mailto:jukka.rahko...@maanmittauslaitos.fi>>
 wrote:
Hi,

I noticed that Even was editing the ogr2ogr help about the –dim parameter and  
remembered that I think that it does not have an effect on the OCI driver. For 
forcing a new Oracle table into 2D you must use the OCI drivers own layer 
creation option “DIM” instead http://www.gdal.org/drv_oci.html. I am not sure 
if that happens also with the current GDAL version.

-Jukka Rahkonen-
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org<mailto: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

Re: [gdal-dev] Ogr2ogr -dim and Oracle

2016-11-17 Thread Michael Smith 
Yes even the current version needs the layer creation option for dim. I would 
be +1 for this change (never really understood why it was this way). I think we 
are probably one of the biggest users of the oracle driver and I think this 
would be a good improvement. 

Sent from my iPhone

> On Nov 17, 2016, at 2:06 AM, Rahkonen Jukka (MML) 
>  wrote:
> 
> Hi,
>  
> I noticed that Even was editing the ogr2ogr help about the –dim parameter and 
>  remembered that I think that it does not have an effect on the OCI driver. 
> For forcing a new Oracle table into 2D you must use the OCI drivers own layer 
> creation option “DIM” instead http://www.gdal.org/drv_oci.html. I am not sure 
> if that happens also with the current GDAL version.
>  
> -Jukka Rahkonen-
> ___
> 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

Re: [gdal-dev] Ogr2ogr -dim and Oracle

2016-11-17 Thread Even Rouault 
On jeudi 17 novembre 2016 08:06:24 CET Rahkonen Jukka (MML) wrote:
> Hi,
> 
> I noticed that Even was editing the ogr2ogr help about the -dim parameter
> and  remembered that I think that it does not have an effect on the OCI
> driver. For forcing a new Oracle table into 2D you must use the OCI drivers
> own layer creation option "DIM" instead http://www.gdal.org/drv_oci.html. I
> am not sure if that happens also with the current GDAL version.

Yes you would still need to play with the DIM layer creation option for OCI. I 
dug into history and am wondering if the current behaviour of the OCI driver 
to not use the dimension of the geometry type passed to the CreateLayer() 
method by default, but use instead 3 as default and use DIM creation option as 
an override has some rationale specific to Oracle behaviour, or is just a 
matter of history ( https://trac.osgeo.org/gdal/changeset/4057 : 14 years 
ago).
Would it make sense to change it to the behaviour of the PostGIS driver that 
usess the dimension of the geometry type passed to the CreateLayer() method by 
default by default, unless DIM is defined ( https://trac.osgeo.org/gdal/
changeset/7303 : 12 years ago)

Even


-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Ogr2ogr -dim and Oracle

2016-11-17 Thread Rahkonen Jukka (MML) 
Hi,

I noticed that Even was editing the ogr2ogr help about the -dim parameter and  
remembered that I think that it does not have an effect on the OCI driver. For 
forcing a new Oracle table into 2D you must use the OCI drivers own layer 
creation option "DIM" instead http://www.gdal.org/drv_oci.html. I am not sure 
if that happens also with the current GDAL version.

-Jukka Rahkonen-
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev