Pradeep,
I have seen your screenshots.
No wonder you got the multiple declaration errors, with all the
'unterminated #ifndef' and '#endif without #if" errors. You should try to
identify the source of those errors.
I never compiled GDAL/OGR files separately from the source tree. Check if
you get
Hello Chaitanya,
ogr_core.h is present in the same directory where .cpp is present. Gdal
files, you mean the header files which are required right, I have included
all of them and are present in the same directory.
Thanks and Regards,
Pradeepkp
On Fri, May 6, 2011 at 10:22 AM, Chaitanya kumar C
Pradeep,
I see your ogr_core.h file is in a separate directory. Are you compiling ogr
without the gdal files?
Also, I couldn't open the screenshots archive.
On Fri, May 6, 2011 at 9:33 AM, Pradeepkp
wrote:
> Hello,
>
> While I am compiling the code (cpp version) given in
> http://www.gdal.org/o
Hello,
While I am compiling the code (cpp version) given in
http://www.gdal.org/ogr/ogr_apitut.html
I am getting lot of compilation errors. I am not sure why they are coming as
it is the code directly taken from the above given link. Can you please look
at the screenshots attached and let me know
Bill
gdal uses degrib to read grib files, best I can tell is it does whatever
degrib does by default
Brian
On Thu, 2011-05-05 at 22:33 +, Cassanova, Bill wrote:
> I have noticed the same thing. My question is why would gdal do a conversion
> that you had not asked for? We create some of
Thanks Even, much appreciated!
Regards, Bill Teluk.
--
View this message in context:
http://osgeo-org.1803224.n2.nabble.com/gdal-dev-EPSG-value-tp5708841p6335944.html
Sent from the GDAL - Dev mailing list archive at Nabble.com.
___
gdal-dev mailing lis
I have noticed the same thing. My question is why would gdal do a conversion
that you had not asked for? We create some of our own grib2 files that may at
times have unitless values. For some odd reason they are being converted to
Celsius as well.
Sent from my iPad
On May 5, 2011, at 5:09
Yup,
that was it. I should have looked a little closer i suppose ...
thanks
matt
On 5/5/2011 3:09 PM, Brian Case wrote:
> Matt,
>
> At a quick glance I would say pygrib is outputting in kelvin and gdal
> Celsius. also it looks like there not in the same order.
>
> Brian
>
>
>
> On Thu, 2011-05-05
Matt,
At a quick glance I would say pygrib is outputting in kelvin and gdal
Celsius. also it looks like there not in the same order.
Brian
On Thu, 2011-05-05 at 14:57 -0600, maf...@nmsu.edu wrote:
> Hi,
> i am a little confused. I am using the gdal/python and trying to read
> values from a gri
Hi,
i am a little confused. I am using the gdal/python and trying to read
values from a grib file (i can email the file if needed). I am using
pygrib to compare against. I do this with the following code:
import struct
import pygrib
from osgeo import gdal
from osgeo import ogr
from osgeo import
Le mardi 03 mai 2011 22:29:38, Jeremy a écrit :
The following works for me (in dev version, but should also work with 1.8 - I
believe) :
gdal_translate frmts/wms/frmt_wms_googlemaps_tms.xml out.tif -projwin
-12712685 6656748 -12679290 6621294 -outsize 1% 1%
> Hello,
>
>
>
> I would like t
Le mercredi 04 mai 2011 00:40:42, Kyle Shannon a écrit :
> I am using AutoCreateWarpedVRT to warp a dataset. I grab the the source
> nodata for a band using
>
> double noData = poBand->GetNoDataValue( &pbSuccess );
>
> which returns 1.#QNAN... on windows.
>
> I then try to set the INIT_
Le mercredi 04 mai 2011 16:52:02, Bborie Park a écrit :
> Hi,
>
> I'm currently in the process of seeing what can be done to expose
> GDAL's C warp functions to PostGIS Raster and am wondering if I have
> hit a roadblock.
>
> >From the docs for gdal_alg.h, it appears that the warp functionality
>
I believe that I have the example working. When using the command 'print
an_array', it wasn't showing the parts that contained non-zero data. Once I
realized that, everything seems to work as expected.
Thanks for the support.
Julianne
--
View this message in context:
http://osgeo-org.1803224.
Julianne,
You can use the Memory raster driver just like you would use any other
format driver. Use the ReadRaster() function.
Refer to http://www.gdal.org/gdal_tutorial.html
On Thu, May 5, 2011 at 7:59 PM, Juliannerc wrote:
> Thanks for the response.
>
> Are the code snippets below what you me
Thanks for the response.
Are the code snippets below what you mean by the memory drivers?
#
# Create a memory raster to rasterize into.
#
target_dr = gdal.GetDriverByName ('MEM')
target_ds = target_dr.Create ('',
1500,
For context, please see this posting from April:
http://lists.osgeo.org/pipermail/gdal-dev/2011-April/028328.html
thanks
Simon
--- On Tue, 3/5/11, Simon Payne wrote:
> From: Simon Payne
> Subject: [gdal-dev] OGR feature style spec and LABEL style parts - not
> working apparently
> To: gdal
Hello all,
I'm new one to gdal. Now I have to do some spatial data format
transformations, and I know of gdal from the internet. To avoid compiling
gdal source data I download FWTools2.7.4. According to some guidances from
the internet , I copy gdal_csharp.dll, gdalconst_csharp.dll, ogr_csharp.
Selon Bill Teluk :
> If I understand correctly from above, would it be correct to say that if
> ogrinfo/ogr2ogr doesn't see an "EPSG" value specified in the WKT, it cannot
> derive the EPSG code? eg. the ogr utilities won't translate a WKT to an EPSG
> code?
Exactly. OGR will not try to guess the
19 matches
Mail list logo
