I noticed that, in the GNUMakefile in the ogr/ogr_frmts/s57 directory, two
utilities are mentioned for which there is no source code.
This concerns mks57 and write_soundg. What happened to these utilities? Should
they be removed from the makefile?
Regards,
Rene Hogendoorn
On 11/16/10 02:40, Frank Warmerdam wrote:
Folks,
After 15 years of denial, and bullheadedness it is now time for me to
admit my interpretation of PixelIsPoint in GeoTIFF files is wrong. To
that
end I have prepared a brief RFC discussing how I intend to fix it. I'd
appreciate comment
Frank,
Wouldn't this apply to the netCDF grids as well? GMT has always made the
distinction on the area vs point representation. The grids created by
GMT hold that information on the global attribute node_offset. As for
other netCDF CF grids created elsewhere it is also possible to find
Does anyone know if gdal will work on Solaris 10, if so which of the prebuilt
binaries can I use? Or do I have to build the binaries from scratch?
Thanks,
George
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
George,
Corrado, George P. wrote:
Does anyone know if gdal will work on Solaris 10, if so which of the prebuilt
binaries can I use? Or do I have to build the binaries from scratch?
Build from scratch is best. I've been running it on Solaris 10 / Sparc for
years without problems. I do
Frank,
Although I agree with your answer to Joaquim's question I would like to extend
the subject a little bit.
If I understood the RFC33 correctly the CreateCopy()'s of others driver will
not going to fell the effect of that change. I mean, the GeoTransform will
still be based on the center
Ok, I've installed gcc and its dependences, but I can't figure out why I'm
getting this error when I run make. Any ideas?
make
(cd port; make)
make[1]: Entering directory `/export/gdal/gdal-1.7.3/port'
/bin/sh /export/gdal/gdal-1.7.3/libtool --mode=compile --tag=CXX g++ -g -O2
-Wall
Ivan Lucena wrote:
Frank,
Although I agree with your answer to Joaquim's question I would like to
extend the subject a little bit.
If I understood the RFC33 correctly the CreateCopy()'s of others driver will
not going to fell the effect of that change. I mean, the GeoTransform will
still be
On 16-11-2010 15:54, Frank Warmerdam wrote:
Ivan Lucena wrote:
Frank,
Although I agree with your answer to Joaquim's question I would like to
extend the subject a little bit.
If I understood the RFC33 correctly the CreateCopy()'s of others
driver will
not going to fell the effect of that
Hogendoorn, Rene wrote:
I noticed that, in the GNUMakefile in the ogr/ogr_frmts/s57 directory,
two utilities are mentioned for which there is no source code.
This concerns mks57 and write_soundg. What happened to these utilities?
Should they be removed from the makefile?
Regards,
Rene,
They
I keep forgetting to hit reply to all in gmail... so here's the conversation
I've used the compiler and utilties at http://www.sunfreeware.com/ to
compile gdal successfully.
sophia
On Tue, Nov 16, 2010 at 8:44 AM, Corrado, George P.
george.corr...@gd-ais.com wrote:
Ok cool, yeah, I'm trying
see http://trac.osgeo.org/gdal/ticket/3670
On Tue, Nov 16, 2010 at 9:53 AM, Corrado, George P.
george.corr...@gd-ais.com wrote:
Ok, I've installed gcc and its dependences, but I can't figure out why I'm
getting this error when I run make. Any ideas?
make
(cd port; make)
make[1]: Entering
Yes those files sounds right, but I haven't repackaged gdal in a couple of
years and I think I just grabbed all the libs and bin files and stuck them
into the appropriate directories. Good luck on your app.
sophia
On Tue, Nov 16, 2010 at 12:55 PM, Corrado, George P.
george.corr...@gd-ais.com
I also was getting that import error and had to make sure that I was pointing
to the python included with FWTools. Then I got this:
Traceback (most recent call last):
File gdal_merge.py, line 463, in ?
sys.exit(main())
File gdal_merge.py, line 433, in main
if quiet == 0 and verbose
2010/11/15 Frank Warmerdam warmer...@pobox.com
I have made a couple changes to gdallocationinfo based on feedback I
received when bringing it up for discussion. I am not motioning to adopt
RFC 32, making gdallocationinfo an official GDAL utility, installed
by default, documented and
Tamas Szekeres wrote:
2010/11/15 Frank Warmerdam warmer...@pobox.com
mailto:warmer...@pobox.com
I have made a couple changes to gdallocationinfo based on feedback I
received when bringing it up for discussion. I am not motioning to adopt
RFC 32, making gdallocationinfo an
The default way of doing things at my company is to treat the lower left
corner of a file as the origin. Thus when I call RasterIO on a GeoTIFF, I
make the buffer I pass as pData address to the last row of the buffer I've
allocated, and I make nLineSpace negative. This has the effect of reading
I am not totally sure, but I believe that the gdal data model always uses
the upper left corner for the origin, even on files that reference the lower
left in space. I think this is also the way rasterio handles it. See
RasterIO docs:
What does this mean?
$ gdal_translate -of Rasterlite /data/grass/global/cusa/cellhd/agc_crop
cusa.db -co DRIVER=PNG
Input file size is 695, 298
ERROR 1: In ExecuteSQL(): sqlite3_prepare(SELECT
AddGeometryColumn('cusa_metadata', 'geometry', -1, 'POLYGON', \
2)):
no such function:
Neil,
OGR's SQLite driver can read a SpatiaLite database without the SpatiaLite
library. The library is needed only for the extra features like indexes,
functions, etc. So, you probably don't have SpatiaLite configured right.
On Wed, Nov 17, 2010 at 10:11 AM, Neil Best nb...@ci.uchicago.edu
20 matches
Mail list logo
