I think Frank meant
With Even's work, it is *now* possible for many drivers to to
transparently access compressed files using the /vsigzip/ mechanism.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
On 16-1-2010 3:01, Frank Warmerdam wrote:
Instead, if this is a goal of archiving, I'd suggest archiving
the original data (in a possibly arcane format), and a copy in
a more accessable format likely to still be usable decades later.
That's what we are doing now. It's OK for practical
Oh, that makes a difference indeed! When I read Frank's long answer,
this was the only point I didn't like. How does this mechanism work?
Jan
On 16-1-2010 12:33, Even Rouault wrote:
I think Frank meant
With Even's work, it is *now* possible for many drivers to to
transparently access
Jan,
Some GDAL and OGR drivers use a specific API, the VSI File Large API, to
access files. That API mimics the semantics of standard C library IO API :
fopen - VSIFOpenL
fread - VSIFReadL
fseek - VSIFSeekL
Usually that API enables access to large files ( 4 GB) on Unix and
Windows. But
Frank Warmerdam wrote:
Mateusz Loskot wrote:
One more thing if I may, the Wiki/Roadmap say the RC1 is planned on Dec
15, 2009.
I understand the schedule has changed. Would you have new date of RC1?
Mateusz,
I'd like to issue RC1 by January 19th.
Frank,
It's perfect, thanks
Best regards,
Yes, that is clear, thanks. I see that at the moment only raster files
are supported. Would it make sense to do this for vector formats too? I
am thinking of a dump from a large PostGIS database I had to upgrade
from a 32 to a 64 bits server. I didn't like the pgdump format, as I got
in all
Jan Hartmann wrote:
Yes, that is clear, thanks. I see that at the moment only raster files
are supported.
Would it make sense to do this for vector formats too?
The VSI layer is available to all parts of GDAL and OGR.
If you scan source code of OGR drivers, you'll find that this feature
is
Python(x,y) comes with Numpy 1.3.0.
Some more info. ReadRaster() will sometimes work but sometimes not
(crashes). gdalinfo -checksum on the dataset works with no problem
whatsoever. And again, the same install on a XP machine works as
expected...
daniel
On Fri, Jan 15, 2010 at 7:43 PM,
On 16-1-2010 16:03, Mateusz Loskot wrote:
Jan Hartmann wrote:
Yes, that is clear, thanks. I see that at the moment only raster files
are supported.
Would it make sense to do this for vector formats too?
The VSI layer is available to all parts of GDAL and OGR.
If you scan source
Hi All,
I'd like to know if I can take the results of a MapServer Python mapscript
'mapImage.getBytes()' operation, and feed it into GDAL as a data source for
an in-memory raster? The MapServer docs state that the results of
'getBytes' in Python is a string of binary data. I'm not sure if GDAL
Hi Isaac,
I see that you've updated LD_LIBRARY_PATH already, but perhaps you could try
adding the lib location to ls.so.conf as well. See below for how I dealt
with similar error in the past.
--
$ gdalinfo --formats
gdalinfo: error while loading shared libraries: libgdal.so.1:
Roger André wrote:
Hi All,
I'd like to know if I can take the results of a MapServer Python
mapscript 'mapImage.getBytes()' operation, and feed it into GDAL as a
data source for an in-memory raster? The MapServer docs state that the
results of 'getBytes' in Python is a string of binary
Thanks Frank, I'll try and let you know.
BTW: Perhaps your idea of GML-output for OGR would solve the
Metadata-problem for OGR. Everyone can add whatever data they want to
the GML-file, as long as OGR knows what parts to retrieve to reconstruct
the vector map.
Jan
On 16-Jan-10 21:53, Frank
Hi Frank,
Thanks for the example. How can I specify alpha in that, for one of the
quantized 8-bit PNG's (with alpha) that MapServer produces?
They look like this:
Metadata:
Software=UMN Mapserver
Corner Coordinates:
Upper Left (0.0,0.0)
Lower Left (0.0, 256.0)
Upper Right (
I have this command, which I might have gotten from this list a few
years ago, for how to do this:
cs2cs
+proj=latlong
+datum=WGS84
+to
+proj=latlong
+ellps=GRS67
+towgs84=-57,1.0,-41,0,0,0,0
+no_defs
-f %.5f
-w5
Not sure I understand all of that, but anyway, I set it up and test it
Roger André wrote:
Hi Frank,
Thanks for the example. How can I specify alpha in that, for one of the
quantized 8-bit PNG's (with alpha) that MapServer produces?
Roger,
In a way this is simplier. It is just a one band GDT_Byte file, so more
like the first example I gave. The palette can
Hi Frank,
Ok, that makes sense. So for this to work, I will have to know (somehow)
what type of image mapserver is sending, and then instantiate a MEM dataset
with the correct parameters. Problem with that is that I can't think of a
good way to read what those parameters are out of the binary
I find that OGR does not support M value in Geometry? So there is no way to
read M values in ESRI Shapefile? If I want, how can I handle this?
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
钱晓明 wrote:
I find that OGR does not support M value in Geometry? So there is no way
to read M values in ESRI Shapefile? If I want, how can I handle this?
Kyle,
I believe that OGR does not support reading M values from shapefiles
at this time. There has been discussion of providing a
Roger André wrote:
Hi Frank,
Ok, that makes sense. So for this to work, I will have to know
(somehow) what type of image mapserver is sending, and then instantiate
a MEM dataset with the correct parameters. Problem with that is that I
can't think of a good way to read what those parameters
20 matches
Mail list logo
