[gdal-dev] Selecting a specific driver
Hello everybody, is there a way to explicitly specify the driver to use when opening an image? In fact, I have a Jpeg2000 image that opens well with the MrSID driver, but not with other Jpeg2000 drivers... sadly, the MrSID driver is not chosen by default. I saw that GDALOpenInternal allowed to select allowed drivers, but it is not accesible out of GDAL ... Is there an other way? Thanks Gwen ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Re: Selecting a specific driver
Gwenael LE NOC gwenael.le-noc at wanadoo.fr writes: Hello everybody,is there a way to explicitly specify the driver to use when opening an image?In fact, I have a Jpeg2000 image that opens well with the MrSID driver, but not with other Jpeg2000 drivers... sadly, the MrSID driver is not chosen by default.I saw that GDALOpenInternal allowed to select allowed drivers, but it is not accesible out of GDAL ...Is there an other way?ThanksGwen Hi, At least it is possible to skip one driver by setting GDAL_SKIP= environment variable for the driver to be skipped. There can be many JPEG2000 drivers configured but I do not know if it is possible to skip several drivers by giving a list. -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] download.osgeo.org down?
On Thu, Mar 17, 2011 at 06:31:39PM +0100, Jorge Arévalo wrote: I can't access the page since yesterday. Someone else? On the GFOSS.it mailing list (Italian users) was noticed the same problem a wewk ago. Still not resolved. It seems a routing problem between providers. An Italian provider know to be broken: INTERB-MNT (Interbusiness, the largest Italian ISP provider) Also the Orange provider from Romania was reported to be broken. Can someone on the download.osgeo.org network check the reverse route? A ping should suffice, an example hosts to check against: 88.57.16.26 (my gateway on INTERB-MNT) -- Niccolo Rigacci Firenze - Italy ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] download.osgeo.org down?
On 11-03-18 07:50 AM, Niccolo Rigacci wrote: Can someone on the download.osgeo.org network check the reverse route? A ping should suffice, an example hosts to check against: 88.57.16.26 (my gateway on INTERB-MNT) Niccolo, I can confirm the above IP cannot be pinged from download.osgeo.org, but can be from Montreal. I will note there is a download mirror at http://download2.osgeo.org/ I would suggest we leave other dicussion of download.osgeo.org to the OSGEO System Administration Committee mailing list. 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 Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Re: Selecting a specific driver
Accroding to GDALDriverManager doc (http://www.gdal.org/classGDALDriverManager.html#6b571113d0ee5ac074a572bc4ae3df74) : All drivers specified in the space delimited list in the GDAL_SKIP environment variable will be deregistered and destroyed. It therefore seems possible to specify multiple drivers to skip, and thanks to GDALDriverManager, to unload them dynamically (and possibly to reload them after loading the image. Thanks a lot ! Gwen -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/gdal-dev-Selecting-a-specific-driver-tp6183624p6184487.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
[gdal-dev] Does WMS TMS minidriver support a local path for ServerURL?
Hi, I've built a TMS structure using gdal2tiles. I'd like to access the files directly not via a webserver. It appears the WMS TMS minidriver may be an option and I'd like to know if ServerURL supports reference to a local drive\path. Thanks much, -Jeff ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Does WMS TMS minidriver support a local path for ServerURL?
Le vendredi 18 mars 2011 21:00:12, Jeff Ruby a écrit : Hi, I've built a TMS structure using gdal2tiles. I'd like to access the files directly not via a webserver. It appears the WMS TMS minidriver may be an option and I'd like to know if ServerURL supports reference to a local drive\path. Yes, use file://a_directory_name Thanks much, -Jeff ___ 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] Open(), OpenShared(), errors, FlushCache(), and no Close() ?
Hi, I'm seeing some weird behaviors related to virtual raster datasets opened simultaneously from multiple processes. I hope I can explain so that this makes sense. Here's an excerpt of my python code: http://dpaste.com/hold/515217/ Line 8 is where I make a change to the dataset: source_ds.SetProjection(source_ds.GetGCPProjection()) I do that so that the projection for the ground control points is available for a later call to gdal.ReprojectImage(); it wasn't working until I started to use SetProjection() in this way. All of this is being called from the context of a multi-process web server, running as unprivileged user www-data under Ubuntu (this is important later). My web server error log fills up with these: ERROR 1: Failed to write .vrt file in FlushCache(). My assumption here is that because the unprivileged user can't write to the dataset file, gdal throws off an error to complain that it can't flush the dataset cache back to the original file. So far, this is just an annoyance, but one that I would expect to go away when I switched from gdal.Open() to gdal.OpenShared() with the read-only flag, like this: gdal.OpenShared(src_path, gdal.GA_ReadOnly) Still getting the errors. Meanwhile, I made a switch in web servers, from an Apache-based CGI environment to the multi-worker WSGI server Gunicorn. When I initially ran my code under Gunicorn using my normal, privileged user account, I immediately started to see failures from gdal.Open and gdal.OpenShared, specifically the assertion errors on line 4 of the dpaste above. I tried to place exclusive file locks (using fcntl.flock) around each access to a given VRT dataset, but this didn't seem to help at all. There were frequent, unpredictable errors with opening data sets in a multi-process environment *until* I switched from the privileged user to the unprivileged user. Once I did that, everything began to work normally, but I got all the old ERROR 1 reports again. It seems to me that gdal.OpenShared() with the read-only flag isn't doing what it promises, and that it's trying to write back to the files, potentially modifying them even as competing processes are accessing them. Is it possible that the overlapping processes in my privileged user scenario are seeing temporarily-empty VRT files? I'm also confused by the lack of a gdal.Close() function or something similar, and by the fact that I can't seem to make a change to a dataset in memory without gdal attempting to push that change back to disk via FlushCache(). What's the right thing to do here? Make temporary copies of small VRT data sets prior to each use so they can be safely written to and disposed of? Build a wrapper class that encapsulates copying and disposal? Figure out some way to make gdal release datasets when asked, or open them in real read-only mode? Any advice greatly appreciated! -mike. michal migurski- m...@stamen.com 415.558.1610 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Open(), OpenShared(), errors, FlushCache(), and no Close() ?
Michal,
For a reason I'm unclear (might be just historical and not desired behaviour
?), the VRT driver will try to rewrite the VRT if it has been modified.
There's however a workaround to avoid the error to pop at the closing. You can
empty the description of the dataset with source_ds.SetDescription('')
Open() or OpenShared() will not change anything about that.
In python, you close a dataset by dropping the reference to the object, for
example by assigning None to it.
I'm not clear why you have errors with your new webserver, but if you use a
multi-threaded one, did you make sure you have built GDAL with thread support
(./configure --with-threads) ? (This is now the default since GDAL 1.8.0)
Best regards,
Even
Hi,
I'm seeing some weird behaviors related to virtual raster datasets opened
simultaneously from multiple processes. I hope I can explain so that this
makes sense. Here's an excerpt of my python code:
http://dpaste.com/hold/515217/
Line 8 is where I make a change to the dataset:
source_ds.SetProjection(source_ds.GetGCPProjection())
I do that so that the projection for the ground control points is available
for a later call to gdal.ReprojectImage(); it wasn't working until I
started to use SetProjection() in this way. All of this is being called
from the context of a multi-process web server, running as unprivileged
user www-data under Ubuntu (this is important later). My web server
error log fills up with these:
ERROR 1: Failed to write .vrt file in FlushCache().
My assumption here is that because the unprivileged user can't write to the
dataset file, gdal throws off an error to complain that it can't flush the
dataset cache back to the original file. So far, this is just an
annoyance, but one that I would expect to go away when I switched from
gdal.Open() to gdal.OpenShared() with the read-only flag, like this:
gdal.OpenShared(src_path, gdal.GA_ReadOnly)
Still getting the errors.
Meanwhile, I made a switch in web servers, from an Apache-based CGI
environment to the multi-worker WSGI server Gunicorn. When I initially ran
my code under Gunicorn using my normal, privileged user account, I
immediately started to see failures from gdal.Open and gdal.OpenShared,
specifically the assertion errors on line 4 of the dpaste above. I tried
to place exclusive file locks (using fcntl.flock) around each access to a
given VRT dataset, but this didn't seem to help at all. There were
frequent, unpredictable errors with opening data sets in a multi-process
environment *until* I switched from the privileged user to the
unprivileged user. Once I did that, everything began to work normally, but
I got all the old ERROR 1 reports again.
It seems to me that gdal.OpenShared() with the read-only flag isn't doing
what it promises, and that it's trying to write back to the files,
potentially modifying them even as competing processes are accessing them.
Is it possible that the overlapping processes in my privileged user
scenario are seeing temporarily-empty VRT files? I'm also confused by the
lack of a gdal.Close() function or something similar, and by the fact that
I can't seem to make a change to a dataset in memory without gdal
attempting to push that change back to disk via FlushCache().
What's the right thing to do here? Make temporary copies of small VRT data
sets prior to each use so they can be safely written to and disposed of?
Build a wrapper class that encapsulates copying and disposal? Figure out
some way to make gdal release datasets when asked, or open them in real
read-only mode?
Any advice greatly appreciated!
-mike.
michal migurski- m...@stamen.com
415.558.1610
___
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] Open(), OpenShared(), errors, FlushCache(), and no Close() ?
Thanks Even, very helpful!
Gunicorn is not multi-thread, but it's multi-process, so there's going to be
concurrent connections to a data set even though I'm not performing any
threaded functions. I'll try what you suggest, dropping the object reference to
see what happens.
-mike.
On Mar 18, 2011, at 3:14 PM, Even Rouault wrote:
Michal,
For a reason I'm unclear (might be just historical and not desired behaviour
?), the VRT driver will try to rewrite the VRT if it has been modified.
There's however a workaround to avoid the error to pop at the closing. You
can
empty the description of the dataset with source_ds.SetDescription('')
Open() or OpenShared() will not change anything about that.
In python, you close a dataset by dropping the reference to the object, for
example by assigning None to it.
I'm not clear why you have errors with your new webserver, but if you use a
multi-threaded one, did you make sure you have built GDAL with thread support
(./configure --with-threads) ? (This is now the default since GDAL 1.8.0)
Best regards,
Even
Hi,
I'm seeing some weird behaviors related to virtual raster datasets opened
simultaneously from multiple processes. I hope I can explain so that this
makes sense. Here's an excerpt of my python code:
http://dpaste.com/hold/515217/
Line 8 is where I make a change to the dataset:
source_ds.SetProjection(source_ds.GetGCPProjection())
I do that so that the projection for the ground control points is available
for a later call to gdal.ReprojectImage(); it wasn't working until I
started to use SetProjection() in this way. All of this is being called
from the context of a multi-process web server, running as unprivileged
user www-data under Ubuntu (this is important later). My web server
error log fills up with these:
ERROR 1: Failed to write .vrt file in FlushCache().
My assumption here is that because the unprivileged user can't write to the
dataset file, gdal throws off an error to complain that it can't flush the
dataset cache back to the original file. So far, this is just an
annoyance, but one that I would expect to go away when I switched from
gdal.Open() to gdal.OpenShared() with the read-only flag, like this:
gdal.OpenShared(src_path, gdal.GA_ReadOnly)
Still getting the errors.
Meanwhile, I made a switch in web servers, from an Apache-based CGI
environment to the multi-worker WSGI server Gunicorn. When I initially ran
my code under Gunicorn using my normal, privileged user account, I
immediately started to see failures from gdal.Open and gdal.OpenShared,
specifically the assertion errors on line 4 of the dpaste above. I tried
to place exclusive file locks (using fcntl.flock) around each access to a
given VRT dataset, but this didn't seem to help at all. There were
frequent, unpredictable errors with opening data sets in a multi-process
environment *until* I switched from the privileged user to the
unprivileged user. Once I did that, everything began to work normally, but
I got all the old ERROR 1 reports again.
It seems to me that gdal.OpenShared() with the read-only flag isn't doing
what it promises, and that it's trying to write back to the files,
potentially modifying them even as competing processes are accessing them.
Is it possible that the overlapping processes in my privileged user
scenario are seeing temporarily-empty VRT files? I'm also confused by the
lack of a gdal.Close() function or something similar, and by the fact that
I can't seem to make a change to a dataset in memory without gdal
attempting to push that change back to disk via FlushCache().
What's the right thing to do here? Make temporary copies of small VRT data
sets prior to each use so they can be safely written to and disposed of?
Build a wrapper class that encapsulates copying and disposal? Figure out
some way to make gdal release datasets when asked, or open them in real
read-only mode?
Any advice greatly appreciated!
-mike.
michal migurski- m...@stamen.com
415.558.1610
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
michal migurski- m...@stamen.com
415.558.1610
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Open(), OpenShared(), errors, FlushCache(), and no Close() ?
A thing I ended up writing to deal with gdal's desire to write to the VRT files:
http://dpaste.com/hold/516167/
-mike.
On Mar 18, 2011, at 3:59 PM, Michal Migurski wrote:
Thanks Even, very helpful!
Gunicorn is not multi-thread, but it's multi-process, so there's going to be
concurrent connections to a data set even though I'm not performing any
threaded functions. I'll try what you suggest, dropping the object reference
to see what happens.
-mike.
On Mar 18, 2011, at 3:14 PM, Even Rouault wrote:
Michal,
For a reason I'm unclear (might be just historical and not desired behaviour
?), the VRT driver will try to rewrite the VRT if it has been modified.
There's however a workaround to avoid the error to pop at the closing. You
can
empty the description of the dataset with source_ds.SetDescription('')
Open() or OpenShared() will not change anything about that.
In python, you close a dataset by dropping the reference to the object, for
example by assigning None to it.
I'm not clear why you have errors with your new webserver, but if you use a
multi-threaded one, did you make sure you have built GDAL with thread
support
(./configure --with-threads) ? (This is now the default since GDAL 1.8.0)
Best regards,
Even
Hi,
I'm seeing some weird behaviors related to virtual raster datasets opened
simultaneously from multiple processes. I hope I can explain so that this
makes sense. Here's an excerpt of my python code:
http://dpaste.com/hold/515217/
Line 8 is where I make a change to the dataset:
source_ds.SetProjection(source_ds.GetGCPProjection())
I do that so that the projection for the ground control points is available
for a later call to gdal.ReprojectImage(); it wasn't working until I
started to use SetProjection() in this way. All of this is being called
from the context of a multi-process web server, running as unprivileged
user www-data under Ubuntu (this is important later). My web server
error log fills up with these:
ERROR 1: Failed to write .vrt file in FlushCache().
My assumption here is that because the unprivileged user can't write to the
dataset file, gdal throws off an error to complain that it can't flush the
dataset cache back to the original file. So far, this is just an
annoyance, but one that I would expect to go away when I switched from
gdal.Open() to gdal.OpenShared() with the read-only flag, like this:
gdal.OpenShared(src_path, gdal.GA_ReadOnly)
Still getting the errors.
Meanwhile, I made a switch in web servers, from an Apache-based CGI
environment to the multi-worker WSGI server Gunicorn. When I initially ran
my code under Gunicorn using my normal, privileged user account, I
immediately started to see failures from gdal.Open and gdal.OpenShared,
specifically the assertion errors on line 4 of the dpaste above. I tried
to place exclusive file locks (using fcntl.flock) around each access to a
given VRT dataset, but this didn't seem to help at all. There were
frequent, unpredictable errors with opening data sets in a multi-process
environment *until* I switched from the privileged user to the
unprivileged user. Once I did that, everything began to work normally, but
I got all the old ERROR 1 reports again.
It seems to me that gdal.OpenShared() with the read-only flag isn't doing
what it promises, and that it's trying to write back to the files,
potentially modifying them even as competing processes are accessing them.
Is it possible that the overlapping processes in my privileged user
scenario are seeing temporarily-empty VRT files? I'm also confused by the
lack of a gdal.Close() function or something similar, and by the fact that
I can't seem to make a change to a dataset in memory without gdal
attempting to push that change back to disk via FlushCache().
What's the right thing to do here? Make temporary copies of small VRT data
sets prior to each use so they can be safely written to and disposed of?
Build a wrapper class that encapsulates copying and disposal? Figure out
some way to make gdal release datasets when asked, or open them in real
read-only mode?
Any advice greatly appreciated!
-mike.
michal migurski- m...@stamen.com
415.558.1610
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
michal migurski- m...@stamen.com
415.558.1610
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
michal migurski- m...@stamen.com
415.558.1610
___
