Ragi Y. Burhum a écrit :
In order to get it to work correctly, I had to use the right +towgs84
parameters from
http://earth-info.nga.mil/GandG/coordsys/onlinedatum/CountryEuropeTable.html
. Although the table showed -84 (+/-5), -107(+/-6), -120 (+/-3), for my
own purposes -87, -98, -121 see
Even Rouault kirjoitti:
Indeed, the OPT functions are exposed through swig.
I've checked that the Python osr.GetProjectionMethods() works as expected, but
I wouldn't be surprised if the other languages miss the necessary typemaps
Perl code:
use Geo::GDAL;
my $methods = Geo::OSR::GetProject
Same external libtiff 4 beta and internal geotiff as I've always
used. Actually newer, beta 3, than I used in GDAL 1.6.0 (beta 2).
Maybe something important has been updated in libtiff since beta 3?
I see that there are a lot of very recent changes in the internal
libtiff, maybe they are
William,
I might be wrong but I think that this TIFFReadDirectory error is because you need to use the GDAL
internal libtiff/geotiff libraries as in Linux:
./configure --with-libtiff=internal --with-geotiff=internal
Regards,
Ivan
William Kyngesburye wrote:
Just got done testing RC1... Autot
Just got done testing RC1... Autotests all OK on OSX except for a new
failure:
TEST: tiff_ovr_10: tiff_ovr_10_interverted ... ERROR 1:
TIFFFetchDirectory:tmp/ovr10.tif: Can not read TIFF directory count
ERROR 1: TIFFReadDirectory:Failed to read directory at offset 1276248064
fail
Faile
All,
The GDAL team is pleased to announce the release of GDAL 1.6.1 RC2.
According to the roadmap for both the 1.5.x and 1.6.x bugs, ~ 120 bugs
have been addressed in this release. Because this is our first
maintenance release in the 1.6 series, and the list is quite large, I
am not p
I was just sending this e-mail so that it can be searched through the
archives. Thanks to Even Rouault for walking me through something that
should have been obvious :)
Originally, I was having trouble finding the right parameters for gdalwarp
to be able to warp some imagery that I got from Spain.
Frank Warmerdam wrote:
>
> I will mention the rarely used OPT functions:
>
> char CPL_DLL ** OPTGetProjectionMethods();
> char CPL_DLL ** OPTGetParameterList( const char * pszProjectionMethod,
> char ** ppszUserName );
> int CPL_DLL OPTGetParameterInfo( const char
Indeed, the OPT functions are exposed through swig.
Here's the comment from swig/include/osr.i :
/*
* Python has it's own custom interface to GetProjectionMethods().which
returns
* fairly complex structure.
*
* All other languages will have a more simplistic interface which is
* exactly the
Hi Jeff,
I have no other questions, and thanks for explaining how the selection
process works.
Roger
--
On Mon, May 11, 2009 at 11:13 AM, Jeff McKenna <
jmcke...@gatewaygeomatics.com> wrote:
> Roger André wrote:
>
>> Just out of curiosity, how is the location of FOSS4G determined?
>>
>>
> There
Diaren wrote:
Using the SWIG C# libraries I'm attemtping to build a projected/Geographic
SpatialReference creation/edit dialog like you see in various GIS
applications, which has as the main components:
Projection Method
Projection Parameters
Datum
Edit Datum -> Ellipsoid, 3/7 Parameter Transfor
Roger André wrote:
Just out of curiosity, how is the location of FOSS4G determined?
There is an OSGeo conference committee[1] which manages this decision.
The general process is:
- conference committee develops a Request for hosting Proposals document
- RFP is brought to OSGeo Board for app
Roger André wrote:
Just out of curiosity, how is the location of FOSS4G determined?
Roger,
OSGeo has a "Conference Committee" that issues an RFP annually requesting
proposals from folks interested in hosting the conference. The committee
selects one proposal from the responses based on a vari
Just out of curiosity, how is the location of FOSS4G determined?
Thanks,
Roger
--
On Fri, May 8, 2009 at 6:22 AM, Frank Warmerdam wrote:
> Folks,
>
> FOSS4G is always the premier open source geospatial event of the
> year, and an important venue for MapServer and a variety of related
> project
Using the SWIG C# libraries I'm attemtping to build a projected/Geographic
SpatialReference creation/edit dialog like you see in various GIS
applications, which has as the main components:
Projection Method
Projection Parameters
Datum
Edit Datum -> Ellipsoid, 3/7 Parameter Transformation paramete
Using the SWIG C# libraries I'm attemtping to build a projected/Geographic
SpatialReference creation/edit dialog like you see in various GIS
applications, which has as the main components:
Projection Method
Projection Parameters
Datum
Edit Datum -> Ellipsoid, 3/7 Parameter Transformation paramete
You should be able to build the GRASS plugin off my GDAL framework, to
avoid unnecessary duplication, and retain all the other formats built
into my framework. Though there might be a version issue between GDAL
1.7/GRASS plugin and my GDAL 1.6 framework.
I'll look into and get back to you.
hi i'm tring to have gdal-grass installed on osx using grass7+gdal svn,
i compiled gdal, then grass,
then cd in the gdal source/frmts/grass
run make dist to create the tar.gz package.
i configured it using : ./configure --with-gdal=/usr/local/gdal/bin/
gdal-config --with-grass=/usr/local
Helo Sir,
>From your Posts,i guess you have made GDAL working on wince.
I am able to compile the GDAL for wince. But Dont know how to proceed
further.
Can you please help me in this regard providing me some simple applications
to use GDAL or any references.
regards
Mukesh kumar
--
View this mess
Hi Even,
Thank you for your very detailed explanation.
I can now see what the problem is and was able to work around it by
splitting up the larger files first that would exceed the maximum size.
Andreas
On Wed, May 6, 2009 9:36 pm, Even Rouault wrote:
> Le Wednesday 06 May 2009 16:48:06 Andreas
20 matches
Mail list logo
