Re: [gdal-dev] VC10 64-bits compiling
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 > 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\frmts>cd wms && nmake /nologo /f makefile.vc && > cd .. || exit 1 >xcopy /D /Y *.obj ..\o > 0 File(s) copied >cd .. >if exist gdal.lib del gdal.lib >lib /nologo /out:gdal.lib port\*.obj gcore\*.obj alg\*.obj > frmts\o\*.obj ogr\ogrsf_frmts\ogrsf_frmts.lib ogr\ogr.lib > ogrsf_frmts.lib(parsexsd.obj) : warning LNK4221: This object file does not > define any previously undefined public symbols, so it will not be used by > any link operation that consumes this library > > Joaquim Luis > ___ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev > ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] flipping raster in python
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 wrote: > 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), reading a > column > will cause the whole file to be read at each time ! > > Try instead the following version which read line by line and horizontally > flip the buffer : it should complete in a few minutes. > > for band in range(1, indataset.RasterCount + 1): > ## Print the current band > print 'Band %s' % band > > inband = indataset.GetRasterBand(band) > outband = outdataset.GetRasterBand(band) > > count = 0 > print count > > for i in range(inband.YSize): > >## print the current interval of 1k lines >new_count = int(i / 1000) >if new_count > count: > print new_count > count = new_count > > inline = inband.ReadAsArray(0, i, inband.XSize, 1) >flipline = numpy.fliplr(inline) >outband.WriteArray(flipline, 0, i) > >inline = None > > inband = None > outband = None > > Best regards, > > Even > > Le Friday 26 March 2010 21:22:54 Jamie Adams, vous avez écrit : > > 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 overnight, and it had processed less than 1000 columnsin band 3, > > whereas the previous pace for bands 1&2 was around 1000 columns every 10 > > seconds. Here is the relevant code with a few debugging statements > > followed by the gdalinfo output. The only thing I'm noticing is that the > > input image is INTERLEAVED=BAND whereas the output is INTERLEAVED=PIXEL. > > Any help is appreciated. > > > > > --- > >--- for band in range(1, indataset.RasterCount + 1): > > ## Print the current band > > print 'Band %s' % band > > > > inband = indataset.GetRasterBand(band) > > outband = outdataset.GetRasterBand(band) > > > > count = 0 > > print count > > > > for i in range(inband.XSize): > > > > ## print the current interval of 1k lines > > new_count = int(i / 1000) > > if new_count > count: > > print new_count > > count = new_count > > > > inline = inband.ReadAsArray(i, 0, 1, inband.YSize) > > > > outband.WriteArray(inline, inband.XSize - i - 1, 0) > > > > inline = None > > > > inband = None > > outband = None > > > > > --- > >--- Driver: GTiff/GeoTIFF > > Files: test.tif > > Size is 2, 19459 > > Coordinate System is: > > GEOGCS["WGS 84", > > DATUM["WGS_1984", > > SPHEROID["WGS 84",6378137,298.257223563, > > AUTHORITY["EPSG","7030"]], > > AUTHORITY["EPSG","6326"]], > > PRIMEM["Greenwich",0], > > UNIT["degree",0.0174532925199433], > > AUTHORITY["EPSG","4326"]] > > Origin = (-175.536864949200321,33.666235092496755) > > Pixel Size = (-0.62579160220,-0.54370391310) > > Metadata: > > AREA_OR_POINT=Area > > Image Structure Metadata: > > INTERLEAVE=BAND > > Corner Coordinates: > > Upper Left (-175.5368649, 33.6662351) (175d32'12.71"W, 33d39'58.45"N) > > Lower Left (-175.5368649, 32.6082416) (175d32'12.71"W, 32d36'29.67"N) > > Upper Right (-176.7884482, 33.6662351) (176d47'18.41"W, 33d39'58.45"N) > > Lower Right (-176.7884482, 32.6082416) (176d47'18.41"W, 32d36'29.67"N) > > Center (-176.1626566, 33.1372384) (176d 9'45.56"W, 33d 8'14.06"N) > > Band 1 Block=2x1 Type=Byte, ColorInterp=Red > > Mask Flags: PER_DATASET ALPHA > > Band 2 Block=2x1 Type=Byte, ColorInterp=Green > > Mask Flags: PER_DATASET ALPHA > > Band 3 Block=2x1 Type=Byte, ColorInterp=Blue > > Mask Flags: PER_DATASET ALPHA > > Band 4 Block=2x1 Type=Byte, ColorInterp=Alpha > > > ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] flipping raster in python
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), reading a column will cause the whole file to be read at each time ! Try instead the following version which read line by line and horizontally flip the buffer : it should complete in a few minutes. for band in range(1, indataset.RasterCount + 1): ## Print the current band print 'Band %s' % band inband = indataset.GetRasterBand(band) outband = outdataset.GetRasterBand(band) count = 0 print count for i in range(inband.YSize): ## print the current interval of 1k lines new_count = int(i / 1000) if new_count > count: print new_count count = new_count inline = inband.ReadAsArray(0, i, inband.XSize, 1) flipline = numpy.fliplr(inline) outband.WriteArray(flipline, 0, i) inline = None inband = None outband = None Best regards, Even Le Friday 26 March 2010 21:22:54 Jamie Adams, vous avez écrit : > 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 overnight, and it had processed less than 1000 columnsin band 3, > whereas the previous pace for bands 1&2 was around 1000 columns every 10 > seconds. Here is the relevant code with a few debugging statements > followed by the gdalinfo output. The only thing I'm noticing is that the > input image is INTERLEAVED=BAND whereas the output is INTERLEAVED=PIXEL. > Any help is appreciated. > > --- >--- for band in range(1, indataset.RasterCount + 1): > ## Print the current band > print 'Band %s' % band > > inband = indataset.GetRasterBand(band) > outband = outdataset.GetRasterBand(band) > > count = 0 > print count > > for i in range(inband.XSize): > > ## print the current interval of 1k lines > new_count = int(i / 1000) > if new_count > count: > print new_count > count = new_count > > inline = inband.ReadAsArray(i, 0, 1, inband.YSize) > > outband.WriteArray(inline, inband.XSize - i - 1, 0) > > inline = None > > inband = None > outband = None > > --- >--- Driver: GTiff/GeoTIFF > Files: test.tif > Size is 2, 19459 > Coordinate System is: > GEOGCS["WGS 84", > DATUM["WGS_1984", > SPHEROID["WGS 84",6378137,298.257223563, > AUTHORITY["EPSG","7030"]], > AUTHORITY["EPSG","6326"]], > PRIMEM["Greenwich",0], > UNIT["degree",0.0174532925199433], > AUTHORITY["EPSG","4326"]] > Origin = (-175.536864949200321,33.666235092496755) > Pixel Size = (-0.62579160220,-0.54370391310) > Metadata: > AREA_OR_POINT=Area > Image Structure Metadata: > INTERLEAVE=BAND > Corner Coordinates: > Upper Left (-175.5368649, 33.6662351) (175d32'12.71"W, 33d39'58.45"N) > Lower Left (-175.5368649, 32.6082416) (175d32'12.71"W, 32d36'29.67"N) > Upper Right (-176.7884482, 33.6662351) (176d47'18.41"W, 33d39'58.45"N) > Lower Right (-176.7884482, 32.6082416) (176d47'18.41"W, 32d36'29.67"N) > Center (-176.1626566, 33.1372384) (176d 9'45.56"W, 33d 8'14.06"N) > Band 1 Block=2x1 Type=Byte, ColorInterp=Red > Mask Flags: PER_DATASET ALPHA > Band 2 Block=2x1 Type=Byte, ColorInterp=Green > Mask Flags: PER_DATASET ALPHA > Band 3 Block=2x1 Type=Byte, ColorInterp=Blue > Mask Flags: PER_DATASET ALPHA > Band 4 Block=2x1 Type=Byte, ColorInterp=Alpha ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Error trying to merge 3 files for a multi-band ( Windows 7 PRO,
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 the one from FWTools. Best regards, Even Le Friday 26 March 2010 21:45:26 Eduardo Kanegae, vous avez écrit : > 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 error: > > * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * > * * * * * * * * * * * * * * > Traceback (most recent call last): > File "C:\PROGRA~2\FWTOOL~1.7\bin\gdal_merge.py", line 463, in ? > sys.exit(main()) > File "C:\PROGRA~2\FWTOOL~1.7\bin\gdal_merge.py", line 433, in main > if quiet == 0 and verbose == 0: > UnboundLocalError: local variable 'quiet' referenced before assignment > * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * > * * * * * * * * * * * * * * > > Any idea? ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Error trying to merge 3 files for a multi-band ( Windows 7 PRO,
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 error: * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * Traceback (most recent call last): File "C:\PROGRA~2\FWTOOL~1.7\bin\gdal_merge.py", line 463, in ? sys.exit(main()) File "C:\PROGRA~2\FWTOOL~1.7\bin\gdal_merge.py", line 433, in main if quiet == 0 and verbose == 0: UnboundLocalError: local variable 'quiet' referenced before assignment * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * Any idea? -- Eduardo Patto Kanegae http://blogdopatto.webmapit.com.br ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] flipping raster in python
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 overnight, and it had processed less than 1000 columnsin band 3, whereas the previous pace for bands 1&2 was around 1000 columns every 10 seconds. Here is the relevant code with a few debugging statements followed by the gdalinfo output. The only thing I'm noticing is that the input image is INTERLEAVED=BAND whereas the output is INTERLEAVED=PIXEL. Any help is appreciated. -- for band in range(1, indataset.RasterCount + 1): ## Print the current band print 'Band %s' % band inband = indataset.GetRasterBand(band) outband = outdataset.GetRasterBand(band) count = 0 print count for i in range(inband.XSize): ## print the current interval of 1k lines new_count = int(i / 1000) if new_count > count: print new_count count = new_count inline = inband.ReadAsArray(i, 0, 1, inband.YSize) outband.WriteArray(inline, inband.XSize - i - 1, 0) inline = None inband = None outband = None -- Driver: GTiff/GeoTIFF Files: test.tif Size is 2, 19459 Coordinate System is: GEOGCS["WGS 84", DATUM["WGS_1984", SPHEROID["WGS 84",6378137,298.257223563, AUTHORITY["EPSG","7030"]], AUTHORITY["EPSG","6326"]], PRIMEM["Greenwich",0], UNIT["degree",0.0174532925199433], AUTHORITY["EPSG","4326"]] Origin = (-175.536864949200321,33.666235092496755) Pixel Size = (-0.62579160220,-0.54370391310) Metadata: AREA_OR_POINT=Area Image Structure Metadata: INTERLEAVE=BAND Corner Coordinates: Upper Left (-175.5368649, 33.6662351) (175d32'12.71"W, 33d39'58.45"N) Lower Left (-175.5368649, 32.6082416) (175d32'12.71"W, 32d36'29.67"N) Upper Right (-176.7884482, 33.6662351) (176d47'18.41"W, 33d39'58.45"N) Lower Right (-176.7884482, 32.6082416) (176d47'18.41"W, 32d36'29.67"N) Center (-176.1626566, 33.1372384) (176d 9'45.56"W, 33d 8'14.06"N) Band 1 Block=2x1 Type=Byte, ColorInterp=Red Mask Flags: PER_DATASET ALPHA Band 2 Block=2x1 Type=Byte, ColorInterp=Green Mask Flags: PER_DATASET ALPHA Band 3 Block=2x1 Type=Byte, ColorInterp=Blue Mask Flags: PER_DATASET ALPHA Band 4 Block=2x1 Type=Byte, ColorInterp=Alpha ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Checking on Goolge Summer of Code GDAL Project
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 the information. Landon On Fri, Mar 26, 2010 at 3:31 AM, Jorge Arevalo wrote: > On Thu, Mar 25, 2010 at 5:58 PM, Frank Warmerdam 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 yet? Are there any GDAL >>> programmers willing to mentor a student for this summer's program? >>> >>> I told Wolf I would check in with you guys. >> >> Landon, >> >> I have heard expressions of interest from two students about doing >> GDAL projects. Howard Butler and I have expressed willingness to mentor >> this year. I have freshened the information for GDAL below a week ago >> or so. >> >> http://trac.osgeo.org/gdal/wiki/SummerOfCode >> >> Best regards, >> -- > > Hello, > > I'd like to participate this year, to continue my project. I think I'm > one of the students Frank has mentioned. > > Best regards, > Jorge > > >> ---+-- >> I set the clouds in motion - turn up | Frank Warmerdam, >> warmer...@pobox.com >> light and sound - activate the windows | http://pobox.com/~warmerdam >> and watch the world go round - Rush | Geospatial Programmer for Rent >> >> ___ >> gdal-dev mailing list >> gdal-dev@lists.osgeo.org >> http://lists.osgeo.org/mailman/listinfo/gdal-dev >> > ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Re: VRT creation with Python
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 = """
PROJCS["NAD27 / UTM zone
11N",GEOGCS["NAD27",DATUM["North_American_Datum_1927",SPHEROID["Clarke
1866",6378206.4,294.9786982139006,AUTHORITY["EPSG","7008"]],AUTHORITY["EPSG","6267"]],PRIMEM["Greenwich",0],UNIT["degree",0.0174532925199433],AUTHORITY["EPSG","4267"]],PROJECTION["Transverse_Mercator"],PARAMETER["latitude_of_origin",0],PARAMETER["central_meridian",-117],PARAMETER["scale_factor",0.9996],PARAMETER["false_easting",50],PARAMETER["false_northing",0],UNIT["metre",1,AUTHORITY["EPSG","9001"]],AUTHORITY["EPSG","26711"]]
4.4072e+05, 6.e+01,
0.e+00, 3.75132000e+06,
0.e+00, -6.e+01
Area
Gray
byte.tif
1
"""
ds = gdal.Open(vrt_desc)
" 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, basically I was thinking
> of something like:
> * ds = gdal.Open('some.vrt')
> * (maybe a ds2 = ds.Copy() or so here?)
> * ds2.SetMetaDataItem('SourceFilename', 'newFileName')
> * ds2.Reload() (or ds2.Open() if it's thinkable to have a ds handle while
> it's 'closed'?)
>
> Frank Warmerdam wrote:
> > I don't understand your point about metadata. Were you hoping the
> > metadata for the underlying file would be passed through the VRT to
> > the application? This does not occur with VRTs even when they reference
> > a GDAL supported (rather than raw) file.
>
> I understood this sentence from the http://www.gdal.org/gdal_vrttut.html
>
> VRT description :
> > . A special attribute of VRT datasets is that sources can be added to the
> > VRTRasterBand (but not to VRTRawRasterBand) by passing the XML describing
> > the source into SetMetadata() on the special domain target
> > "new_vrt_sources".
>
> like that there is at least some kind of machinery there to provide sources
> to an existing VRT dataset. I read that this is not possible for
> RawRasterBands, but was hoping that there are other possibles in GDAL,
> where this would be possible. Anyhow, I did it myself know, creating a new
> VRT for all images just before I read it.
>
> Frank Warmerdam wrote:
> > Is the .img file a PDS file? Are you aware there is a PDS driver for
> > GDAL? Are you sure you can't just access the PDS image directly?
>
> I am aware and tried it, but got the 'unsupported format' message. I am
> using PyPDS now to read the header and adapt the settings for the vrt
> creation with a self-made mini xml writer.
> Our PDS images are, I think, some of the most complex PDS data that there
> is, with several binary subframes inside, so I guess, the gdal driver still
> has to be improved for that.
> I asked our team leader, if I could provide you with an example image (it's
> as of yet non-public data), and he agreed. So if you like, I could send you
> an FC image by email, so that you could have a look at it, and hopefully
> implement it into the PDS driver.
>
> Have a good weekend!
> Michael
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Re: VRT creation with Python
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, basically I was thinking
of something like:
* ds = gdal.Open('some.vrt')
* (maybe a ds2 = ds.Copy() or so here?)
* ds2.SetMetaDataItem('SourceFilename', 'newFileName')
* ds2.Reload() (or ds2.Open() if it's thinkable to have a ds handle while
it's 'closed'?)
Frank Warmerdam wrote:
>
> I don't understand your point about metadata. Were you hoping the
> metadata for the underlying file would be passed through the VRT to
> the application? This does not occur with VRTs even when they reference
> a GDAL supported (rather than raw) file.
>
I understood this sentence from the http://www.gdal.org/gdal_vrttut.html
VRT description :
> . A special attribute of VRT datasets is that sources can be added to the
> VRTRasterBand (but not to VRTRawRasterBand) by passing the XML describing
> the source into SetMetadata() on the special domain target
> "new_vrt_sources".
>
like that there is at least some kind of machinery there to provide sources
to an existing VRT dataset. I read that this is not possible for
RawRasterBands, but was hoping that there are other possibles in GDAL, where
this would be possible. Anyhow, I did it myself know, creating a new VRT for
all images just before I read it.
Frank Warmerdam wrote:
>
> Is the .img file a PDS file? Are you aware there is a PDS driver for
> GDAL? Are you sure you can't just access the PDS image directly?
>
I am aware and tried it, but got the 'unsupported format' message. I am
using PyPDS now to read the header and adapt the settings for the vrt
creation with a self-made mini xml writer.
Our PDS images are, I think, some of the most complex PDS data that there
is, with several binary subframes inside, so I guess, the gdal driver still
has to be improved for that.
I asked our team leader, if I could provide you with an example image (it's
as of yet non-public data), and he agreed. So if you like, I could send you
an FC image by email, so that you could have a look at it, and hopefully
implement it into the PDS driver.
Have a good weekend!
Michael
--
View this message in context:
http://n2.nabble.com/VRT-creation-with-Python-tp4787592p4805793.html
Sent from the GDAL - Dev mailing list archive at Nabble.com.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
RE: [gdal-dev] Re: rgdal source code
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 the advantage of avoiding DLL name collisions, allowing rgdal to coexist with other libraries that also load GDAL using its traditional name (e.g. gdal16.dll). Is that why rgdal renamed the shared library? Or was it done for another reason? Jason, No, it is the name it gets when built under MSYS by default, nothing cleverer than that, I'm afraid! This is a different question entirely, but a heads-up might be worthwhile. When R 2.11 arrives in three weeks time, there will be a 64-bit Windows version. Because of the external dependencies on expat, proj4, and GDAL, rgdal is one of only a very small group of CRAN packages that is not available as a 64-bit Windows binary. It would be very useful if 64-bit Windows users got together and figured out how to make a bundle of 64-bit DLLs that could automate the CRAN Windows build of rgdal also for 64-bit Windows. R is built with MinGW, so in the MSYS family. I have no access to such a Windows platform, but have some advice from Brian Ripley, and one interested helper. The more the merrier! Roger Thanks, Jason -Original Message- From: gdal-dev-boun...@lists.osgeo.org [mailto:gdal-dev-boun...@lists.osgeo.org] On Behalf Of Roger Bivand Sent: Friday, March 26, 2010 11:09 AM To: Ivan Lucena Cc: gdal-dev@lists.osgeo.org Subject: Re: [gdal-dev] Re: rgdal source code 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 FWTools Windows binary, using VC++. Notes: Building rgdal.dll in rgdal/src: cl /MT /Ox /EHsc /D "WIN32" /c /I E:\rsb\R\R-2.2.1pat\include /I C:\Programfiler\FWTools1.0.0a7\incl ude *.cpp link /dll /out:rgdal.dll /def:RGDAL.def gdal-bindings.obj ogr_geom.obj ogr_proj.obj ogrsource.obj E: \rsb\R\R-2.2.1pat\lib\Rdll.lib /libpath:"C:\Programfiler\FWTools1.0.0a7\lib" gdal_i.lib --- So I am trying to change it a little bit in order to build against GDAL 1.7.1 (or trunk). How does that sounds to you? Good idea? Ivan, No, the README.windows file is of course in the source tarball, in the inst directory (as usual for R packages). If you install the Windows binary, you'll see that it includes GDAL 1.7.1, that is the message reporting the GDAL runtime version shown when the package is loaded. The only reason for doing anything at all is if you need drivers not already provided for your own purposes. Then you might need to review the README.windows file and, for example, build against current FWTools or OSGEO4W distributions. Please do check the drivers first with ogrDrivers() and gdalDrivers() in R after loading the package. Roger Regards, Ivan ---Original Message--- From: Roger Bivand To: gdal-dev@lists.osgeo.org Subject: [gdal-dev] Re: rgdal source code Sent: Mar 26 '10 09:31 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. We?re working to resolve this with alacrity and assure maximum stability and performance." So access should be back by the end of March. Roger Roger Bivand wrote: 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 -d:pserver:anonym...@rgdal.cvs.sourceforge.net:/cvsroot/rgdal login Logging in to :pserver:anonym...@rgdal.cvs.sourceforge.net:2401/cvsroot/rgdal CVS password: cvs [login aborted]: connect to rgdal.cvs.sourceforge.net(216.34.181.108):2401 failed: Connection refused That was a dead end. Correct. When I tried, anonymous checkout from sourceforge was also blocked - nothing we've done, maybe something sourceforge has done. I have changed the main description to: "WARNING: rgdal is only available for download from CRAN - this repository is only used for development and browsing of source code. NEVER use the very out of date file bundles for download from this site!!! See http://rgdal.sourceforge.net for link." Short of migrating to R-forge (which I have done for another R package, spdep), there isn't much that can be done with sourceforge, I'm afraid (sourceforge isn't my favorite place to be). cc: Tim: Any idea why the anonymous checkout fail
[gdal-dev] VC10 64-bits compiling
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\frmts>cd wms && nmake /nologo /f makefile.vc && cd .. || exit 1 xcopy /D /Y *.obj ..\o 0 File(s) copied cd .. if exist gdal.lib del gdal.lib lib /nologo /out:gdal.lib port\*.obj gcore\*.obj alg\*.obj frmts\o\*.obj ogr\ogrsf_frmts\ogrsf_frmts.lib ogr\ogr.lib ogrsf_frmts.lib(parsexsd.obj) : warning LNK4221: This object file does not define any previously undefined public symbols, so it will not be used by any link operation that consumes this library Joaquim Luis ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
RE: [gdal-dev] Re: rgdal source code
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 collisions, allowing rgdal to coexist with other libraries that also load GDAL using its traditional name (e.g. gdal16.dll). Is that why rgdal renamed the shared library? Or was it done for another reason? Thanks, Jason -Original Message- From: gdal-dev-boun...@lists.osgeo.org [mailto:gdal-dev-boun...@lists.osgeo.org] On Behalf Of Roger Bivand Sent: Friday, March 26, 2010 11:09 AM To: Ivan Lucena Cc: gdal-dev@lists.osgeo.org Subject: Re: [gdal-dev] Re: rgdal source code 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 FWTools Windows binary, using VC++. > > Notes: > > Building rgdal.dll in rgdal/src: > > cl /MT /Ox /EHsc /D "WIN32" /c /I E:\rsb\R\R-2.2.1pat\include /I C:\Programfiler\FWTools1.0.0a7\incl > ude *.cpp > > link /dll /out:rgdal.dll /def:RGDAL.def gdal-bindings.obj ogr_geom.obj ogr_proj.obj ogrsource.obj E: > \rsb\R\R-2.2.1pat\lib\Rdll.lib /libpath:"C:\Programfiler\FWTools1.0.0a7\lib" gdal_i.lib > --- > > So I am trying to change it a little bit in order to build against GDAL 1.7.1 (or trunk). > > How does that sounds to you? Good idea? Ivan, No, the README.windows file is of course in the source tarball, in the inst directory (as usual for R packages). If you install the Windows binary, you'll see that it includes GDAL 1.7.1, that is the message reporting the GDAL runtime version shown when the package is loaded. The only reason for doing anything at all is if you need drivers not already provided for your own purposes. Then you might need to review the README.windows file and, for example, build against current FWTools or OSGEO4W distributions. Please do check the drivers first with ogrDrivers() and gdalDrivers() in R after loading the package. Roger > > Regards, > > Ivan > > >> ---Original Message--- >> From: Roger Bivand >> To: gdal-dev@lists.osgeo.org >> Subject: [gdal-dev] Re: rgdal source code >> Sent: Mar 26 '10 09:31 >> >> >> 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. We?re >> working to resolve this with alacrity and assure maximum stability and >> performance." >> >> So access should be back by the end of March. >> >> Roger >> >> >> Roger Bivand wrote: >> > >> > 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 -d:pserver:anonym...@rgdal.cvs.sourceforge.net:/cvsroot/rgdal login >> >> Logging in to >> >> :pserver:anonym...@rgdal.cvs.sourceforge.net:2401/cvsroot/rgdal >> >> CVS password: >> >> cvs [login aborted]: connect to >> >> rgdal.cvs.sourceforge.net(216.34.181.108):2401 failed: Connection refused >> >> >> >> That was a dead end. >> > >> > Correct. When I tried, anonymous checkout from sourceforge was also >> > blocked - nothing we've done, maybe something sourceforge has done. I have >> > changed the main description to: >> > >> > "WARNING: rgdal is only available for download from CRAN - this repository >> > is only used for development and browsing of source code. NEVER use the >> > very out of date file bundles for download from this site!!! See >> > http://rgdal.sourceforge.net for link." >> > >> > Short of migrating to R-forge (which I have done for another R package, >> > spdep), there isn't much that can be done with sourceforge, I'm afraid >> > (sourceforge isn't my favorite place to be). >> > >> > cc: Tim: Any idea why the anonymous checkout fails? Longer term - is >> > migration to SVN on R-Forge worth considering? >> > >> > Roger >> > >> >> >> >> I download some of those zip packages from rgdal.sourceforge.net but they >> >> only have binary that requires FWTools installation. >> >> >> >> Another dead end. >> >> >> >> But you are right I should have search a little more to find the CRAN >> >> page. >> >> So I am downloading rgdal_0.6-2.5.zip now. Let's see how it goes. >> >> >> > >> > That is the current Windows CRAN binary, get rgdal_0.6-25.tar.gz for the >> > source. Install the Windows binary within R - do *not* treat the zip >> > archive as
[gdal-dev] Cost-efficient way to check if geometry is valid
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 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Re: rgdal source code
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 FWTools Windows binary,
using VC++.
Notes:
Building rgdal.dll in rgdal/src:
cl /MT /Ox /EHsc /D "WIN32" /c /I E:\rsb\R\R-2.2.1pat\include /I
C:\Programfiler\FWTools1.0.0a7\incl
ude *.cpp
link /dll /out:rgdal.dll /def:RGDAL.def gdal-bindings.obj ogr_geom.obj
ogr_proj.obj ogrsource.obj E:
\rsb\R\R-2.2.1pat\lib\Rdll.lib /libpath:"C:\Programfiler\FWTools1.0.0a7\lib"
gdal_i.lib
---
So I am trying to change it a little bit in order to build against GDAL 1.7.1
(or trunk).
How does that sounds to you? Good idea?
Ivan,
No, the README.windows file is of course in the source tarball, in the
inst directory (as usual for R packages).
If you install the Windows binary, you'll see that it includes GDAL 1.7.1,
that is the message reporting the GDAL runtime version shown when the
package is loaded. The only reason for doing anything at all is if you
need drivers not already provided for your own purposes. Then you might
need to review the README.windows file and, for example, build against
current FWTools or OSGEO4W distributions. Please do check the drivers
first with ogrDrivers() and gdalDrivers() in R after loading the package.
Roger
Regards,
Ivan
---Original Message---
From: Roger Bivand
To: gdal-dev@lists.osgeo.org
Subject: [gdal-dev] Re: rgdal source code
Sent: Mar 26 '10 09:31
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. We?re
working to resolve this with alacrity and assure maximum stability and
performance."
So access should be back by the end of March.
Roger
Roger Bivand wrote:
>
> 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 -d:pserver:anonym...@rgdal.cvs.sourceforge.net:/cvsroot/rgdal login
>> Logging in to
>> :pserver:anonym...@rgdal.cvs.sourceforge.net:2401/cvsroot/rgdal
>> CVS password:
>> cvs [login aborted]: connect to
>> rgdal.cvs.sourceforge.net(216.34.181.108):2401 failed: Connection refused
>>
>> That was a dead end.
>
> Correct. When I tried, anonymous checkout from sourceforge was also
> blocked - nothing we've done, maybe something sourceforge has done. I have
> changed the main description to:
>
> "WARNING: rgdal is only available for download from CRAN - this repository
> is only used for development and browsing of source code. NEVER use the
> very out of date file bundles for download from this site!!! See
> http://rgdal.sourceforge.net for link."
>
> Short of migrating to R-forge (which I have done for another R package,
> spdep), there isn't much that can be done with sourceforge, I'm afraid
> (sourceforge isn't my favorite place to be).
>
> cc: Tim: Any idea why the anonymous checkout fails? Longer term - is
> migration to SVN on R-Forge worth considering?
>
> Roger
>
>>
>> I download some of those zip packages from rgdal.sourceforge.net but they
>> only have binary that requires FWTools installation.
>>
>> Another dead end.
>>
>> But you are right I should have search a little more to find the CRAN
>> page.
>> So I am downloading rgdal_0.6-2.5.zip now. Let's see how it goes.
>>
>
> That is the current Windows CRAN binary, get rgdal_0.6-25.tar.gz for the
> source. Install the Windows binary within R - do *not* treat the zip
> archive as an archive - it is just a frozen binary version of the source
> for Windows.
>
> Roger
>
>> Thanks you so very much Roger. Have a nice day.
>>
>> Ivan
>>
>> Roger Bivand wrote:
>>> Please, do your homework!
>>>
>>> Google on "R rgdal" gives:
>>>
>>> http://cran.r-project.org/web/packages/rgdal/index.html
>>>
>>> http://rgdal.sourceforge.net/
>>>
>>> where the latter says: "The R contributed package rgdal is available
>>> from
>>> CRAN", that is the first link. On CRAN you will find both the source
>>> tarball
>>> and a Windows 32-bit binary including 1.7.1 with standard drivers and
>>> expat
>>> for reading KML etc.
>>> The sourceforge site is used exclusively as a CVS repository for
>>> developers
>>> - it hasn't been used for software distribution since about 2004; the
>>> CRAN
>>> distribution mechanism is far more robust and "just works".
>>>
>>> Refer to show.file(system.file("README.windows", package="rgdal")) if
>>> you
>>> need to build from source for more exotic drivers.
>>>
>>> The relevant mailing l
Re: [gdal-dev] Re: rgdal source code
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:
Building rgdal.dll in rgdal/src:
cl /MT /Ox /EHsc /D "WIN32" /c /I E:\rsb\R\R-2.2.1pat\include /I
C:\Programfiler\FWTools1.0.0a7\incl
ude *.cpp
link /dll /out:rgdal.dll /def:RGDAL.def gdal-bindings.obj ogr_geom.obj
ogr_proj.obj ogrsource.obj E:
\rsb\R\R-2.2.1pat\lib\Rdll.lib /libpath:"C:\Programfiler\FWTools1.0.0a7\lib"
gdal_i.lib
---
So I am trying to change it a little bit in order to build against GDAL 1.7.1
(or trunk).
How does that sounds to you? Good idea?
Regards,
Ivan
> ---Original Message---
> From: Roger Bivand
> To: gdal-dev@lists.osgeo.org
> Subject: [gdal-dev] Re: rgdal source code
> Sent: Mar 26 '10 09:31
>
>
> 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. Were
> working to resolve this with alacrity and assure maximum stability and
> performance."
>
> So access should be back by the end of March.
>
> Roger
>
>
> Roger Bivand wrote:
> >
> > 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 -d:pserver:anonym...@rgdal.cvs.sourceforge.net:/cvsroot/rgdal login
> >> Logging in to
> >> :pserver:anonym...@rgdal.cvs.sourceforge.net:2401/cvsroot/rgdal
> >> CVS password:
> >> cvs [login aborted]: connect to
> >> rgdal.cvs.sourceforge.net(216.34.181.108):2401 failed: Connection refused
> >>
> >> That was a dead end.
> >
> > Correct. When I tried, anonymous checkout from sourceforge was also
> > blocked - nothing we've done, maybe something sourceforge has done. I have
> > changed the main description to:
> >
> > "WARNING: rgdal is only available for download from CRAN - this repository
> > is only used for development and browsing of source code. NEVER use the
> > very out of date file bundles for download from this site!!! See
> > http://rgdal.sourceforge.net for link."
> >
> > Short of migrating to R-forge (which I have done for another R package,
> > spdep), there isn't much that can be done with sourceforge, I'm afraid
> > (sourceforge isn't my favorite place to be).
> >
> > cc: Tim: Any idea why the anonymous checkout fails? Longer term - is
> > migration to SVN on R-Forge worth considering?
> >
> > Roger
> >
> >>
> >> I download some of those zip packages from rgdal.sourceforge.net but they
> >> only have binary that requires FWTools installation.
> >>
> >> Another dead end.
> >>
> >> But you are right I should have search a little more to find the CRAN
> >> page.
> >> So I am downloading rgdal_0.6-2.5.zip now. Let's see how it goes.
> >>
> >
> > That is the current Windows CRAN binary, get rgdal_0.6-25.tar.gz for the
> > source. Install the Windows binary within R - do *not* treat the zip
> > archive as an archive - it is just a frozen binary version of the source
> > for Windows.
> >
> > Roger
> >
> >> Thanks you so very much Roger. Have a nice day.
> >>
> >> Ivan
> >>
> >> Roger Bivand wrote:
> >>> Please, do your homework!
> >>>
> >>> Google on "R rgdal" gives:
> >>>
> >>> http://cran.r-project.org/web/packages/rgdal/index.html
> >>>
> >>> http://rgdal.sourceforge.net/
> >>>
> >>> where the latter says: "The R contributed package rgdal is available
> >>> from
> >>> CRAN", that is the first link. On CRAN you will find both the source
> >>> tarball
> >>> and a Windows 32-bit binary including 1.7.1 with standard drivers and
> >>> expat
> >>> for reading KML etc.
> >>> The sourceforge site is used exclusively as a CVS repository for
> >>> developers
> >>> - it hasn't been used for software distribution since about 2004; the
> >>> CRAN
> >>> distribution mechanism is far more robust and "just works".
> >>>
> >>> Refer to show.file(system.file("README.windows", package="rgdal")) if
> >>> you
> >>> need to build from source for more exotic drivers.
> >>>
> >>> The relevant mailing list is R-sig-geo,
> >>> https://www.stat.math.ethz.ch/mailman/listinfo/R-SIG-Geo/, and the best
> >>> point of entrance, the R Spatial task view:
> >>> http://cran.r-project.org/web/views/Spatial.html.
> >>>
> >>> Hope this helps,
> >>>
> >>> Roger
> >>>
> >>>
> >>>
> >>> Ivan-5 wrote:
> Hi there,
>
> I am trying to get RGDAL to work wi
[gdal-dev] Re: rgdal source code
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. We’re
working to resolve this with alacrity and assure maximum stability and
performance."
So access should be back by the end of March.
Roger
Roger Bivand wrote:
>
> 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 -d:pserver:anonym...@rgdal.cvs.sourceforge.net:/cvsroot/rgdal login
>> Logging in to
>> :pserver:anonym...@rgdal.cvs.sourceforge.net:2401/cvsroot/rgdal
>> CVS password:
>> cvs [login aborted]: connect to
>> rgdal.cvs.sourceforge.net(216.34.181.108):2401 failed: Connection refused
>>
>> That was a dead end.
>
> Correct. When I tried, anonymous checkout from sourceforge was also
> blocked - nothing we've done, maybe something sourceforge has done. I have
> changed the main description to:
>
> "WARNING: rgdal is only available for download from CRAN - this repository
> is only used for development and browsing of source code. NEVER use the
> very out of date file bundles for download from this site!!! See
> http://rgdal.sourceforge.net for link."
>
> Short of migrating to R-forge (which I have done for another R package,
> spdep), there isn't much that can be done with sourceforge, I'm afraid
> (sourceforge isn't my favorite place to be).
>
> cc: Tim: Any idea why the anonymous checkout fails? Longer term - is
> migration to SVN on R-Forge worth considering?
>
> Roger
>
>>
>> I download some of those zip packages from rgdal.sourceforge.net but they
>> only have binary that requires FWTools installation.
>>
>> Another dead end.
>>
>> But you are right I should have search a little more to find the CRAN
>> page.
>> So I am downloading rgdal_0.6-2.5.zip now. Let's see how it goes.
>>
>
> That is the current Windows CRAN binary, get rgdal_0.6-25.tar.gz for the
> source. Install the Windows binary within R - do *not* treat the zip
> archive as an archive - it is just a frozen binary version of the source
> for Windows.
>
> Roger
>
>> Thanks you so very much Roger. Have a nice day.
>>
>> Ivan
>>
>> Roger Bivand wrote:
>>> Please, do your homework!
>>>
>>> Google on "R rgdal" gives:
>>>
>>> http://cran.r-project.org/web/packages/rgdal/index.html
>>>
>>> http://rgdal.sourceforge.net/
>>>
>>> where the latter says: "The R contributed package rgdal is available
>>> from
>>> CRAN", that is the first link. On CRAN you will find both the source
>>> tarball
>>> and a Windows 32-bit binary including 1.7.1 with standard drivers and
>>> expat
>>> for reading KML etc.
>>> The sourceforge site is used exclusively as a CVS repository for
>>> developers
>>> - it hasn't been used for software distribution since about 2004; the
>>> CRAN
>>> distribution mechanism is far more robust and "just works".
>>>
>>> Refer to show.file(system.file("README.windows", package="rgdal")) if
>>> you
>>> need to build from source for more exotic drivers.
>>>
>>> The relevant mailing list is R-sig-geo,
>>> https://www.stat.math.ethz.ch/mailman/listinfo/R-SIG-Geo/, and the best
>>> point of entrance, the R Spatial task view:
>>> http://cran.r-project.org/web/views/Spatial.html.
>>>
>>> Hope this helps,
>>>
>>> Roger
>>>
>>>
>>>
>>> Ivan-5 wrote:
Hi there,
I am trying to get RGDAL to work with GDAL 1.7.1 but I cannot access
the
source code [1] and the binaries for Windows depend on some old version
of
gdal_fw.dll. Does anybody have any clue?
Regards,
Ivan
[1] - http://sourceforge.net/scm/?type=cvs&group_id=84716
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
>>>
>>>
>>> -
>>> Roger Bivand
>>> Economic Geography Section
>>> Department of Economics
>>> Norwegian School of Economics and Business Administration
>>> Helleveien 30
>>> N-5045 Bergen, Norway
>>>
>>
>>
>
> --
> Roger Bivand
> Economic Geography Section, Department of Economics, Norwegian School of
> Economics and Business Administration, Helleveien 30, N-5045 Bergen,
> Norway. voice: +47 55 95 93 55; fax +47 55 95 95 43
> e-mail: roger.biv...@nhh.no
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
>
-
Roger Bivand
Economic Geography Section
Department of Economics
Norwegian School of Economics and Business Administration
Helleveien 30
N-5045 Bergen, Norway
--
View this messa
Re: [gdal-dev] Area of hourglass shaped polygon
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 > > Whilst I agree with Chris that the 'winding' method for calculating polygon >> areas would need tweaking to work with a shape like this, the 'complementary >> areas' method or the triangulation method would. See Stephen Wise, GIS >> Basics, London: Taylor & Francis (2002) pp61-64 or Joseph O'Rourke, >> Computational Geometry in C, Cambridge (2nd Edn): Cambridge University Press >> (1998) pp18-22. >> >> Best wishes, >> >> Peter >> >> >> Chris 'Xenon' Hanson wrote: >> >>> On 3/18/2010 10:20 AM, Ramiro Gonzalez wrote: >>> I use gdal to calculate the area of polygons drawn by a user over a map. The points are added to the polygon in same order the user selects them. An hourglass shaped polygon can be created adding 4 points like a 'z'. When the polygon has the shape of an hourglass, the measure returned by get_Area() is smaller than the sum of the areas of the two independent triangles. I'd like to know if there is a way to calculate the area in this situation? I tried to intersect the polygon with another that contains it but the operation fails when the polygon cross itself(return NULL). I could use this to inform that the area calculated is invalid, but I'd like to know if there is a better way of knowing this. >>> >>> I'm pretty sure this would be considered nonsensical topology. Area >>> calculations usually >>> rely on the points in a polygon winding either consistently clockwise or >>> counter-clockwise, but yours are mixed. >>> >>> Don't do that. It's bad. >>> >>> If you want to measure the area of a shape like that, create it out of >>> two normal >>> consistently-wound triangles stacked tip-to-tip. >>> >>> Thanks, Ramiro >>> >>> >> -- >> >> >> Peter J Halls, GIS Advisor, University of York >> Telephone: 01904 433806 Fax: 01904 433740 >> Snail mail: Computing Service, University of York, Heslington, York YO10 >> 5DD >> This message has the status of a private and personal communication >> >> >> >> ___ >> gdal-dev mailing list >> gdal-dev@lists.osgeo.org >> http://lists.osgeo.org/mailman/listinfo/gdal-dev >> > > > ___ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev > -- Best regards, Chaitanya kumar CH. /tʃaɪθənjə/ /kʊmɑr/ +91-9848167848 17.2416N 80.1426E ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Checking on Goolge Summer of Code GDAL Project
On Thu, Mar 25, 2010 at 5:58 PM, Frank Warmerdam 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 yet? Are there any GDAL >> programmers willing to mentor a student for this summer's program? >> >> I told Wolf I would check in with you guys. > > Landon, > > I have heard expressions of interest from two students about doing > GDAL projects. Howard Butler and I have expressed willingness to mentor > this year. I have freshened the information for GDAL below a week ago > or so. > > http://trac.osgeo.org/gdal/wiki/SummerOfCode > > Best regards, > -- Hello, I'd like to participate this year, to continue my project. I think I'm one of the students Frank has mentioned. Best regards, Jorge > ---+-- > I set the clouds in motion - turn up | Frank Warmerdam, > warmer...@pobox.com > light and sound - activate the windows | http://pobox.com/~warmerdam > and watch the world go round - Rush | Geospatial Programmer for Rent > > ___ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev > ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] rgdal source code
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 -d:pserver:anonym...@rgdal.cvs.sourceforge.net:/cvsroot/rgdal login
Logging in to :pserver:anonym...@rgdal.cvs.sourceforge.net:2401/cvsroot/rgdal
CVS password:
cvs [login aborted]: connect to
rgdal.cvs.sourceforge.net(216.34.181.108):2401 failed: Connection refused
That was a dead end.
Correct. When I tried, anonymous checkout from sourceforge was also
blocked - nothing we've done, maybe something sourceforge has done. I have
changed the main description to:
"WARNING: rgdal is only available for download from CRAN - this repository
is only used for development and browsing of source code. NEVER use the
very out of date file bundles for download from this site!!! See
http://rgdal.sourceforge.net for link."
Short of migrating to R-forge (which I have done for another R package,
spdep), there isn't much that can be done with sourceforge, I'm afraid
(sourceforge isn't my favorite place to be).
cc: Tim: Any idea why the anonymous checkout fails? Longer term - is
migration to SVN on R-Forge worth considering?
Roger
I download some of those zip packages from rgdal.sourceforge.net but they
only have binary that requires FWTools installation.
Another dead end.
But you are right I should have search a little more to find the CRAN page.
So I am downloading rgdal_0.6-2.5.zip now. Let's see how it goes.
That is the current Windows CRAN binary, get rgdal_0.6-25.tar.gz for the
source. Install the Windows binary within R - do *not* treat the zip
archive as an archive - it is just a frozen binary version of the source
for Windows.
Roger
Thanks you so very much Roger. Have a nice day.
Ivan
Roger Bivand wrote:
Please, do your homework!
Google on "R rgdal" gives:
http://cran.r-project.org/web/packages/rgdal/index.html
http://rgdal.sourceforge.net/
where the latter says: "The R contributed package rgdal is available from
CRAN", that is the first link. On CRAN you will find both the source
tarball
and a Windows 32-bit binary including 1.7.1 with standard drivers and expat
for reading KML etc.
The sourceforge site is used exclusively as a CVS repository for developers
- it hasn't been used for software distribution since about 2004; the CRAN
distribution mechanism is far more robust and "just works".
Refer to show.file(system.file("README.windows", package="rgdal")) if you
need to build from source for more exotic drivers.
The relevant mailing list is R-sig-geo,
https://www.stat.math.ethz.ch/mailman/listinfo/R-SIG-Geo/, and the best
point of entrance, the R Spatial task view:
http://cran.r-project.org/web/views/Spatial.html.
Hope this helps,
Roger
Ivan-5 wrote:
Hi there,
I am trying to get RGDAL to work with GDAL 1.7.1 but I cannot access the
source code [1] and the binaries for Windows depend on some old version of
gdal_fw.dll. Does anybody have any clue?
Regards,
Ivan
[1] - http://sourceforge.net/scm/?type=cvs&group_id=84716
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
-
Roger Bivand
Economic Geography Section
Department of Economics
Norwegian School of Economics and Business Administration
Helleveien 30
N-5045 Bergen, Norway
--
Roger Bivand
Economic Geography Section, Department of Economics, Norwegian School of
Economics and Business Administration, Helleveien 30, N-5045 Bergen,
Norway. voice: +47 55 95 93 55; fax +47 55 95 95 43
e-mail: roger.biv...@nhh.no
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
