Hi
I understand that for GDAL to support reading VPF files, I need to have the
OGDI driver.
Are there prebuilt binaries for windows 64 bit which include OGDI?
Are there prebuilt binaries of OGDI itself, which I can use to build GDAL with
that driver?
thanks
Yehiyam
On 11-08-30 06:58 PM, tang wrote:
Thanks a lot for your replay!
I got the gdal.lib,but while I link the program to this lib,it still needs
gdal18.dll. this confused me . I had tried to comment out DLLBUILD=1 ,
but the commandline programs need gdal18.dll too. even replacing all
On 11-08-30 11:24 PM, Livneh Yehiyam wrote:
Hi
I understand that for GDAL to support reading VPF files, I need to have the
OGDI driver.
Are there prebuilt binaries for windows 64 bit which include OGDI?
Are there prebuilt binaries of OGDI itself, which I can use to build GDAL with
that driver?
I want to read a multiband image(in format of .img) by using method
ReadRaster, however, I encount some problems. I just can't understand why
the data loaded to memory is wrong?
the code is like this
OSGeo.GDAL.Dataset dataSet =
You should make sure about the actual representation of the raster image,
whether it represents the pixel as floats as you have used float arrays in
the code. The last 2 parameters are used to define the byte offset of the
pixels and lines in the image ( for more info see the
Selon Tamas Szekeres szeker...@gmail.com:
You should make sure about the actual representation of the raster image,
whether it represents the pixel as floats as you have used float arrays in
the code. The last 2 parameters are used to define the byte offset of the
pixels and lines in the
Matt,
Thanks for the link but I already read this page and I have only one process
(assign projection information).
Anyway, this is always good to read this information !
List,
I successfully assigned my projection information but still have some
difference in the file size. This is not so
Hi list,
I was wondering if there is any support for reading DGN files using GDAL /
Java?
regards,
--
I.R
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Selon Yves Jacolin yjaco...@free.fr:
List,
I successfully assigned my projection information but still have some
difference in the file size. This is not so important but I wanted to
understand
the reason. Idea welcome :)
Yves,
You have a difference between the input file and the output
Selon Imran Rajjad raj...@gmail.com:
Hi list,
I was wondering if there is any support for reading DGN files using GDAL /
Java?
The Java bindings for GDAL/OGR should be able to deal with any format supported
by GDAL/OGR, DGN being one of those ( http://gdal.org/ogr/drv_dgn.html )
regards,
It seems that gdal always links it's applications to dynamic lib. at last I
change the makefile.vc in the app folder with below lines.
!IFDEF DLLBUILD
LIBS = $(GDAL_ROOT)\gdal_i.lib
!ELSE
LIBS = $(GDAL_ROOT)\gdal.lib $(GDAL_ROOT)\ogr\ogr.lib
$(GDAL_ROOT)\port\cpl.lib
On 2011/08/31 14:41, Even Rouault wrote:
Selon Imran Rajjadraj...@gmail.com:
Hi list,
I was wondering if there is any support for reading DGN files using GDAL /
Java?
The Java bindings for GDAL/OGR should be able to deal with any format supported
by GDAL/OGR, DGN being one of those (
Yehiyam,
current OGDI sources (betas) need a bit of tweaking, if you want it to build
yourself.
Version 3.1.5 is far way better to build.
Best regards
Martin
-Original Message-
From: gdal-dev-boun...@lists.osgeo.org
[mailto:gdal-dev-boun...@lists.osgeo.org] On Behalf Of Frank
Thank for both of you, I will try according to your suggestion.
--
View this message in context:
http://osgeo-org.1803224.n2.nabble.com/The-problem-when-using-ReadRaster-C-method-tp6745826p6746581.html
Sent from the GDAL - Dev mailing list archive at Nabble.com.
Sommer, Martin wrote:
current OGDI sources (betas) need a bit of tweaking, if you want it to build
yourself.
Version 3.1.5 is far way better to build.
It's just an imprecise annotation, yet I'd like to share my findings
with you that the simple joy of getting an OGDI library built without
I am sure the original data is available, because I see the imges in ENVI and
have loaded it to MATLAB, so how can I inspect the values by
gdallocationinfo??Thanks !
--
View this message in context:
Thank you for all the insight. I guess I will try to build 3.1.5 or take the
precompiled from OSGeo4W.
Sent from my mobile
-
From: Martin Spott
Subject: Re: [gdal-dev] VPF support
Date: 31 אוגוסט 2011 16:51
Sommer, Martin wrote:
current OGDI sources (betas) need
Hello Even,
Le mercredi 31 août 2011 14:38:53, Even Rouault a écrit :
Selon Yves Jacolin yjaco...@free.fr:
List,
I successfully assigned my projection information but still have some
difference in the file size. This is not so important but I wanted to
understand
the reason. Idea
Tams:
I extract the first band of that multiband image and save it as another
img file, then the read to that single band is successful ! So maybe the
mistake is due to the code get first band?
--
View this message in context:
Le 31/08/2011 14:13, Yves Jacolin a écrit :
Another question: I have 2 000 ECW files (40 Mo each), 49 ECW files (1 Go each)
and 2 ECW files (2 Go each). I worked first on 2 Go ECW file, it takes around 1
day to assign the projection information in the files.
Do you think this is normal? How
LinkedIn
sn jo requested to add you as a connection on LinkedIn:
--
Brian,
I'd like to add you to my professional network on LinkedIn.
- sn
Accept invitation from sn jo
Le mercredi 31 août 2011 14:38:53, Even Rouault a écrit :
It contains a possible workaround
(altough you will find it quite ironic if you keep in memory what has been
said previously in this thread about gdalwarp being slower than
gdal_translate ;-)).
ouaaah, indeed it is really fast, the
Le mercredi 31 août 2011 17:18:35, Yves Jacolin a écrit :
Le mercredi 31 août 2011 14:38:53, Even Rouault a écrit :
It contains a possible workaround
(altough you will find it quite ironic if you keep in memory what has
been said previously in this thread about gdalwarp being slower than
Hello,
I have a Lambert Conformal Conic image that crosses the 180 dateline and I
want to gdalwarp to a latlong projection. The result image wraps around the
globe instead of just crossing the dateline. It seems to be a problem with
the western hemisphere because I have tried a -te option with
Hi Jim,
proj.4 (cs2cs) has a parameter to force lat long coords into a +-180 or 0-360
space by specifying the output central meridian.
From the proj.4 changelog:
2006-10-12 Frank Warmerdam warmer...@pobox.com
* Added experimental +lon_wrap argument to set a center point for
Hendy
1)
I added an item on the wiki page under I/O issues, can you make a detailed
ticket and link to it on the wiki?
In the mean time, please use Even's suggestion of using an intermediary format
such as VRT.
* Support Create() method so that gdalwarp can be used on a netcdf file
It's
Hi Devs,
When troubleshooting geodata integrity issues, we sometimes use ogr2ogr
to push WKT expressions to a .csv file using a script like I show below.
It uses an ogr sql statement to grab a single feature from a raw
shapefile data source, then it saves the output to a CSV:
ogr2ogr -f CSV
Le mercredi 31 août 2011 22:44:55, Elijah Robison a écrit :
Hi Devs,
When troubleshooting geodata integrity issues, we sometimes use ogr2ogr
to push WKT expressions to a .csv file using a script like I show below.
It uses an ogr sql statement to grab a single feature from a raw
shapefile
On Wed, Aug 31, 2011 at 1:52 PM, Even Rouault
even.roua...@mines-paris.org wrote:
Le mercredi 31 août 2011 22:44:55, Elijah Robison a écrit :
Hi Devs,
When troubleshooting geodata integrity issues, we sometimes use ogr2ogr
to push WKT expressions to a .csv file using a script like I show
On 31/08/2011 22:52, Even Rouault wrote:
Yes, as a output filename, you can use the special name /vsistdout/ (you need
the trailing slash) . You likely need GDAL 1.8 or later for it to work.
Even,
Thanks for the hint. Is there a specific reason why the csv driver isn't
able to use
Le mercredi 31 août 2011 23:08:36, Hermann Peifer a écrit :
On 31/08/2011 22:52, Even Rouault wrote:
Yes, as a output filename, you can use the special name /vsistdout/ (you
need the trailing slash) . You likely need GDAL 1.8 or later for it to
work.
Even,
Thanks for the hint. Is
Rad. :)
Thanks, Even.
It took me a few minutes to realize that -f CSV still applied --- but
now I'm catching on. I presume the following statement is true:
The special /vsistdout/ file path will output ogr2ogr results directly
to the console, provided the output type is a text-based format
Le jeudi 01 septembre 2011 00:19:52, Elijah Robison a écrit :
Rad. :)
Thanks, Even.
It took me a few minutes to realize that -f CSV still applied --- but
now I'm catching on. I presume the following statement is true:
The special /vsistdout/ file path will output ogr2ogr results
But the ecwhdr utility that Jean-Claude mentionned is really what you would
want to use, if you indeed just want to alter the projection info and/or
georeferenced bounds. I thought that there was only a Erdas utility to
achieve that, cool to see that it can be done with the SDK API. This
Message: 6
Date: Wed, 31 Aug 2011 13:05:11 -0700 (PDT)
From: Etienne Tourigny etienne...@yahoo.com
Subject: Re: Fwd: [gdal-dev] Re: discussion on improvements to the
NetCDF driver and CF-1 convention
To: Hendy Sumanto hsuma...@vpac.org, gdal-dev@lists.osgeo.org
2)
I assume your file is in a projected CRS?
Yes, it projected CRS.
In any case, the current implementation is not 100% CF compliant. GDAL can
read them (through custom tags), but other software cannot.
I have submitted a patch to fix geographic CRS only.
I have tried your patch for
36 matches
Mail list logo
