Even Rouault wrote:
> Le mercredi 11 avril 2012 14:21:09, Jukka Rahkonen a écrit :
>> Hi,
>>
>> Do we have anything that could be used for injecting GMLJP2 georeferencing
>> metadata from a text file into an existing JPEG2000 image? I found a tool
>> called "JP2 Meta Editor" by a company j2k-codec
Hi,
I am wondering why there is such a large difference in the time to convert a
large O(250MB) Jpeg2000 image to GeoTiff format in comparison with
conversion to other formats (e.g. jpeg, png)?
I am using the Kakadu Jpeg2000 driver. With a 43221 x 36021 Jpeg2000 image.
Results of timed conversio
Le vendredi 13 avril 2012 00:29:18, Jim Bellenger a écrit :
> The http://www.gdal.org/frmt_pdf.html page talks about georeferencing
> PDF files using the OGC best practice and the ISO standard so I was
> wondering if GDAL or OGR can be used georeference existing vector
> based PDF files. I have ve
The http://www.gdal.org/frmt_pdf.html page talks about georeferencing
PDF files using the OGC best practice and the ISO standard so I was
wondering if GDAL or OGR can be used georeference existing vector
based PDF files. I have vector PDF files that I know the
georeferencing but I don't know how t
On 12-04-2012 22:32, Frank Warmerdam wrote:
On Thu, Apr 12, 2012 at 2:31 PM, Frank Warmerdam wrote:
On Thu, Apr 12, 2012 at 2:09 PM, Joaquim Luis wrote:
While at this, could I make a small request that VERSION variable in
nmake.opt be wrapped in a IFNDEF so that we can optionally set it insid
Le mercredi 11 avril 2012 14:21:09, Jukka Rahkonen a écrit :
> Hi,
>
> Do we have anything that could be used for injecting GMLJP2 georeferencing
> metadata from a text file into an existing JPEG2000 image? I found a tool
> called "JP2 Meta Editor" by a company j2k-codec which is usable for
> indi
On Thu, Apr 12, 2012 at 2:31 PM, Frank Warmerdam wrote:
> On Thu, Apr 12, 2012 at 2:09 PM, Joaquim Luis wrote:
>> While at this, could I make a small request that VERSION variable in
>> nmake.opt be wrapped in a IFNDEF so that we can optionally set it inside
>> nmake.local? It would be something
On Thu, Apr 12, 2012 at 2:09 PM, Joaquim Luis wrote:
> While at this, could I make a small request that VERSION variable in
> nmake.opt be wrapped in a IFNDEF so that we can optionally set it inside
> nmake.local? It would be something like
>
> # Version number embedded in DLL name.
> !IFNDEF VERS
On 12-04-2012 16:00, Ivan Lucena wrote:
Olá Joaquim,
Sometimes a SVN update bring things that require a complete clean up before we
can rebuild it again, so you need to run:
nmake -f makefile.vc clean
nmake -f makefile.vc
nmake -f makefile.vc install
Ivan, obrigado but ... I wish it was that
looks to me like you do not have write permissions for that directory.
If on linux try 'cp 11MAY05170702-P1BS-052548267010_01_P001.NTF tmp1.NTF'
On Thu, Apr 12, 2012 at 4:54 PM, Jonathan Greenberg wrote:
> Here's it with debug ON:
>
>> gdal_translate -of ENVI 11MAY05170702-P1BS-052548267010_01_P
Here's it with debug ON:
> gdal_translate -of ENVI 11MAY05170702-P1BS-052548267010_01_P001.NTF
> 11MAY05170702-P1BS-052548267010_01_P001.envi --debug ON
GDAL:
GDALOpen(/vsisubfile/3884_395220981,11MAY05170702-P1BS-052548267010_01_P001.NTF,
this=0x66a420) succeeds as JPEG2000.
GDAL: NITFDataset::
On Thu, Apr 12, 2012 at 12:40 PM, Jonathan Greenberg wrote:
> GDALers:
>
> I've got some DigitalGlobe Worldview-2 files in NITF format, but I'm
> not able to convert it from NITF to ENVI:
>
>> gdal_translate -of ENVI 11MAY05170702-M1BS-052548267010_01_P001.NTF
>> 11MAY05170702-M1BS-052548267010_0
GDALers:
I've got some DigitalGlobe Worldview-2 files in NITF format, but I'm
not able to convert it from NITF to ENVI:
> gdal_translate -of ENVI 11MAY05170702-M1BS-052548267010_01_P001.NTF
> 11MAY05170702-M1BS-052548267010_01_P001.envi
[some time passes]
Input file size is 9216, 6144
0ERROR 4:
On 12-04-2012 16:24, Jeff McKenna wrote:
Hi Joaquim,
I've definitely been in a similar situation before. Most of the time,
when I get those 'LIBCMT' or 'MSVCRT' conflict messages, it is because I
built a dependent library with the /MT option by mistake, causing the
GDAL built to try to include
Hi Joaquim,
I've definitely been in a similar situation before. Most of the time,
when I get those 'LIBCMT' or 'MSVCRT' conflict messages, it is because I
built a dependent library with the /MT option by mistake, causing the
GDAL built to try to include LIBCMT.lib (but GDAL and all of its
depende
Olá Joaquim,
Sometimes a SVN update bring things that require a complete clean up before we
can rebuild it again, so you need to run:
nmake -f makefile.vc clean
nmake -f makefile.vc
nmake -f makefile.vc install
If you use one of those .vcproj generated by makegdal_gen.bat you can just
click Cr
Yes of course :
>
> ...
> ...
>
> 0
> Gray
>
> 1.tif
> 1
>DataType="UInt16" BlockXSize="8449" BlockYSize="1" />
>
>
> 0
>
>
> 2.tif
> 1
>DataType="UInt16" BlockXSize="8772" BlockYSize="1" />
>
>
Saâd,
Can you provide the vrt file causing the crash? Also, please show me the
error messages you got.
On Thu, Apr 12, 2012 at 7:21 PM, Saâd HESSANE wrote:
> Thank you Chaitanya for the answer,
>
> I do the test with the kenel element like the documentation :
>
>
>>
>> 3
>> 0. 0
Thank you Chaitanya for the answer,
I do the test with the kenel element like the documentation :
>
> 3
> 0. 0. 0. 0. 0.
> 0. 0. 0. 0.
>
>
It's the same probleme, gdal_translate crash. But if the VRTRasterBand have
Hi folks,
thank you for you hints!
It is working and I am waiting for the gdal2tiles script to build my 25GB
quadtree. :-)
Cheers,
David
--
View this message in context:
http://osgeo-org.1560.n6.nabble.com/gdal-translate-custom-binary-image-format-tp4851982p4854974.html
Sent from the GDAL - Dev
I made some false reports in the past about the build failures that
ended up being caused by no starting by a "make clean", but that is not
the case this time.
.^^
Clean and rebuild GDAL.
As I first said ...
___
gdal-dev m
On 12 April 2012 14:15, Joaquim Luis wrote:
> On 12-04-2012 13:07, Even Rouault wrote:
>> Selon Joaquim Luis:
>>
>>> Hi,
>>>
>>> I made some false reports in the past about the build failures that
>>> ended up being caused by no starting by a "make clean", but that is not
>>> the case this time.
>
On 12-04-2012 13:07, Even Rouault wrote:
Selon Joaquim Luis:
Hi,
I made some false reports in the past about the build failures that
ended up being caused by no starting by a "make clean", but that is not
the case this time.
I'm getting these errors on linking the current head.
There must be
Selon Joaquim Luis :
> Hi,
>
> I made some false reports in the past about the build failures that
> ended up being caused by no starting by a "make clean", but that is not
> the case this time.
>
> I'm getting these errors on linking the current head.
There must be something particular in your s
Saâd,
There should be a Kernel element in a KernelFilteredSource.
FYI, all the pixels whose kernel has a nodata pixel will be reported as a
nodata pixel.
On Wed, Apr 11, 2012 at 3:20 PM, Saâd HESSANE wrote:
> Hy all,
>
> I have a VRT file generated with buildvrt utility :
>
>
>> ...
>> ...
Hi David,
I have done a similar thing in the past by using the ENVI format driver.
The ENVI format is just raw binary with a very simple text header file.
You can easily create the header and then gdal will read your data.
You can find information on ENVI headers at
http://geol.hu/data/online_
Hi,
I made some false reports in the past about the build failures that
ended up being caused by no starting by a "make clean", but that is not
the case this time.
I'm getting these errors on linking the current head.
Joaquim
LIBCMT.lib(dosmap.obj) : error LNK2005: _errno already defined in
David,
GDAL's vrt driver supports defining a raw file's structure in an xml file.
You should define the VRTRawRasterBand subclass.
http://www.gdal.org/gdal_vrttut.html
On Thu, Apr 12, 2012 at 5:09 PM, vonengel wrote:
> Hi folks,
>
> I am quite new with gdal, and I am using it (or to be precise
Hi folks,
I am quite new with gdal, and I am using it (or to be precise gdal2tiles) to
create a quadtree representation of large panoramic images (for further
out-of-core rendering). I now got a large dataset (30x3) in a simple
binary format (The 8bit RGB information is simply stored in se
Le 11 avril 2012 10:01, Ari Jolma a écrit :
> In the Perl bindings all strings going to GDAL internals are upgraded from
> Perl internal format to utf-8 and all strings coming from GDAL internals are
> marked for Perl to be utf-8.
>
> This is done in the Perl typemaps after a change last November.
Hi,
The compile phase seems to work, but when it comes to the linking there is
something missing:
1>Link:
1> zlib.lib(crc32.obj) : MSIL .netmodule or module compiled with /GL found;
restarting link with /LTCG; add /LTCG to the link command line to improve
linker performance
1> Creating li
31 matches
Mail list logo
