Should it not be #include "gdal.h"? The <> construct is used for system
includes, whereas gdal.h counts as a user include, to be found in the include
path. But I admit my c to be a little rusty ... Peter
Riki Tiki wrote:
Hi,
I am using bloodshed dev-C++...
I have written only this
//
Bryan, (or others with such a program):
I am very interested in the python script you mention that includes
interpolation. Have you posted it to the list? (I checked through the end of
the thread and did not find it - apologies if already posted).
Many Thanks!
-Marty Petach
>>
>> gdal-dev] qu
Riki Tiki wrote:
> Hi,
>
> I am using bloodshed dev-C++...
> [...]
> when i compile and run it... it says the following:
> C:\...\main.c gdal.h: No such file or directory.
> C:\...\Makefile.win [Build Error] [main.o] Error 1
>
> can you help me to solve the problem?
I have never used this ID
Hi,
I am using bloodshed dev-C++...
I have written only this
//
#include
#include
#include
int main(int argc, char *argv[])
{
system("PAUSE");
return 0;
}
/
Before compiling it i have installed the FWTools2.4
hi all,
i wanted to write the following program in C (which i took from gdal.org)
#include "gdal.h"
int main()
{
GDALDatasetH hDataset;
GDALAllRegister();
hDataset = GDALOpen( pszFilename, GA_ReadOnly );
if( hDatase
Hello,
I experience some troubles building perl bindings on MingW.
Here is my config :
Windows XP;
MingW 5.1.6 + MSys;
Gdal1.6.2 sources from website;
ActivePerl 5.10;
I successfully built gdal library using MingW. Then I build perl bindings :
perl Makefile.pl -> everything looks fine;
dmake ->
Am Montag 12 Oktober 2009 15:53:15 schrieben Sie:
Joaquim,
thanks very much for your reply.
Just found that using '-wo' can cure the thing (a bit).
The calculus goes soemthing like:
SOURCE_EXTRA=5.5*Pixel_X/degrees_span_of_map
(degrees_span = Your wanted map in deegres)
The 5.5 [degrees] are ju
Simon,
I agree a long way with you.
But how about a solution?
I think enough smart people are involved in OSGeo, it should be possible to
get them together and create a fully Open-Source fast vector format.
I'm not one of those but I'm willing to help with the requirements,
implementation and test
Hello gdal list,
reprojecting raster images from epsg:4326 -> '+ortho +lat_0=90 lon_0=0' results
in a not closed image, missing about 5-6°. (.i.e Pacman like)
Reproducable for '+lon_0=90,180 and 270'.
Now shifting 'lon_0=6/-6' resolves the issue and the map is closed.
Reproducable for every 'lon
Hi Yilmaz,
Thank you very much!!
Now, my application and ogrinfo from GDAL/OGR works well after setting
GDAL_DATA environment variable and changing the version.
Frank is right, the question should be needed in FAQ. I think this is my fault
and I'm sorry to disturb everyone.
And I want to say "Tha
Ok,
about the WSG84 to UTM, I can fin the UTM Zone easily:
>>from osgeo import osr
>>def UTMZone(lon, lat):
>>return int((lon + 180) / 6) + 1
The problems are:
1) from WGS84 to UPS
2) from UPS to WSG84
How to do it?
Thanks!
Marco Nicoletti wrote:
>
> Dear all,
>
> I got some problems in u
Dear all,
I got some problems in using the osgeo.osr library to convert from WGS84
(lat,lon) coordinates to UTM/UPS carthographic projection.
>From UTM (zone=33, for example) to WGS84 it seems easy:
>> wgs84 = osr.SpatialReference()
>> wgs84.SetWellKnownCS('WSG84')
>> utm = osr.SpatialReference(
Matt Wilkie wrote:
I'm by no way a vector expert, but for this kind of stuff I'd go the
postgis way, at least for intermediate storage.
I've thought of this but have shied away from it because of the
overhead of installing postgis etc. just to get started. Time to get
over my shyness perhaps
13 matches
Mail list logo
