On Thu, 25 Mar 2010, Ivan wrote:
Roger,
I in fact did my homework, but I've got a C.
As you can see on my previous message I did find the RGDAL Source Forge page
where it shows the CVS instructions === [1] ===. That would give a B+ at
least, no? If it worked.
cvs
On Thu, Mar 25, 2010 at 5:58 PM, Frank Warmerdam warmer...@pobox.com wrote:
Sunburned Surveyor wrote:
Hey Guys.
I'm trying to help Wolf administer the OSGeo Summer of Code effort
this year. He mentioned GDAL expressed some interest in participating
this year. Does GDAL have any students
Ramiro,
The C API function OGR_R_IsValid( OGRGeometryH ) may help you.
On Fri, Mar 26, 2010 at 2:02 AM, Ramiro Gonzalez
ramirogonza...@suremptec.com.ar wrote:
I won't calculate the area. I'll show an 'invalid area' message to the
user.
Thanks.
2010/3/19 Peter J Halls p.ha...@york.ac.uk
The root cause of the sourceforge issue is in a message posted 2010-03-25
from their admin:
Update on the current CVS outage that is affecting projects whose UNIX
names start with the letters a, e, h, i, m, o, r, s, w, z.
The work being done on this server may take up to two days to resolve.
Roger,
Yes, you are right. The source code is on rgdal_0.6-25.tar.gz, I know, but the
instructions to build on Windows are on the rgdal_0.6-25.zip package on
README.windows, where it says:
---
The R Windows binary rgdal package is built against an FWTools Windows binary,
using VC++.
Notes:
On Fri, 26 Mar 2010, Ivan Lucena wrote:
Roger,
Yes, you are right. The source code is on rgdal_0.6-25.tar.gz, I know, but the
instructions to build on Windows are on the rgdal_0.6-25.zip package on
README.windows, where it says:
---
The R Windows binary rgdal package is built against an
Good afternoon (at least where I am),
I was wondering if there was a cost-efficient way to find out if a topology
is valid or not. By valid, I basically mean it will not raise a
TopologyException.
I am a geo-noob, sorry if this sounds obvious.
Many thanks,
Daniel
Roger,
Pardon me for interrupting with a question I've had for a while but not
asked you.
On Windows at least, it appears that rgdal renames the GDAL shared library
(e.g. gdal16.dll) to an rgdal-specific name (e.g. libgdal-1.dll). On
windows, this has the advantage of avoiding DLL name
Hi
I just managed to compile a 64-bits GDAL trunk with VC10
There are lots of new warnings but of inocent type. However I don't
know how to judge this one that might be not so innocuous
...
C:\programs\GDALtrunk\gdal\frmtscd wms nmake /nologo /f makefile.vc
cd .. || exit 1
xcopy
On Fri, 26 Mar 2010, Jason Roberts wrote:
Roger,
Pardon me for interrupting with a question I've had for a while but not
asked you.
On Windows at least, it appears that rgdal renames the GDAL shared library
(e.g. gdal16.dll) to an rgdal-specific name (e.g. libgdal-1.dll). On
windows, this has
Frank Warmerdam wrote:
There is no public GDAL API for modifying the sourcefilename of a VRT.
Can you not just create the VRT files programmatically by inserting the
filename in a template text file?
I can, but that's still more coding than with my idea of manipulating
meta-data,
Michael,
In case you're not aware of it, you don't have to write the VRT in a on-disk
file. You can store it into a Python string instead, like :
vrt_desc =
VRTDataset rasterXSize=20 rasterYSize=20
SRSPROJCS[quot;NAD27 / UTM zone
Thanks Jorge. Don't forget the student application period starts on
March 29 and is only open for a few days.
It looks like we've got until April 21 to get GDAL mentors signed up,
but the sooner we do this the better.
I look forward to working with the GDAL team over the summer. Thank
you for
I've written some simple Python code to flip a raster in relation to the
y-axis. The raster is 2x19459 and has 4 bands of type Byte, and is
written east to west (I have no idea why). The script proceeds normally for
the first 2 bands, but slows way down after starting band 3. I let it run
Hi folks,
I'm trying to merge 3 separated tiff files to a single one ( make a
RGB composition with 3 bands) using the command:
$ gdal_merge -of GTiff -o target-RGB432.tif -separate BAND4.tif
BAND3.tif BAND2.tif
I'm running Windows 7 Pro, FWTools 2.4.7 with GDAL 1.7.0b2
and I get the following
Eduardo,
Yes, this is a known regression. See http://trac.osgeo.org/gdal/ticket/3354
You can workaround this by specifying the -q or -v flags.
Or just download
http://trac.osgeo.org/gdal/browser/branches/1.7/gdal/swig/python/scripts/gdal_merge.py?format=raw
and use it as the replacement for
Jamie,
I'm not sure why it slowdowns after the first 2 bands, but I can say your way
of proceeding is very inefficient and you can achieve the same results by
processing by rows instead of columns. As your input file is scanline
oriented (block size is 2x1 - which is pretty standard),
Thanks Even,
I had (sort of) come to that conclusion myself, as I started looking into
what blocksize actually meant. I'll modify to work in row order.
Thanks!
Jamie
On Fri, Mar 26, 2010 at 2:10 PM, Even Rouault
even.roua...@mines-paris.orgwrote:
Jamie,
I'm not sure why it slowdowns after
Hi,
This warning (LNK4221) is not related to VC 2010, it's generated also with
VC 2005 and above.
Best regards,
Tamas
2010/3/26 Joaquim Luis jl...@ualg.pt
Hi
I just managed to compile a 64-bits GDAL trunk with VC10
There are lots of new warnings but of inocent type. However I don't know
19 matches
Mail list logo
