Sorry to bring this up again. I've been looking for why epsg_tr.py -proj4 is
not including the +gamma (RectifiedToSkew angle) parameter for the
+proj=omerc projection as used in EPSG:3168, EPSG:3375, etc. It seems that
it is not set in
Selon Hilmy Hashim hil...@gmail.com:
Sorry to bring this up again. I've been looking for why epsg_tr.py -proj4 is
not including the +gamma (RectifiedToSkew angle) parameter for the
+proj=omerc projection as used in EPSG:3168, EPSG:3375, etc. It seems that
it is not set in
Merci Even,
Didn't know which one is the effective code, there are so many versions
around. It's good to know that changes have been made.
I'm using QGis 1.7 dev and the About say it's using GDAL/OGR 1.8.0. How come
the +gamma is not included there?
Regards
*Hilmy*
On Thu, Apr 14, 2011 at
Selon Hilmy Hashim hil...@gmail.com:
Merci Even,
Didn't know which one is the effective code, there are so many versions
around. It's good to know that changes have been made.
I'm using QGis 1.7 dev and the About say it's using GDAL/OGR 1.8.0. How come
the +gamma is not included there?
I
I'm using OSGeo4W on Windows 7. I just checked using the OSGeo4W shell and
setting gdaldev environment epsg_tr does give me +gamma. On my Ubuntu 10.04
box with GDAL 1.7.3, the gamma is not there.
I've just updated QGis 1.7.0-114 and I don't get the gamma in the CRS
listing.
Thanks
*Hilmy*
On
Hi Even,
On Thu, 14. Apr 2011 at 09:51:54 +0200, Even Rouault wrote:
I know they have updated very recently their srs.db to sync it with GDAL
1.8.0.
Perhaps you should also update to the latest svn version of qgis ?
OSGeo4W has the qgis-dev package which is a nightly build of trunk.
But the
On 11-04-14 04:15 AM, Hilmy Hashim wrote:
I'm using OSGeo4W on Windows 7. I just checked using the OSGeo4W shell and
setting gdaldev environment epsg_tr does give me +gamma. On my Ubuntu 10.04 box
with GDAL 1.7.3, the gamma is not there.
I've just updated QGis 1.7.0-114 and I don't get the
Frank,
I now get the gamma with epsg_tr. The issue that remains is that the srs.db
that qgis uses is not synced with the latest gdal.
Thanks
*Hilmy*
On Thu, Apr 14, 2011 at 6:30 PM, Frank Warmerdam warmer...@pobox.comwrote:
On 11-04-14 04:15 AM, Hilmy Hashim wrote:
I'm using OSGeo4W on
Hello:
I'm having a hard time getting anything to work with the files I have.
Maybe the files need to be changed or translated? Joaquim mentioned
they need to be in geogs but I'm not sure how to go about checking for
that or converting to that if need be. I've included output from one
of the
Jerl,
I suggested the ps2raster way because it's one that I know well (I'm
supposed to) but probably there is also a GDAL solution (that I don't
know). Since ps2raster is a GMT program I suggest that you make this
questions in the GMT list. However, since I kind of start this I'll give
some
Joaquim:
Ok that makes more sense now. You answered some of the questions I
was having, like how can ps2raster do anything with a necdf anyway?
I just used the info for that one test file, because the contents were
shorted.
It happens with others as well like this one that has these
Folks,
FOSS4G 2011 presentation abstracts are due by tomorrow, April 15th.
If you are thinking of attending FOSS4G 2011 in Denver and have
something related to free geospatial software that you would like
to present (30 minute slots including questions) then write up an
abstract and submit it
Does anyone on the GDAL team have any suggestions on how to do this?
Thank you,
Jerl
On Tue, Apr 12, 2011 at 2:59 PM, Jerl Simpson jsimp...@wxtrends.com wrote:
Hello:
I stopped by the #gdal channel on IRC to ask this question. Thank you
for the help provided there. I thought it might be
Martin Krüger martin.krueger at gmx.com writes:
Hello
I was in need to generate tiles from a geotiff to publish the image as a
tms-service. So i was happy to find the gdal2tiles.py script which does
the job.
The only issue i stumbled over:
gdal2tiles.py generates the tiles in the google
I tried compiling the FileGDB OGR driver on ubuntu 8.04 and got a few
errors. On the first step I got:
eadam@lgis0229ubuntu:/usr/local/src/gdal$ g++ -Wall -g
ogr/ogrsf_frmts/filegdb/*.c* -shared -o ogr_filegdb.so -Iport -Igcore
-Iogr -Iogr/ogrsf_frmts -Iogr/ogrsf_frmts/filegdb -L. -lgdal
This is an informational report only, there are not problems in trunk.
Using 1.8.0 from OSGeo4W on XP, I made a mosaic of about 1200 uncompressed tifs
totally 80G.
gdalbuildvrt mosaic.vrt *.tif
Then gdal_translated that to a compressed tif of about 8G
gdal_translate mosaic.vrt
Le jeudi 14 avril 2011 16:50:16, Eli Adam a écrit :
I tried compiling the FileGDB OGR driver on ubuntu 8.04 and got a few
errors. On the first step I got:
eadam@lgis0229ubuntu:/usr/local/src/gdal$ g++ -Wall -g
ogr/ogrsf_frmts/filegdb/*.c* -shared -o ogr_filegdb.so -Iport -Igcore
-Iogr
I reviewed this a little further. I was mistaken in my first report,
the field RDSRCDATE was created as DATE (as opposed to DateTime) and
populated with null.
I had mistakenly checked and reported on the field CONST_DATE which is
created as an Integer and populated with null. (I don't know if
Le jeudi 14 avril 2011 17:02:36, Eli Adam a écrit :
I'm not aware of any recent change in the GTiff driver that could have solved
the issue you've seen. This is a bit surprising.
Could you also try with the -stable builds (based on 1.8 branch) from
http://vbkto.dyndns.org/sdk/ to compare ?
Eli Adam EAdam at co.lincoln.or.us writes:
It works (at least in OpenEV it displays quickly like it is using overviews),
except the file sizes for the
overviews seem odd and too large.
Hi,
You can check which kind of overview file you really have with gdalinfo if you
first rename the
You can check which kind of overview file you really have with gdalinfo if
you first rename the .ovr file to something.tif. Gdalinfo then shows the
compression method used and sizes of overviews. No need to do guessing
with OpenEV.
You don't even need to rename the file. GDAL doesn't care
Even,
The I have a feeling that the handling of blobs may be a little more
involved. The blobs in ESRI GeoDatabases are serialized COM SafeArrays that
contain the actual binary information. So in order to *really* access the
blob, one would have to strip the safearray portion out and expose the
PCIDSK doesn't always write in network order. I believe that it is
missing a SwapPixel. Here is a trivial patch against 1.8.0.
--- cpixelinterleavedchannel.cpp~ 2011-01-13 21:19:05.0 -0800
+++ cpixelinterleavedchannel.cpp2011-04-13 16:43:36.447932521 -0700
@@ -254,6
I'm not aware of any recent change in the GTiff driver that could have
solved
the issue you've seen. This is a bit surprising.
Could you also try with the -stable builds (based on 1.8 branch) from
http://vbkto.dyndns.org/sdk/ to compare ?
I am trying it with,
24 matches
Mail list logo
