Re: [gdal-dev] sqlite dialect and MySQL spatial input
Even Rouault even.rouault at mines-paris.org writes: I've just pushed in trunk a change to make SQLITE dialect available to all OGR drivers that have a specialized ExecuteSQL() implementation. Hi, Is this a correct interpretation: - The default SQL dialect is OGR SQL, except for databases when the default is to use the native SQL dialect of the RDBMS - The default dialect can be overridden by the -dialect parameter, which can take values OGR SQL or SQLITE and after your change this works for all drivers in a similar way. If this is right I will have a look at the documentation and see if there is something to improve. At least I would make a little addition into http://www.gdal.org/ogr2ogr.html Now there reads -dialect dialect: SQL dialect. In some cases can be used to use (unoptimized) OGR SQL instead of the native SQL of an RDBMS by passing OGRSQL. Starting with GDAL 1.10, the SQLITE dialect can also be used with any datasource. It would be good to give the alternatives and a hint about how to give OGR SQL so that the space character will not cause trouble as -dialect dialect: SQL dialect. Can take values OGR SQL or SQLITE. Should we do something also for the statement Starting with GDAL 1.10, the SQLITE dialect can also be used with any datasource which is totally true with databases only after your commit http://trac.osgeo.org/gdal/changeset/26506 -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] unable to make a valid TMS xml file
Hi,
I'm trying to use the TMS minidriver, my xml file is based on the OSM's
example and the data is an output of gdal2tiles. I've not been able to
use it with gdal 1.10 :
# gdalinfo D:\MyFolder\My_File.xml
ERROR 4 : 'D:\MyFolder\My_File.xml' not recognized as a supported file
format.
gdalinfo failed - unable to open 'D:\MyFolder\My_File.xml'.
Here is the content of the file :
GDAL_WMS
Service name=TMS
ServerUrlfile://d:/MyFolder/tiles/${z}/${x}/${y}.png/ServerUrl
/Service
DataWindow
UpperLeftX156542.969/UpperLeftX
UpperLeftY6653076.172/UpperLeftY
LowerRightX469628.906/LowerRightX
LowerRightY6457397.461/LowerRightY
TileLevel17/TileLevel
TileCountX1/TileCountX
TileCountY1/TileCountY
YOrigintop/YOrigin
/DataWindow
ProjectionEPSG:3857/Projection
BlockSizeX256/BlockSizeX
BlockSizeY256/BlockSizeY
BandsCount4/BandsCount
Cache /
/GDAL_WMS
Could you please tell me where the error ?
Regards,
Jean-Roc
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Write dataset to web output
Hi Even,
Sorry, I'm only noticing your reply now.
My use case is weird as I am using GDAL to reproject a WMS source which
doesn't offer web mercator (French Cadastral Parcels WMS) and needs some
computation on the URL (city code, CRS depending on location).
If I understand your solution, I can't directly output my datasource to
the webserver, I need to write it on disk first ?
All the best
Guillaume
Le 26/09/13 01:19, Even Rouault a écrit :
Le mercredi 25 septembre 2013 10:48:00, Guillaume Sueur a écrit :
Hi list,
I've build a python gdal script which retrieves WMS images from a remote
layer. I'd like to send the image back to the browser, but I can't
figure out how to do that...
Once I've got a correct gdal dataset, how to read it into the server
response ?
Guillaume,
Not sure to completely understand your use case, but why not just using
OpenLayers to display images from a WMS source ?
If you want to stick with your script, a solution could be to create a PNG file
from the GDAL dataset ( gdal.GetDriverByName('PNG').CreateCopy('the.png',
src_ds) ) and then dump it to the standard output of your webserver after
having written a ContentType: image/png\n\n header.
Note : you can do that without having to create a file on the regular
filesystem, but by CreateCopy'ing() instead to /vsimem/the.png and using
gdal.VSIFOpenL() / gdal.VSIFReadL() / gdal.VSIFCloseL() to get the content
into a Python buffer object ( see autotest/gcore/vsifile.py in GDAL source tree
)
Even
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Write dataset to web output
Le 01/10/2013 16:21, Guillaume Sueur a écrit : My use case is weird as I am using GDAL to reproject a WMS source which doesn't offer web mercator (French Cadastral Parcels WMS) and needs some computation on the URL (city code, CRS depending on location). If I understand your solution, I can't directly output my datasource to the webserver, I need to write it on disk first ? Hello, May be you should have a look at MapProxy, which is able to reproject on-the-fly a WMS service. Jean-Claude ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] sqlite dialect and MySQL spatial input
Le mardi 01 octobre 2013 08:58:22, Jukka Rahkonen a écrit : Even Rouault even.rouault at mines-paris.org writes: I've just pushed in trunk a change to make SQLITE dialect available to all OGR drivers that have a specialized ExecuteSQL() implementation. Hi, Is this a correct interpretation: - The default SQL dialect is OGR SQL, except for databases when the default is to use the native SQL dialect of the RDBMS - The default dialect can be overridden by the -dialect parameter, which can take values OGR SQL or SQLITE and after your change this works for all drivers in a similar way. Yes. Just to crrect : the string is OGRSQL (no space) If this is right I will have a look at the documentation and see if there is something to improve. At least I would make a little addition into http://www.gdal.org/ogr2ogr.html Now there reads -dialect dialect: SQL dialect. In some cases can be used to use (unoptimized) OGR SQL instead of the native SQL of an RDBMS by passing OGRSQL. Starting with GDAL 1.10, the SQLITE dialect can also be used with any datasource. It would be good to give the alternatives and a hint about how to give OGR SQL so that the space character will not cause trouble as -dialect dialect: SQL dialect. Can take values OGR SQL or SQLITE. Adding quote would be indeed good to avoid the confusion with space/nospace. Want to give a crack at it ? Should we do something also for the statement Starting with GDAL 1.10, the SQLITE dialect can also be used with any datasource which is totally true with databases only after your commit http://trac.osgeo.org/gdal/changeset/26506 Not sure how to render the dynamics of before and after r26506. I would perhaps just keep it as it is currently to avoid confusion. Using SQLITE dialect with a RDBMS driver is kind of unusual use case (which was the thing that was finxed with r26506). -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- Geospatial professional services http://even.rouault.free.fr/services.html ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] unable to make a valid TMS xml file
Le mardi 01 octobre 2013 14:06:20, Jean-Roc Morreale a écrit :
Hi,
I'm trying to use the TMS minidriver, my xml file is based on the OSM's
example and the data is an output of gdal2tiles. I've not been able to
use it with gdal 1.10 :
# gdalinfo D:\MyFolder\My_File.xml
ERROR 4 : 'D:\MyFolder\My_File.xml' not recognized as a supported file
format.
gdalinfo failed - unable to open 'D:\MyFolder\My_File.xml'.
Here is the content of the file :
GDAL_WMS
Service name=TMS
ServerUrlfile://d:/MyFolder/tiles/${z}/${x}/${y}.png/ServerUrl
/Service
DataWindow
UpperLeftX156542.969/UpperLeftX
UpperLeftY6653076.172/UpperLeftY
LowerRightX469628.906/LowerRightX
LowerRightY6457397.461/LowerRightY
TileLevel17/TileLevel
TileCountX1/TileCountX
TileCountY1/TileCountY
YOrigintop/YOrigin
/DataWindow
ProjectionEPSG:3857/Projection
BlockSizeX256/BlockSizeX
BlockSizeY256/BlockSizeY
BandsCount4/BandsCount
Cache /
/GDAL_WMS
Could you please tell me where the error ?
Jean-Roc,
This works for me (at least gdalinfo reports a valid dataset). Make sure that
GDAL_WMS is found at the very beginning of the file. No space, newline or any
character before.
Even
--
Geospatial professional services
http://even.rouault.free.fr/services.html
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Kernel resource leak -- Windows
Le lundi 30 septembre 2013 00:59:33, Joaquim Luis a écrit :
Hi,
I can make a ticket with this but before, let me just report it here.
- Win 64 bits GDAL build
While playing with an Intel analysis tool to chase GMT memory leaks I
got two complains respecting GDAL.
P1: Error: Kernel resource leak
P1.55: Kernel resource leak: New
c:\programs\gdaltrunk\gdal\port\cpl_multiproc.cpp(626): Error X63:
Critical section creation site: Function CPLCreateMutex: Module
C:\progs_cygw\GMTdev\gmt5\trunk\WIN64\bin\gdal_w64.dll
Code snippet:
624 if( pcs )
625 {
626InitializeCriticalSectionAndSpinCount(pcs, 4000);
627EnterCriticalSection(pcs);
628 }
The MS Help says that this can be solved with a call
to'FindCloseChangeNotification'
MSDN doesn't mention FindCloseChangeNotification as a valid function to call
related to the use of InitializeCriticalSectionAndSpinCount.
Is it really a repeated memory leak (something that will be leaked each time
you call CPLCreateMutex() - with correctly paired CPLDestroyMutex() - and that
will end up exhausting memory / kernel ressources ) or just a one time memory
leak (something that a tool like valgrind would report as 'still reachable' at
the end of the process) due to one of the main static GDAL mutex not being
freed ?
--
Geospatial professional services
http://even.rouault.free.fr/services.html
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] sqlite dialect and MySQL spatial input
Even Rouault even.rouault at mines-paris.org writes: Le mardi 01 octobre 2013 08:58:22, Jukka Rahkonen a écrit : - The default SQL dialect is OGR SQL, except for databases when the default is to use the native SQL dialect of the RDBMS - The default dialect can be overridden by the -dialect parameter, which can take values OGR SQL or SQLITE and after your change this works for all drivers in a similar way. Yes. Just to crrect : the string is OGRSQL (no space) ...Snip... It would be good to give the alternatives and a hint about how to give OGR SQL so that the space character will not cause trouble as -dialect dialect: SQL dialect. Can take values OGR SQL or SQLITE. Adding quote would be indeed good to avoid the confusion with space/nospace. Want to give a crack at it ? Not really if the string to use is OGRSQL and not OGR SQL as I thought. I noticed that ogr2ogr accepts OGR SQL but also -dialect FOO with pleasure. Want to give a crack ? Alternatively I can try to improve documentation a bit? -Jukka- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Buffering geometries
Thank you for your advice Even, it works perfectly!
i have another issue, what is the unit of dfDist from
Bufferhttp://www.gdal.org/ogr/classOGRGeometry.html#ab34b27e2c8812a0fc1dccf055b11d1a2
?
On Tue, Oct 1, 2013 at 4:02 PM, Even Rouault
even.roua...@mines-paris.orgwrote:
Le lundi 30 septembre 2013 23:12:30, federico a écrit :
Dear all, i'm trying buffer some geometries with GDAL. I have success
with
poligons and lines but i can't create the buffer when i try to do the
same
procedure with an OGRPoint.
Here is a screenshot with the buffer http://i.imgur.com/rRQuooc.jpg
I'm using the Buffer function from OGRGeometry Class in a map with WGS 84
coordinates reference system.
Anyone know what could be wrong?
This should work. Make sure your target layer can contain polygons. Your
code
sample isn't sufficient to detect what might go wrong in your case.
Just a few remarks : you are going to suffer from 3 memory leaks in your
code
sample (if it isn't an extract of your real code) :
* Buffer() returns a new geometry object. So use SetGeometryDirectly() so
that
it is owned by pnewfeature
* you should delete pnewfeature after having passed it to CreateFeature()
* you should delete pfeature when it is no longer used
Code example
OGRFeature *pfeature = player-GetNextFeature(); // Apunta al primer
feature
while (pfeature) {
OGRFeature* pnewfeature = pfeature-Clone();
pnewfeature-SetGeometry(pnewfeature-GetGeometryRef()-Buffer(bufferdist))
; pdestlayer-CreateFeature(pnewfeature);
pfeature = player-GetNextFeature();
}
--
View this message in context:
http://osgeo-org.1560.x6.nabble.com/Buffering-geometries-tp5081031.html
Sent from the GDAL - Dev mailing list archive at Nabble.com.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
--
Geospatial professional services
http://even.rouault.free.fr/services.html
--
Federico Jurio
SUR Emprendimientos Tecnológicos
Perú 345 Piso 5to Oficina B (C1067AAG)
Ciudad de Buenos Aires, Argentina
Tel. +54 (11) 4342-2976/84
federicoju...@suremptec.com.ar
www.suremptec.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Buffering geometries
Le mardi 01 octobre 2013 22:05:55, Federico Jurio a écrit :
Thank you for your advice Even, it works perfectly!
i have another issue, what is the unit of dfDist from
Bufferhttp://www.gdal.org/ogr/classOGRGeometry.html#ab34b27e2c8812a0fc1dcc
f055b11d1a2 ?
The same unit as the coordinates of your geometries : degrees if your
coordinates are in degrees, meters if they are in meters, etc...
On Tue, Oct 1, 2013 at 4:02 PM, Even Rouault
even.roua...@mines-paris.orgwrote:
Le lundi 30 septembre 2013 23:12:30, federico a écrit :
Dear all, i'm trying buffer some geometries with GDAL. I have success
with
poligons and lines but i can't create the buffer when i try to do the
same
procedure with an OGRPoint.
Here is a screenshot with the buffer http://i.imgur.com/rRQuooc.jpg
I'm using the Buffer function from OGRGeometry Class in a map with WGS
84 coordinates reference system.
Anyone know what could be wrong?
This should work. Make sure your target layer can contain polygons. Your
code
sample isn't sufficient to detect what might go wrong in your case.
Just a few remarks : you are going to suffer from 3 memory leaks in your
code
sample (if it isn't an extract of your real code) :
* Buffer() returns a new geometry object. So use SetGeometryDirectly() so
that
it is owned by pnewfeature
* you should delete pnewfeature after having passed it to CreateFeature()
* you should delete pfeature when it is no longer used
Code example
OGRFeature *pfeature = player-GetNextFeature(); // Apunta al primer
feature
while (pfeature) {
OGRFeature* pnewfeature = pfeature-Clone();
pnewfeature-SetGeometry(pnewfeature-GetGeometryRef()-Buffer(bufferdist
))
; pdestlayer-CreateFeature(pnewfeature);
pfeature = player-GetNextFeature();
}
--
View this message in context:
http://osgeo-org.1560.x6.nabble.com/Buffering-geometries-tp5081031.html
Sent from the GDAL - Dev mailing list archive at Nabble.com.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
--
Geospatial professional services
http://even.rouault.free.fr/services.html
--
Geospatial professional services
http://even.rouault.free.fr/services.html
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Buffering geometries
Thank you again, regards!
On Tue, Oct 1, 2013 at 5:16 PM, Even Rouault
even.roua...@mines-paris.orgwrote:
Le mardi 01 octobre 2013 22:05:55, Federico Jurio a écrit :
Thank you for your advice Even, it works perfectly!
i have another issue, what is the unit of dfDist from
Buffer
http://www.gdal.org/ogr/classOGRGeometry.html#ab34b27e2c8812a0fc1dcc
f055b11d1a2 ?
The same unit as the coordinates of your geometries : degrees if your
coordinates are in degrees, meters if they are in meters, etc...
On Tue, Oct 1, 2013 at 4:02 PM, Even Rouault
even.roua...@mines-paris.orgwrote:
Le lundi 30 septembre 2013 23:12:30, federico a écrit :
Dear all, i'm trying buffer some geometries with GDAL. I have success
with
poligons and lines but i can't create the buffer when i try to do the
same
procedure with an OGRPoint.
Here is a screenshot with the buffer http://i.imgur.com/rRQuooc.jpg
I'm using the Buffer function from OGRGeometry Class in a map with
WGS
84 coordinates reference system.
Anyone know what could be wrong?
This should work. Make sure your target layer can contain polygons.
Your
code
sample isn't sufficient to detect what might go wrong in your case.
Just a few remarks : you are going to suffer from 3 memory leaks in
your
code
sample (if it isn't an extract of your real code) :
* Buffer() returns a new geometry object. So use SetGeometryDirectly()
so
that
it is owned by pnewfeature
* you should delete pnewfeature after having passed it to
CreateFeature()
* you should delete pfeature when it is no longer used
Code example
OGRFeature *pfeature = player-GetNextFeature(); // Apunta al
primer
feature
while (pfeature) {
OGRFeature* pnewfeature = pfeature-Clone();
pnewfeature-SetGeometry(pnewfeature-GetGeometryRef()-Buffer(bufferdist
))
; pdestlayer-CreateFeature(pnewfeature);
pfeature = player-GetNextFeature();
}
--
View this message in context:
http://osgeo-org.1560.x6.nabble.com/Buffering-geometries-tp5081031.html
Sent from the GDAL - Dev mailing list archive at Nabble.com.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
--
Geospatial professional services
http://even.rouault.free.fr/services.html
--
Geospatial professional services
http://even.rouault.free.fr/services.html
--
Federico Jurio
SUR Emprendimientos Tecnológicos
Perú 345 Piso 5to Oficina B (C1067AAG)
Ciudad de Buenos Aires, Argentina
Tel. +54 (11) 4342-2976/84
federicoju...@suremptec.com.ar
www.suremptec.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] sqlite dialect and MySQL spatial input
Le mardi 01 octobre 2013 22:01:51, Jukka Rahkonen a écrit : Even Rouault even.rouault at mines-paris.org writes: Le mardi 01 octobre 2013 08:58:22, Jukka Rahkonen a écrit : - The default SQL dialect is OGR SQL, except for databases when the default is to use the native SQL dialect of the RDBMS - The default dialect can be overridden by the -dialect parameter, which can take values OGR SQL or SQLITE and after your change this works for all drivers in a similar way. Yes. Just to crrect : the string is OGRSQL (no space) ...Snip... It would be good to give the alternatives and a hint about how to give OGR SQL so that the space character will not cause trouble as -dialect dialect: SQL dialect. Can take values OGR SQL or SQLITE. Adding quote would be indeed good to avoid the confusion with space/nospace. Want to give a crack at it ? Not really if the string to use is OGRSQL and not OGR SQL as I thought. I noticed that ogr2ogr accepts OGR SQL but also -dialect FOO with pleasure. Want to give a crack ? Hum, not sure if that's really worth and it would not be very convenient to do the validation. For drivers such as shapefile this could be detected in the generic implementation. For other drivers with a specialized implementation, the logic is if it is 'OGRSQL' or 'SQLITE', use the OGRSQL or SQLITE implementation, otherwise whatever the string is, use the specialized implementation. Perhaps some people for the PG driver use dialect = PG ? Alternatively I can try to improve documentation a bit? I'm a bit lost at what you want to improve now, but if you feel to do it, please do so. -Jukka- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- Geospatial professional services http://even.rouault.free.fr/services.html ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] [EXTERNAL] Minimum user rights needed for Oracle driver
Jukka, Basically, you need read access to the schema.table in question. The spatial views are automatically available if a user has read access to the table. So the minimum access is GRANT SELECT on SCHEMA.TABLENAME to USERNAME; ALL_SDO_GEOM_METADATA is a view that contains metadata information for all spatial tables on which the user has SELECT permission. It is this view that OGR uses to access Oracle Spatial data. Mike -- Michael Smith US Army Corps Remote Sensing GIS/Center On 10/1/13 4:42 PM, Jukka Rahkonen jukka.rahko...@mmmtike.fi wrote: Hi, PostGIS manual page has a useful chapter about what rights GDAL user needs You must have permissions on all tables you want to read and geometry_columns and spatial_ref_sys. Misleading behavior may follow without an error message if you do not have permissions to these tables. Permission issues on geometry_columns and/or spatial_ref_sys tables can be generally confirmed if you can see the tables by setting the configuration option PG_LIST_ALL_TABLES to YES. (e.g. ogrinfo --config PG_LIST_ALL_TABLES YES PG:x) Oracle Spatial manual page http://www.gdal.org/ogr/drv_oci.html is missing this information. I have also a feeling that with Oracle there are more tables and views and Oracle system stuff involved. Is here anybody who could tell what rights GDAL user must have for a) read access b) read and write access? It would be ideal to have a comprehensive list that could be given for the ever friendly DB admins GRANT [privileges] ON [object_1] TO [user] GRANT [privileges] ON [object_2] TO [user] ... -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] [EXTERNAL] Minimum user rights needed for Oracle driver
For write access, one needs INSERT and/or UPDATE on an existing table. For a new table, a user needs CREATE TABLE and CREATE SEQUENCE access to a Schema and some tablespace allocation for the schema, ALTER USER USERNAME QUOTA SIZE on TABLESPACE Y, or GRANT UNLIMITED TABLESPACE to USERNAME. Mike -- Michael Smith US Army Corps Remote Sensing GIS/Center On 10/1/13 4:58 PM, Smith, Michael ERDC-RDE-CRREL-NH michael.sm...@erdc.dren.mil wrote: Jukka, Basically, you need read access to the schema.table in question. The spatial views are automatically available if a user has read access to the table. So the minimum access is GRANT SELECT on SCHEMA.TABLENAME to USERNAME; ALL_SDO_GEOM_METADATA is a view that contains metadata information for all spatial tables on which the user has SELECT permission. It is this view that OGR uses to access Oracle Spatial data. Mike -- Michael Smith US Army Corps Remote Sensing GIS/Center On 10/1/13 4:42 PM, Jukka Rahkonen jukka.rahko...@mmmtike.fi wrote: Hi, PostGIS manual page has a useful chapter about what rights GDAL user needs You must have permissions on all tables you want to read and geometry_columns and spatial_ref_sys. Misleading behavior may follow without an error message if you do not have permissions to these tables. Permission issues on geometry_columns and/or spatial_ref_sys tables can be generally confirmed if you can see the tables by setting the configuration option PG_LIST_ALL_TABLES to YES. (e.g. ogrinfo --config PG_LIST_ALL_TABLES YES PG:x) Oracle Spatial manual page http://www.gdal.org/ogr/drv_oci.html is missing this information. I have also a feeling that with Oracle there are more tables and views and Oracle system stuff involved. Is here anybody who could tell what rights GDAL user must have for a) read access b) read and write access? It would be ideal to have a comprehensive list that could be given for the ever friendly DB admins GRANT [privileges] ON [object_1] TO [user] GRANT [privileges] ON [object_2] TO [user] ... -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 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] [EXTERNAL] Minimum user rights needed for Oracle driver
Hi, What about if GDAL and Oracle can't find common understandment about SRID? I have seen that GDAL tries then to insert something into MDSYS.CS_SRS and with our user rights that fails always. I have not studied that further because that comes always from my error and adding -lco SRID helps which is lucky because our db admins tend to be jealous about the MDSYS area. Nothing to worry about USER/ALL_SDO_INDEX_METADATA, is it handled automatically together with read/write rights to tables and views? -Jukka- Smith, Michael wrote: For write access, one needs INSERT and/or UPDATE on an existing table. For a new table, a user needs CREATE TABLE and CREATE SEQUENCE access to a Schema and some tablespace allocation for the schema, ALTER USER USERNAME QUOTA SIZE on TABLESPACE Y, or GRANT UNLIMITED TABLESPACE to USERNAME. Mike -- Michael Smith US Army Corps Remote Sensing GIS/Center On 10/1/13 4:58 PM, Smith, Michael ERDC-RDE-CRREL-NH michael.sm...@erdc.dren.mil wrote: Jukka, Basically, you need read access to the schema.table in question. The spatial views are automatically available if a user has read access to the table. So the minimum access is GRANT SELECT on SCHEMA.TABLENAME to USERNAME; ALL_SDO_GEOM_METADATA is a view that contains metadata information for all spatial tables on which the user has SELECT permission. It is this view that OGR uses to access Oracle Spatial data. Mike -- Michael Smith US Army Corps Remote Sensing GIS/Center On 10/1/13 4:42 PM, Jukka Rahkonen jukka.rahko...@mmmtike.fi wrote: Hi, PostGIS manual page has a useful chapter about what rights GDAL user needs You must have permissions on all tables you want to read and geometry_columns and spatial_ref_sys. Misleading behavior may follow without an error message if you do not have permissions to these tables. Permission issues on geometry_columns and/or spatial_ref_sys tables can be generally confirmed if you can see the tables by setting the configuration option PG_LIST_ALL_TABLES to YES. (e.g. ogrinfo --config PG_LIST_ALL_TABLES YES PG:x) Oracle Spatial manual page http://www.gdal.org/ogr/drv_oci.html is missing this information. I have also a feeling that with Oracle there are more tables and views and Oracle system stuff involved. Is here anybody who could tell what rights GDAL user must have for a) read access b) read and write access? It would be ideal to have a comprehensive list that could be given for the ever friendly DB admins GRANT [privileges] ON [object_1] TO [user] GRANT [privileges] ON [object_2] TO [user] ... -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 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] [EXTERNAL] Minimum user rights needed for Oracle driver
The MDSYS.CR_SRS table has been deprecated. Its now a view and there are whole set of tables that are used for handling new spatial reference systems. User defined SRIDs should all be above 100 now. Specific info is at http://docs.oracle.com/cd/E16655_01/appdev.121/e17896/sdo_cs_concepts.htm#i 894537 Frankly, I think GDAL/OGR should never add an SRID to Oracle. There is a lot more to add than just the WKT specifications. Mike -- Michael Smith US Army Corps Remote Sensing GIS/Center On 10/1/13 5:28 PM, Rahkonen Jukka jukka.rahko...@mmmtike.fi wrote: Hi, What about if GDAL and Oracle can't find common understandment about SRID? I have seen that GDAL tries then to insert something into MDSYS.CS_SRS and with our user rights that fails always. I have not studied that further because that comes always from my error and adding -lco SRID helps which is lucky because our db admins tend to be jealous about the MDSYS area. Nothing to worry about USER/ALL_SDO_INDEX_METADATA, is it handled automatically together with read/write rights to tables and views? -Jukka- Smith, Michael wrote: For write access, one needs INSERT and/or UPDATE on an existing table. For a new table, a user needs CREATE TABLE and CREATE SEQUENCE access to a Schema and some tablespace allocation for the schema, ALTER USER USERNAME QUOTA SIZE on TABLESPACE Y, or GRANT UNLIMITED TABLESPACE to USERNAME. Mike -- Michael Smith US Army Corps Remote Sensing GIS/Center On 10/1/13 4:58 PM, Smith, Michael ERDC-RDE-CRREL-NH michael.sm...@erdc.dren.mil wrote: Jukka, Basically, you need read access to the schema.table in question. The spatial views are automatically available if a user has read access to the table. So the minimum access is GRANT SELECT on SCHEMA.TABLENAME to USERNAME; ALL_SDO_GEOM_METADATA is a view that contains metadata information for all spatial tables on which the user has SELECT permission. It is this view that OGR uses to access Oracle Spatial data. Mike -- Michael Smith US Army Corps Remote Sensing GIS/Center On 10/1/13 4:42 PM, Jukka Rahkonen jukka.rahko...@mmmtike.fi wrote: Hi, PostGIS manual page has a useful chapter about what rights GDAL user needs You must have permissions on all tables you want to read and geometry_columns and spatial_ref_sys. Misleading behavior may follow without an error message if you do not have permissions to these tables. Permission issues on geometry_columns and/or spatial_ref_sys tables can be generally confirmed if you can see the tables by setting the configuration option PG_LIST_ALL_TABLES to YES. (e.g. ogrinfo --config PG_LIST_ALL_TABLES YES PG:x) Oracle Spatial manual page http://www.gdal.org/ogr/drv_oci.html is missing this information. I have also a feeling that with Oracle there are more tables and views and Oracle system stuff involved. Is here anybody who could tell what rights GDAL user must have for a) read access b) read and write access? It would be ideal to have a comprehensive list that could be given for the ever friendly DB admins GRANT [privileges] ON [object_1] TO [user] GRANT [privileges] ON [object_2] TO [user] ... -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 ___ 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
[gdal-dev] EPSG 8.2 Upgrade
Folks, I have upgraded libgeotiff, GDAL and PROJ.4 trunk's with the EPSG 8.2 database definitions. I have come to the conclusion that the EPSG Postgresql .sql files are distributed in WIN1252 encoding, not LATIN1, and so some special characters - mostly in comments - should be translated better. Let me know if you see problems or have questions. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Software Developer ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
