On 12/11/2012 08:16, Nik Sands wrote:
> Is that limitation actually built into GDAL?
> Because 2-point .map files are not uncommon, and so long as the two points
> are both different in both axes, then there should be no reason why a 3rd
> point in required (especially in UTM).
>
> Nik.
Have yo
Is that limitation actually built into GDAL?
Because 2-point .map files are not uncommon, and so long as the two points are
both different in both axes, then there should be no reason why a 3rd point in
required (especially in UTM).
Cheers,
Nik.
On 12/11/2012, at 6:13 PM, Jean-Claude Repetto
On 12/11/2012 05:02, Nik Sands wrote:
>
> Please help me figure out why the two sets of .map files behave so
> differently. In particular, how can I get a spatial reference system for the
> failing .map files?
> (Content of two example files are below. First one is OK, second one fails.
> Le
Hi,
I have two sets of Ozi .map files (and corresponding ozf2 files) that behave
very differently when processed by GDAL using the following code:
char *srcWKT = (char *)GDALGetProjectionRef( hSrcDS );
if ( srcWKT == NULL || strlen(srcWKT) <= 0 )
Please ignore this thread. I've finally figured out that it was an error in
code on my part. I thought that my code was reading the .map file, when in
fact it was reading the GeoTIFF file that had been converted from the .map/ozf2
earlier in the program. My humble apologies.
(I may post a ne
I still don't have any resolution to this issue, but thanks to feedback from
one list reader, I've been prompted to find out some more information...
gdalinfo produces the following output, which is contrary to what my
application produces:
Coordinate System is `LOCAL_CS[""Ozi" projecti
Unfortunately, I did not get any reply to my message about GDAL being unable to
georeference an .ozf2 image using an ozi .map file a user sent me (see below).
Is there anybody who could take a look and help me out with this?
Please let me know if there is more information that I can provide in
> now it's my turn to be confused.
> This is pixel-by-pixel copy of a subset of the input pixels. It is a
> subwindow of the original image, exactly as you say.
> I'm taking an m x n input image and copying p x q pixels (p <= m, q <=n)
> into p x q pixels in the band. The scale is unchanged.
Ah i
On 11/11/2012 12:56 PM, Even Rouault wrote:
GDALRasterBand::WriteCropToBand(int nCropSizeX, // width of the cropped
region int nCropSizeY, // height of the cropped region int nXOffset, //
offset to the left edge of the cropped region int nYOffset, // offset to
the top of the cropped region vo
> GDALRasterBand::WriteCropToBand(int nCropSizeX, // width of the cropped
> region int nCropSizeY, // height of the cropped region int nXOffset, //
> offset to the left edge of the cropped region int nYOffset, // offset to
> the top of the cropped region void * pBuf,// pointer to the buffe
On 11/11/2012 9:25 AM, Even Rouault wrote:
The value of a new function is code clarity. It's not just computing
pData, it's that the nBufXSize and nBufYSize become the size of the
cropped region, not the size of the actual buffer,
I don't unders
Le dimanche 11 novembre 2012 20:00:37, Ben Discoe a écrit :
> +1 to everything Ragi said.
>
> Version "numbering" like "1.10" is an affront to common sense and the basic
> concept of the decimal system, not to mention every OS's filename sorting.
> If 1.10 comes after 1.9, then it would be imperat
On 11 November 2012 19:00, Ben Discoe wrote:
> +1 to everything Ragi said.
>
> Version "numbering" like "1.10" is an affront to common sense and the basic
> concept of the decimal system, not to mention every OS's filename sorting.
> If 1.10 comes after 1.9, then it would be imperative to replace
On 11 November 2012 19:07, David Strip wrote:
> On 11/11/2012 11:59 AM, Mateusz Loskot wrote:
>
>> IMO, for GDAL 2.0 the API could be improved and some symmetry
>> introduced. For example, for GDALColorTable::Clone()
>> two static methods could be added:
>>
>> static GDALColorTable* GDALColorTable
On 11/11/2012 11:59 AM, Mateusz Loskot wrote:
IMO, for GDAL 2.0 the API could be improved and some symmetry
introduced. For example, for GDALColorTable::Clone()
two static methods could be added:
static GDALColorTable* GDALColorTable::Create(GDALPaletteInterp=GPI_RGB);
static void GDALColorTabl
+1 to everything Ragi said.
Version "numbering" like "1.10" is an affront to common sense and the basic
concept of the decimal system, not to mention every OS's filename sorting.
If 1.10 comes after 1.9, then it would be imperative to replace the
misleading decimal points (which are, apparently, N
On 11 November 2012 18:22, Even Rouault wrote:
> Le dimanche 11 novembre 2012 19:16:30, David Strip a écrit :
>> If I'm reading the docs right, there is no copy constructor or
>> assignment operator for a GDALColorTable.
>> If I use GDALColorTable::clone(), how do release the copy when I'm done?
>
On 11/11/2012 11:22 AM, Even Rouault wrote:
Le dimanche 11 novembre 2012 19:16:30, David Strip a écrit :
If I'm reading the docs right, there is no copy constructor or
assignment operator for a GDALColorTable.
If I use GDALColorTable::clone(), how do release the copy when I'm done?
Do I use CPLF
Le dimanche 11 novembre 2012 19:16:30, David Strip a écrit :
> If I'm reading the docs right, there is no copy constructor or
> assignment operator for a GDALColorTable.
> If I use GDALColorTable::clone(), how do release the copy when I'm done?
> Do I use CPLFree or can I use delete?
delete should
If I'm reading the docs right, there is no copy constructor or
assignment operator for a GDALColorTable.
If I use GDALColorTable::clone(), how do release the copy when I'm done?
Do I use CPLFree or can I use delete?
Thanks.
___
gdal-dev mailing list
> The value of a new function is code clarity. It's not just computing
> pData, it's that the nBufXSize and nBufYSize become the size of the
> cropped region, not the size of the actual buffer,
I don't understand what you mean, sorry. Perhaps you should show the code. I
understand that better th
On 11/11/2012 3:53 AM, Even Rouault wrote:
Le dimanche 11 novembre 2012 03:45:57, David Strip a écrit :
The current GDALRasterBand::RasterIO signature makes it easy to read or
write a contiguous subregion of the band. However, if you want to read or
write the entire band into/from a contiguou
Le dimanche 11 novembre 2012 03:45:57, David Strip a écrit :
> The current GDALRasterBand::RasterIO signature makes it easy to read or
> write a contiguous subregion of the band. However, if you want to read or
> write the entire band into/from a contiguous sub-region of the buffer,
> it's not ne
23 matches
Mail list logo
