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 als
Folks,
Motion: That we accept the GDAL/OGR 1.8.1RC1 package as the
final GDAL/OGR 1.8.1 release.
--
PSC members, please vote after at least some sort of testing.
Non-PSC members please let us know if you discover problems!
--
+1 Frank
--
---+--
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 summary is that while I intend to remain active working on GDAL
it won't be as much as before, and I won't be a
Sure, I've uploaded samples here.
http://www.mikejcorey.com/spatial/diablo-box-sample.tif
http://www.mikejcorey.com/spatial/diablo-cutout-sample.tif
These are the same as the images created by the process I described (but
scaled down).
To your point about specifying size in the first step --
Michael,
Can you provide screenshots of diablo-combined-center-utm10-70pct-box.tif
and diablo-combined-center-utm10-70pct-cutout.tif for comparison?
By the way, you can perform the actions of the two gdal_translate commands
in the first step with the gdal_merge.py script itself unless you want to
On Wed, Jul 6, 2011 at 5:51 PM, Even Rouault
wrote:
> It is just that CreateLayer() will declare the geometry as being Polygon,
> but
> insert MultiPolygon sometimes. That's one of the caveats with the shapefile
> format/driver that will report a layer as being of type wkbPolygon but can
> return
Hi all:
I'm using a shapefile as a clipping mask to cut out the shoreline from
some DOQ files that I have merged together. But when I do the clipping
step, I end up with unwanted semitransparency in the non-clipped areas.
I'm pretty sure the problem is only with my gdalwarp step at the end.
Luke,
Please check if there are features with duplicate FIDs in the MSSQL
datasource. The 'uniqueness' of the FIDs is not checked throughly in OGR.
Some may slip through.
Resetting the FIDs is not always desirable. Some applications might need to
retain the old FIDs.
However, having an option to
Le mercredi 06 juillet 2011 23:36:52, Luke Peterson a écrit :
> On Wed, Jul 6, 2011 at 3:56 PM, Even Rouault
ok, with the help of the traces, this makes sense now. The real issue is that
the warning and error :
> Warning 1: Geometry to be inserted is of type Multi Polygon, whereas
> the layer ge
On Wed, Jul 6, 2011 at 3:56 PM, Even Rouault
wrote:
> Le mercredi 06 juillet 2011 21:46:58, Luke Peterson a écrit :
>> What CopyLayer() is supposed to do (and the code I've written does) is
>> create a new layer based on an existing layer, copies a field set from
>> the source layer, then iterate
Jean-Claude Repetto wrote:
>
> On 07/06/11 22:54, mett wrote:
>
> I think your results are correct, because PROJ.4 gives exactly the same
> ones :
>
> proj -I -f "%.12f" +proj=lcc +lat_1=64.25 +lat_2=65.75 +lat_0=65
> +lon_0=-19 +x_0=50 +y_0=50 +datum=WGS84 +units=m +no_defs
> 258321.
Le mercredi 06 juillet 2011 23:18:21, Cole, Derek a écrit :
> I have noticed that when attempting to do this, I am able to do a gdalinfo
> on the source and destination files (even if the destination file is not
> complete, it seems the header gets created, and gdalinfo recognizes teh
> file).
>
>
On 07/06/11 22:54, mett wrote:
Jean-Claude Repetto wrote:
Probably because your projection is not cylindrical. What projection are
you using ?
The projection is
`PROJCS["User-Defined WGS84/Lambert Conformal Conic (IS.)",GEOGCS["WGS
84",DATUM["WGS_1984",SPHEROID["WGS
84",6378137,298.257223563,
I have noticed that when attempting to do this, I am able to do a gdalinfo on
the source and destination files (even if the destination file is not complete,
it seems the header gets created, and gdalinfo recognizes teh file).
Is it possible that this is taking so long because my destination fil
Jean-Claude Repetto wrote:
>
> Probably because your projection is not cylindrical. What projection are
> you using ?
> Jean-Claude
>
> The projection is
> `PROJCS["User-Defined WGS84/Lambert Conformal Conic (IS.)",GEOGCS["WGS
> 84",DATUM["WGS_1984",SPHEROID["WGS
> 84",6378137,298.257223563,AUT
A quick search for "frank warmerdam google" on Google return 53,200 results
The same search on Bing return 16,400 results
But then Bing tell us that "Related Search: .. Frank Sinatra, .. Frank Zappa,
..
Anna Frank"
Some guys at Google are going to have a chuckle
Congrat!
Sylvain.
___
On 07/06/11 22:26, mett wrote:
Hello,
thank you very much for your reply. For example:
Upper Left = (*258321.25943477*, 655225.28062628)
Lower Left = (*258321.25943477*, 574605.28062628)
here the X value is the same (258321.25943477), so, I would aspect that also
the conversion is the same relate
Hello,
thank you very much for your reply. For example:
Upper Left = (*258321.25943477*, 655225.28062628)
Lower Left = (*258321.25943477*, 574605.28062628)
here the X value is the same (258321.25943477), so, I would aspect that also
the conversion is the same related to the X value (in fact is a
On 07/06/11 21:43, mett wrote:
Hello everybody,
I'm using GDAL 1.8.0 with Java, and I do not why but I got different results
with TransformPoint with same inputs. Maybe I'm wrong, anyway see this:
Upper Left = (/258321.25943477/, 655225.28062628)
Abs: *-24.39163021771631*, 66.2996405709653
Lowe
Le mercredi 06 juillet 2011 21:46:58, Luke Peterson a écrit :
> You're right, an error should be expected from your append case -- but
> I'm not using it to append, I'm running into this FID error on a
> simple invocation of CopyLayer() in an empty schema, trying to copy a
> layer from a Shapefile
On Wed, Jul 6, 2011 at 2:47 PM, Even Rouault
wrote:
> Le mercredi 06 juillet 2011 17:11:31, Luke Peterson a écrit :
>> On Sat, Jul 24, 2010 at 10:31PM, Chaitanya kumar CH >
> Hum, wait, how come can you use CopyLayer() to append to an existing table ?
> CopyLayer() is supposed to create a new laye
Hello everybody,
I'm using GDAL 1.8.0 with Java, and I do not why but I got different results
with TransformPoint with same inputs. Maybe I'm wrong, anyway see this:
Upper Left = (/258321.25943477/, 655225.28062628)
Abs: *-24.39163021771631*, 66.2996405709653
Lower Left = (/258321.25943477/, 5746
Well, my plan originally was to create a Virtual Data set in memory, so that I
could just write to the blocks while in memory before writing to disk. It seems
like I may be just as well off to go ahead and create the copy, and then just
overwrite the block in the copy.
I have tried to switch t
Le mercredi 06 juillet 2011 17:11:31, Luke Peterson a écrit :
> On Sat, Jul 24, 2010 at 10:31PM, Chaitanya kumar CH
Hum, wait, how come can you use CopyLayer() to append to an existing table ?
CopyLayer() is supposed to create a new layer, so I don't see how it would
work with an existing targe
Le mercredi 06 juillet 2011 17:11:31, Luke Peterson a écrit :
> I'm reviving a nearly-year-old thread here, sort of. I'm trying to
> create cross-compatibility between MSSQL and PostGIS on some OGR-based
> code I wrote in Python for the MSSQL environment: I had been running
> into issues simply cr
Le mercredi 06 juillet 2011 18:50:56, Cole, Derek a écrit :
> Sorry to follow up so soon. I also tried what is int he API, using the
> following:
>
> char **papszOptions = NULL;
>
> papszOptions = CSLSetNameValue( papszOptions, "BLOCKXSIZE", "1024" );
> papszOptions = CSLSetNameValue
Sorry to follow up so soon. I also tried what is int he API, using the
following:
char **papszOptions = NULL;
papszOptions = CSLSetNameValue( papszOptions, "BLOCKXSIZE", "1024" );
papszOptions = CSLSetNameValue( papszOptions, "BLOCKYSIZE", "1024" );
poVRTDS = poVRTDriver->C
What is the proper way to set those creation options?
I have tried the following:
char* papszOptions[] = { "BLOCKXSIZE=1024", "BLOCKYSIZE=1024" };
poVRTDS = poVRTDriver->CreateCopy( "", poDataset, FALSE, papszOptions,
MyTextProgress, message);
poBand = poVRTDS->GetRasterBan
Jay,
You are right. The NITF driver is not passing the creation options on to the
jp2kak driver. The NITF driver uses jp2kak the IC=C8 creation option is set
and both the ECW and Jasper drivers are unavailable.
I think what you asked for can be implemented easily. Please create a new
ticket [1] f
Hi folks,
We are using a GDAL trunk snapshot from February 2011 (so 1.9dev ?) on a
Windows 7 environment. We have a Kakadu JPEG-2000 license and can successfully
make NITF files with JPEG-2000 compression. The compression appears to be the
default QUALITY=20 because the files are consistently
On Sat, Jul 24, 2010 at 10:31PM, Chaitanya kumar CH wrote:
>
>Esben,
>
>I am not sure why the value is not quoted in the error report. The
>PostgreSQL driver quotes the string values.
>When using CreateFeature() you need to make sure to set the feature's FID to
>OGRNullFID using SetFID(OGRNullFID)
I made a quick test with MapServer and FGS and have no problems to report.
On 11-07-05 10:44 PM, Frank Warmerdam wrote:
Folks,
I have prepared a release candidate for an RC1 release. It can
be found at:
http://download.osgeo.org/gdal/gdal-1.8.1RC1.tar.gz
http://download.osgeo.org/gdal
32 matches
Mail list logo
