Michael,
It looks like both the images have the transparency issue.
Please provide the gdalinfo outputs of the rasters.
Specifying the extents in gdal_merge.py will definitely speed things up.
Scaling time has many more variables. It is probably faster in
gdal_translate. Also, gdal_translate
Hi
I'm trying to make a transformation between ud50 and etrs98 for some files
shp. This transformation must do it through the grid system (NTv2). To do
this I have the official transformation file
(http://www.ign.es/ign/layoutIn/herramientas.do). I read that 1.8 has a GDAL
driver specific to that
Hello and thank you for that answer.
I think if it was a rounding effect that appears at display time when
ogrinfo outputs the WKT representation, I should have the same results
on several data but this is notthe case.
Indeed,by querying topology between the source layer and output layer
Hi all,
This has come up before, but I'm still struggling for an answer. I want
to rubbersheet an already projected image with control points, so as to
remove small errors.On a suggestion by Frank
(http://lists.osgeo.org/pipermail/gdal-dev/2009-February/019775.html) I
produced a VRT file of
Selon Sylvain MAFFREN sylvain.maff...@crige-paca.org:
Hello and thank you for that answer.
I think if it was a rounding effect that appears at display time when
ogrinfo outputs the WKT representation, I should have the same results
on several data but this is notthe case.
Indeed,by
Hi jblazquez,
for vector files use ogr2ogr.
Gr
Ralf
Am Donnerstag 07 Juli 2011, 11:38:56 schrieb jblazquez:
Hi
I'm trying to make a transformation between ud50 and etrs98 for some files
shp. This transformation must do it through the grid system (NTv2). To do
this I have the official
Jan,
If you are just going to shift the image, just the GeoTransform element
should be enough. You don't need the GCPs.
On Thu, Jul 7, 2011 at 3:04 PM, Jan Hartmann j.l.h.hartm...@uva.nl wrote:
**
Hi all,
This has come up before, but I'm still struggling for an answer. I want to
On Thu, Jul 7, 2011 at 2:38 AM, jblazquez jiblazquezmo...@gmail.com wrote:
Hi
I'm trying to make a transformation between ud50 and etrs98 for some files
shp. This transformation must do it through the grid system (NTv2). To do
this I have the official transformation file
Michael,
On 7/6/2011 at 5:35 PM, in message 4e14ff42.50...@cironline.org, Michael
Corey mco...@cironline.org wrote:
Sure, I've uploaded samples here.
http://www.mikejcorey.com/spatial/diablo-box-sample.tif
http://www.mikejcorey.com/spatial/diablo-cutout-sample.tif
I don't notice the
Frank,
I have found 2 issues related to the mssql spatial and the mapinfo tab
driver.
http://trac.osgeo.org/gdal/ticket/4149
http://trac.osgeo.org/gdal/ticket/4150
Committed the fix for each and it would be great to have these changes in
1.8.1
Best regards,
Tamas
2011/7/7 Frank Warmerdam
signature
database 6272 (20110707) __
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Congrats for the new job, Frank!
Best regards,
Tamas
2011/7/7 Frank Warmerdam warmer...@pobox.com
Sylvain,
Consider it mentioned now! I had my first day today (lots to take in).
I discussed this on my blog at:
http://fwarmerdam.blogspot.com/2011/06/joining-google.html
The short
Tamas,
I have also discovered that I got the release date wrong by one
month in the RC1 so I will change my vote to -1 on the RC1. I'll
prepare an RC2 - likely tonight.
Best regards,
On Thu, Jul 7, 2011 at 7:21 AM, Tamas Szekeres szeker...@gmail.com wrote:
Frank,
I have found 2 issues
database 6272 (20110707) __
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Hi,
I posted a patch to solve this issue... It fecthes the metadata
from the subdaset opened (it keeps the global metadata and it adds the
subdaset metadata to it) I tested it and it is working... Please
review it to see it isn' disruptive with the rest of the driver's
logic.
Thanks for your responses, Chaitanya and Eli. The semitransparency isn't
really noticeable until you put the image on top of something else (in
Photoshop or another program).
It looks like the problem is actually in my gdal_merge.py command.
That's where the semitransparency is getting
Well, I am about to give up on this I think and go a different route for
creating a NITF from this data.
I tried a small test file, and it takes about 45s to CopyCrate() an 80mb NITF.
here is the output I got after turning on CPL_DEBUG
GDAL: GDALOpen(/home/dcole/eraser/Images/dan_data.ntf,
Le jeudi 07 juillet 2011 19:52:34, Cole, Derek a écrit :
Well, I am about to give up on this I think and go a different route for
creating a NITF from this data.
I tried a small test file, and it takes about 45s to CopyCrate() an 80mb
NITF.
Yes, that's very poor performance !
here is
Yes, the source data is a NITF. Here is the first few lines of the projection
info in that source NITF:
Coordinate System is:
PROJCS[unnamed,
GEOGCS[WGS 84,
DATUM[WGS_1984,
SPHEROID[WGS 84,6378137,298.257223563,
AUTHORITY[EPSG,7030]],
I actually just out of curiosity tried to open the file given by this command:
gdal_translate dan_data.ntf dan_data_translate.ntf
And it turns out that dan_data_translate.ntf was actually a TIFF file that I
could view. I had to explicitly add the option -of NITF
in which case it still did the
I'm having a problem joining a Postgres table to a shapefile. I've done this
in the past with MySQL tables.
ogrinfo -al -so myshapefile.shp -sql SELECT * FROM myshapefile LEFT JOIN
'PG:dbname=mypgdb host=localhost user=someuser password='.mypgtable ON
myshapefile.keyfield = mypgtable.keyfield
Michael,
another option is to use gdalwarp to merge images together.
Brian
On Thu, 2011-07-07 at 09:47 -0700, Michael Corey wrote:
Thanks for your responses, Chaitanya and Eli. The semitransparency isn't
really noticeable until you put the image on top of something else (in
Photoshop or
Le jeudi 07 juillet 2011 21:57:31, William Kyngesburye a écrit :
I'm having a problem joining a Postgres table to a shapefile. I've done
this in the past with MySQL tables.
ogrinfo -al -so myshapefile.shp -sql SELECT * FROM myshapefile LEFT JOIN
'PG:dbname=mypgdb host=localhost
On Jul 7, 2011, at 3:17 PM, Even Rouault wrote:
Le jeudi 07 juillet 2011 21:57:31, William Kyngesburye a écrit :
I'm having a problem joining a Postgres table to a shapefile. I've done
this in the past with MySQL tables.
ogrinfo -al -so myshapefile.shp -sql SELECT * FROM myshapefile LEFT
Only simplified the names. The shapefile name starts with numbers (natural
earth shapefiles). There's the problem. I removed the leading numbers,
and simplified the shapefile names to a few letters (they're also long
names), no syntax error (segfault). Renamed with a short name with a
On Jul 7, 2011, at 4:22 PM, Even Rouault wrote:
Only simplified the names. The shapefile name starts with numbers (natural
earth shapefiles). There's the problem. I removed the leading numbers,
and simplified the shapefile names to a few letters (they're also long
names), no syntax error
So that this may help anyone in the future - it seems like I may have solved
the problem for now! After looking through gdal_translate, it appears that they
are using the C API instead of C++ for the CreateCopy. I switched my code to
the C API instead of C++ just for consistency sake, and sure
Le jeudi 07 juillet 2011 23:46:11, Cole, Derek a écrit :
So that this may help anyone in the future - it seems like I may have
solved the problem for now! After looking through gdal_translate, it
appears that they are using the C API instead of C++ for the CreateCopy. I
switched my code to the
Le vendredi 08 juillet 2011 00:25:04, Cole, Derek a écrit :
Even, thanks for the help by the way. Hopefully I can return the favor some
day, as it looks like I am going to be getting quite familiar with this.
I think the caching value was the issue perhaps,
Yes certainly, if you provided a
Greetings
I'm using gdalwarp to reproject a few tiles from platecarré to UTM WGS84
(for a specific zone). Originally they are tiles so they don't have any
blank space between them but when I reproject to UTM I get a few areas in
the borders of the image. What can I do to still have a perfect match
Greetings
I'm using gdalwarp to reproject a few tiles from platecarré to UTM
WGS84
(for a specific zone). Originally they are tiles so they don't have
any
blank space between them but when I reproject to UTM I get a few
areas in
the borders of the image. What can I do to still have a perfect
No in my case i want to reproject them first and only then to create a
mosaic. (maybe I was not clear on this)
2011/7/8 Eli Adam ea...@co.lincoln.or.us
Greetings
I'm using gdalwarp to reproject a few tiles from platecarré to UTM
WGS84
(for a specific zone). Originally they are tiles so
Kat,
The only practical way I know to avoid these slivers of
misalignment due to projections having slightly different rotations is
to mosaic first. I've been able to do that with even extremely large
files with the help the virtual file format (VRT) of GDAL. If you have
tiles in one
I haven't worked with MERIS on NDVI data but I know about MODIS:
so let's say we have four MODIS files lvl3 data:
MOD13Q1.A2010113.h08v04.005.2010133194933.hdf
MOD13Q1.A2010113.h08v05.005.2010134041223.hdf
MOD13Q1.A2010113.h09v04.005.2010135200404.hdf
MOD13Q1.A2010113.h09v05.005.2010133080730.hdf
34 matches
Mail list logo
