Nicolas Simon wrote:
Franck,
I'm interested in becoming a longer term contributor for the OCI driver.
What format do you prefer for fixes ? Patch format against main trunk ?
Nicolas,
An "svn diff" patch against trunk is the most convenient form for
patches.
I must have been doing something like that. I got frustrated and started from
scratch and am now getting the correct results.
Thank you guys help immensely. GDAL is great but the learning curve is a bit
steep at times.
From: gdal-dev-boun...@lists.osgeo.org
[mailto:gdal-dev-boun...@lis
Just out of curiosity, I ran your code on my machine and I got exactly the same
results as Even.
I do not think that Endianity will cause such wrong results. Are you sure you
are not changing the values
of new_x and new_y before printing them out?
~Belaid.
> From: even.roua...@mines-paris.org
do'h.
* http://download.osgeo.org/gdal/gdal-1.6.2-RC2.tar.gz
* http://download.osgeo.org/gdal/gdal162-RC2.zip
On Jul 31, 2009, at 1:25 PM, Even Rouault wrote:
Howard,
I'm afraid you will have to make a RC2 : gcore/gdal_version.h hasn't
been
updated.
Even
Le Friday 31 July 2009 16:08:02
Le Friday 31 July 2009 18:04:14 Jorge Arévalo, vous avez écrit :
>
> Yes, it's not commited yet. But, where do you store the overviews? The
> overviews are a kind of datasets exposed via GetOverview method and
> based in the first level dataset, right? So, when I'm creating a
> dataset, I can creat
Howard,
I'm afraid you will have to make a RC2 : gcore/gdal_version.h hasn't been
updated.
Even
Le Friday 31 July 2009 16:08:02 Howard Butler, vous avez écrit :
> All,
>
> The GDAL team is pleased to announce the release of GDAL 1.6.2 RC1.
>
> * http://download.osgeo.org/gdal/gdal-1.6.2-RC1.tar
Bill,
that's weird. Your code looks correct and I've just compiled it and I get the
following results :
lat-lon -127, 51
7.24754e-13, 4.12115e-13
The new_x, new_y values are almost 0 as expected (the small difference is due
to numerical imprecision when computing the inverse geotransform).
I
Hi All,
I found a post a while back regarding GDALApplyGeoTransform and
GDALInvGeoTransform
(http://n2.nabble.com/Converting-raster-pixel-space-to-geospace-td325875
1.html )
GDALApplyGeoTransform() will convert from pixels to georeferenced
positions
and GDALInvGeoTransform() will invert the geot
Hello,
2009/7/29 Frank Warmerdam :
> Jorge Arévalo wrote:
>>
>> Hello,
>>
>> Here, the report:
>> http://www.gis4free.org/blog/2009/07/26/gsoc-09-weekly-report-9-1707-2407/
>>
>> And here, the project page:
>> http://trac.osgeo.org/gdal/wiki/WKTRasterDriver
>
> Jorge,
>
> The progress looks good.
Franck,
I'm interested in becoming a longer term contributor for the OCI driver.
What format do you prefer for fixes ? Patch format against main trunk ?
I 'll also provide test to demonstrate the problem and the fix.
Is there a standard way to provide tes
Good catch Daniel!
Daniel knew that my orginal images were in HFA (.img) float32 and was
translated to byte and scaled . I'm trying to merge those byte-scaled
images.
The nodata value for these file is 0 and not -3.4028234663852886e+038
anymore.
What confused me is gdalinfo on those new images.
All,
The GDAL team is pleased to announce the release of GDAL 1.6.2 RC1.
* http://download.osgeo.org/gdal/gdal-1.6.2-RC1.tar.gz
* http://download.osgeo.org/gdal/gdal162-RC1.zip
The following issues were addressed in this release:
General:
* OGR expression parser causes access violations with
Hi,
Still trying to merge images...
I need to merge several images. As an example The image EstMtl.tif must be
over the image EstGa.tif.
Here is the command
gdalwarp -srcnodata -3.4028234663852886e+038 -dstnodata 0 -of "GTiff" -te
-931841.246 126213 241462 805816 -tr 30.0 30.0 EstGa.tif icu.tif
python question,
http://trac.osgeo.org/gdal/browser/trunk/autotest/gdrivers is a good place
for simple and powerful examples involving GDAL drivers.
BTW, nice mail-id!
On Thu, Jul 30, 2009 at 10:57 PM, python question
wrote:
> I am very much a beginner at python and programming altogether. I ha
Hi Chaitanya
Thanks for this information. So I'm going to commit the workaround to QGIS for
now and remove it later once your work is finished (and the corresponding OGR
version found it's way into most standard distros).
Regards,
Marco
-Ursprüngliche Nachricht-
Von: Chaitanya kumar CH
Marco,
I have been working on this. http://trac.osgeo.org/gdal/ticket/2798
On Fri, Jul 31, 2009 at 6:12 PM, Hugentobler Marco <
marco.hugentob...@karto.baug.ethz.ch> wrote:
> Hi gdal/ogr devs
>
> In QGIS, there is a bug where updates to shapefiles are not displayed until
> the spatial index of a
Hi gdal/ogr devs
In QGIS, there is a bug where updates to shapefiles are not displayed until the
spatial index of a shapefile is recreated
(http://trac.osgeo.org/qgis/ticket/1572).
It seems to me that OGR does not update the index automatically when calling
e.g. OGR_L_CreateFeature and then OG
The old one was possibly statically linked. The newer libs are just dynamic lib
files.
Von: gdal-dev-boun...@lists.osgeo.org [mailto:gdal-dev-boun...@lists.osgeo.org]
Im Auftrag von Chaitanya kumar CH
Gesendet: Freitag, 31. Juli 2009 12:53
An: ariasg...@gmx.d
Sam,
This looks like a PNG issue rather than a GDAL one. FYI, versions of libpng
used are libpng1.2.15 in GDAL1.6 and libpng1.2.35 in GDAL trunk. You may
also want to checkout libpng.org
Best regards,
--
Chaitanya kumar CH.
On Fri, Jul 31, 2009 at 1:42 PM, wrote:
> Hello,
>
> we have been usi
Hello,
we have been using an old gdal version (1.0.x) with our projects, there was the
png support compiled into the gdal library. Dependency Walker proved there were
global png_* functions in the gdal library (.dll at this point)
Due to some issues with png I had to update the png format direc
20 matches
Mail list logo
