[gdal-dev] compilation problem
hello hello I encountered this problem when I compiled gdal-svn-trunk-2011.03.27 sr/local/gdal/frmts/envisat/EnvisatFile.c:1046: undefined reference to `__stack_chk_fail_local' /usr/local/gdal/frmts/o/EnvisatFile.o:/usr/local/gdal/frmts/envisat/EnvisatFile.c:419: more undefined references to `__stack_chk_fail_local' follow what can I do ? regards -- Ahmet Temiz Jeoloji Müh. Afet ve Acil Durum Yönetimi Başkanlığı Planlama ve Zarar Azaltma Dairesi Başkanlığı Bilgi ve CBS grubu Eskişehir Yolu 10. km. Lodumlu / Ankara Tel : 0 312 2872680 / 1535 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] compilation problem
Ahmet, These kind of compilation errors usually resolve themselves if you perform a make clean or start with a fresh copy. Probably caused by 'make' not seeing a modification of file or due to an interrupted compilation. Also, I noticed some problems when running make with the --jobs option. 2011/4/4 ahmet temiz ahmettemi...@gmail.com hello hello I encountered this problem when I compiled gdal-svn-trunk-2011.03.27 sr/local/gdal/frmts/envisat/EnvisatFile.c:1046: undefined reference to `__stack_chk_fail_local' /usr/local/gdal/frmts/o/EnvisatFile.o:/usr/local/gdal/frmts/envisat/EnvisatFile.c:419: more undefined references to `__stack_chk_fail_local' follow what can I do ? regards -- Ahmet Temiz Jeoloji Müh. Afet ve Acil Durum Yönetimi Başkanlığı Planlama ve Zarar Azaltma Dairesi Başkanlığı Bilgi ve CBS grubu Eskişehir Yolu 10. km. Lodumlu / Ankara Tel : 0 312 2872680 / 1535 ___ 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-9494447584 17.2416N 80.1426E ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] EPSG:3388 (Caspian Sea Mercator)) Projection Parameter incorectly set
This relates to the following bug report ( Ticket #2744 ) by crschmidt :http://trac.osgeo.org/gdal/ticket/2744I have found that the parameters are still incorrectly set with my Debian Squeeze versions of proj4, PostGIS and GDAL. Using proj I set the correct parameters (+proj=merc +lon_0=51 +lat_ts=42 +x_0=0 +y_0=0 +ellps=krass +towgs84=23.92,-141.27,-80.9,-0,0.35,0.82,-0.12 +units=m +no_defs) by hand, spatial_ref_sys table in PostGIS has been edited accordingly.Anyone using EPSG:3388 with this standard set-up may be interested.Thanks,Martin ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] problem with decimal precision (SAGA driver)
Hi, we encountered a problem with decimal precision when converting a SAGA grid to ESRI ASCII. I expect the problem arising from ASCII to double conversion by atof() and/or from the Geotransform (pixel as point to pixel as area). The SAGA header looks like POSITION_XMIN = 12181.80 POSITION_YMIN = 219184.88 CELLSIZE= 1.00 The final ESRI ASCII header looks like xllcorner12181.2999 yllcorner219184.3805 instead of xllcorner12181.3 yllcorner219184.38 How is this problem handled in other drivers (using strtod(), stringstream, ...)? The relevant lines of code in sagadataset.cpp (http://trac.osgeo.org/gdal/browser/trunk/gdal/frmts/saga/sagadataset.cpp) are: 406 http://trac.osgeo.org/gdal/browser/trunk/gdal/frmts/saga/sagadataset.cpp#L406 dXmin = atof(papszTokens[1]); 408 http://trac.osgeo.org/gdal/browser/trunk/gdal/frmts/saga/sagadataset.cpp#L408 dYmin = atof(papszTokens[1]); 410 http://trac.osgeo.org/gdal/browser/trunk/gdal/frmts/saga/sagadataset.cpp#L410 dCellsize = atof(papszTokens[1]); 601 http://trac.osgeo.org/gdal/browser/trunk/gdal/frmts/saga/sagadataset.cpp#L601 padfGeoTransform[0] = poGRB-m_Xmin - poGRB-m_Cellsize / 2; 602 http://trac.osgeo.org/gdal/browser/trunk/gdal/frmts/saga/sagadataset.cpp#L602 padfGeoTransform[3] = poGRB-m_Ymin + (nRasterYSize - 1) * poGRB-m_Cellsize + poGRB-m_Cellsize / 2; Thanks, Volker ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] kml superoverlay help request
Brian IIRC the superoverlay driver is read only. Reading images from knls are problematic at best. Can you give me some info on the stucture of the kmz's? Brian On Sun, 2011-04-03 at 22:43 -0700, Brian Wilson wrote: I received a batch of files that are in a kml format that looks like the KML SUPEROVERLAY that gdal supports. There is a kmz flle which when unzipped contains a batch of JPEGs and a file called doc.kml that describes them. My gdalinfo --formats command says KMLSUPEROVERLAY (rwv): Kml Super Overlay but I don't know how to feed it the files. I tried the KMZ, the unpacked directory, and the doc file ERROR 4: `nc4806-50.kmz' not recognised as a supported file format. ERROR 4: `nc4806-50' not recognised as a supported file format. ERROR 4: `nc4806-50/doc.kml' not recognised as a supported file format. Or maybe I am wrong about what a kml super overlay is? My google searches only turned up help with writing the kml files, but I am assuming the formats rwv means it can read, write, and also do something else starting with the letter 'v' -- always wondered about those codes like rw+ maybe the + means update or append?? (And rov means remotely operated vehicle? oops context shift sorry) Thanks in advance Brian Wilson Corvallis OR ___ 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] kml superoverlay help request
Brian, I had responded earlier but for some reason my email was rejected by list maybe because my official ID changed. In any case below is my response. What version of gdal is this? KMLSUPEROVERLAY driver creates a hierarchy of regions that can be used to efficiently serve large set of imagery. As few points near higher resolution tiles are loaded. KMLSUPEROVERLAY driver generates kmz with this command: Gdal_translate.exe -of KMLSUPEROVERLAY c:\my.tif c:\myResult.kmz -co FORMAT=PNG I have not implemented read for KMLSUPEROVERLAY. Ogrinfo should be able to read kml but not gdal. Let me know if you have more questions. v gets appended for formats supporting virtual IO. Harsh Govind -Original Message- From: gdal-dev-boun...@lists.osgeo.org [mailto:gdal-dev-boun...@lists.osgeo.org] On Behalf Of brian Sent: Monday, April 04, 2011 12:23 PM To: Brian Wilson Cc: gdal-dev@lists.osgeo.org Subject: Re: [gdal-dev] kml superoverlay help request Brian IIRC the superoverlay driver is read only. Reading images from knls are problematic at best. Can you give me some info on the stucture of the kmz's? Brian On Sun, 2011-04-03 at 22:43 -0700, Brian Wilson wrote: I received a batch of files that are in a kml format that looks like the KML SUPEROVERLAY that gdal supports. There is a kmz flle which when unzipped contains a batch of JPEGs and a file called doc.kml that describes them. My gdalinfo --formats command says KMLSUPEROVERLAY (rwv): Kml Super Overlay but I don't know how to feed it the files. I tried the KMZ, the unpacked directory, and the doc file ERROR 4: `nc4806-50.kmz' not recognised as a supported file format. ERROR 4: `nc4806-50' not recognised as a supported file format. ERROR 4: `nc4806-50/doc.kml' not recognised as a supported file format. Or maybe I am wrong about what a kml super overlay is? My google searches only turned up help with writing the kml files, but I am assuming the formats rwv means it can read, write, and also do something else starting with the letter 'v' -- always wondered about those codes like rw+ maybe the + means update or append?? (And rov means remotely operated vehicle? oops context shift sorry) Thanks in advance Brian Wilson Corvallis OR ___ 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 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
RE: [gdal-dev] kml superoverlay help request
Harsh, Depending on how its layed out, I have a way to read these. Brian On Mon, 2011-04-04 at 12:51 -0400, Harsh Govind wrote: Brian, I had responded earlier but for some reason my email was rejected by list maybe because my official ID changed. In any case below is my response. What version of gdal is this? KMLSUPEROVERLAY driver creates a hierarchy of regions that can be used to efficiently serve large set of imagery. As few points near higher resolution tiles are loaded. KMLSUPEROVERLAY driver generates kmz with this command: Gdal_translate.exe -of KMLSUPEROVERLAY c:\my.tif c:\myResult.kmz -co FORMAT=PNG I have not implemented read for KMLSUPEROVERLAY. Ogrinfo should be able to read kml but not gdal. Let me know if you have more questions. v gets appended for formats supporting virtual IO. Harsh Govind -Original Message- From: gdal-dev-boun...@lists.osgeo.org [mailto:gdal-dev-boun...@lists.osgeo.org] On Behalf Of brian Sent: Monday, April 04, 2011 12:23 PM To: Brian Wilson Cc: gdal-dev@lists.osgeo.org Subject: Re: [gdal-dev] kml superoverlay help request Brian IIRC the superoverlay driver is read only. Reading images from knls are problematic at best. Can you give me some info on the stucture of the kmz's? Brian On Sun, 2011-04-03 at 22:43 -0700, Brian Wilson wrote: I received a batch of files that are in a kml format that looks like the KML SUPEROVERLAY that gdal supports. There is a kmz flle which when unzipped contains a batch of JPEGs and a file called doc.kml that describes them. My gdalinfo --formats command says KMLSUPEROVERLAY (rwv): Kml Super Overlay but I don't know how to feed it the files. I tried the KMZ, the unpacked directory, and the doc file ERROR 4: `nc4806-50.kmz' not recognised as a supported file format. ERROR 4: `nc4806-50' not recognised as a supported file format. ERROR 4: `nc4806-50/doc.kml' not recognised as a supported file format. Or maybe I am wrong about what a kml super overlay is? My google searches only turned up help with writing the kml files, but I am assuming the formats rwv means it can read, write, and also do something else starting with the letter 'v' -- always wondered about those codes like rw+ maybe the + means update or append?? (And rov means remotely operated vehicle? oops context shift sorry) Thanks in advance Brian Wilson Corvallis OR ___ 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 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
RE: [gdal-dev] kml superoverlay help request
Yes, definitely. I meant to say that using KLSUPEROVERLAY driver you cannot read kmz. Thanks for pointing that out. Harsh Govind -Original Message- From: brian [mailto:r...@winkey.org] Sent: Monday, April 04, 2011 12:57 PM To: Harsh Govind Cc: Brian Wilson; gdal-dev@lists.osgeo.org Subject: RE: [gdal-dev] kml superoverlay help request Harsh, Depending on how its layed out, I have a way to read these. Brian On Mon, 2011-04-04 at 12:51 -0400, Harsh Govind wrote: Brian, I had responded earlier but for some reason my email was rejected by list maybe because my official ID changed. In any case below is my response. What version of gdal is this? KMLSUPEROVERLAY driver creates a hierarchy of regions that can be used to efficiently serve large set of imagery. As few points near higher resolution tiles are loaded. KMLSUPEROVERLAY driver generates kmz with this command: Gdal_translate.exe -of KMLSUPEROVERLAY c:\my.tif c:\myResult.kmz -co FORMAT=PNG I have not implemented read for KMLSUPEROVERLAY. Ogrinfo should be able to read kml but not gdal. Let me know if you have more questions. v gets appended for formats supporting virtual IO. Harsh Govind -Original Message- From: gdal-dev-boun...@lists.osgeo.org [mailto:gdal-dev-boun...@lists.osgeo.org] On Behalf Of brian Sent: Monday, April 04, 2011 12:23 PM To: Brian Wilson Cc: gdal-dev@lists.osgeo.org Subject: Re: [gdal-dev] kml superoverlay help request Brian IIRC the superoverlay driver is read only. Reading images from knls are problematic at best. Can you give me some info on the stucture of the kmz's? Brian On Sun, 2011-04-03 at 22:43 -0700, Brian Wilson wrote: I received a batch of files that are in a kml format that looks like the KML SUPEROVERLAY that gdal supports. There is a kmz flle which when unzipped contains a batch of JPEGs and a file called doc.kml that describes them. My gdalinfo --formats command says KMLSUPEROVERLAY (rwv): Kml Super Overlay but I don't know how to feed it the files. I tried the KMZ, the unpacked directory, and the doc file ERROR 4: `nc4806-50.kmz' not recognised as a supported file format. ERROR 4: `nc4806-50' not recognised as a supported file format. ERROR 4: `nc4806-50/doc.kml' not recognised as a supported file format. Or maybe I am wrong about what a kml super overlay is? My google searches only turned up help with writing the kml files, but I am assuming the formats rwv means it can read, write, and also do something else starting with the letter 'v' -- always wondered about those codes like rw+ maybe the + means update or append?? (And rov means remotely operated vehicle? oops context shift sorry) Thanks in advance Brian Wilson Corvallis OR ___ 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 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Building a resizable polygon
Hi All, I am looking for some direction on if GDAL has the capability has the ability to build a super-polygon from a series of small polygons...I have played a bit with the OGR Geometry classes but I can't seem to quite get what I need. Let's start with a simply example. Polygon A has vertices in (X,Y) format of 0, 0, 0,1, 1,0, 1,1 Polygon B has vertices in (x,y) format of 1,0 , 1,1, 2,0, 2,1 Since Polygon A and B share a common side with vertices 1,0 and 1,1 I want to build super polygon that contains the coordinates of the outer perimeter of the points. When complete the new polygon C will thus have points 0,0,0,1,2,0, 2,1 I had first looked at OGRPolygon.AddRing wherein A and B above would be OGRLinearRings and then by making a call to C.getExteriorRing() but this seem to report the first ring added. Am I heading in the correct direction or is this something that I will essentially have to do manually by first creating a OGRLinearRing from the vertices of polygon A, then creating a OGRPolygon to which I execute addRing. Then interrogating that ring to see which line segments are common between A and B and removing the ones that are common and adding the line segments that aren't common. Thanks, Bill William Cassanova | Senior GFS Developer | The Weather Channel | 770.226.2368 | bcassan...@weather.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Building a resizable polygon
Bill, Either of OGRGeometry::Union() and OGRGeometry::UnionCascaded() should help you. I would choose the latter if there are more than two polygons. It operates on an OGRMultiPolygon object. On Tue, Apr 5, 2011 at 2:35 AM, Cassanova, Bill bcassan...@weather.comwrote: Hi All, I am looking for some direction on if GDAL has the capability has the ability to build a super-polygon from a series of small polygons…I have played a bit with the OGR Geometry classes but I can’t seem to quite get what I need. Let’s start with a simply example. Polygon A has vertices in (X,Y) format of 0, 0, 0,1, 1,0, 1,1 Polygon B has vertices in (x,y) format of 1,0 , 1,1, 2,0, 2,1 Since Polygon A and B share a common side with vertices 1,0 and 1,1 I want to build super polygon that contains the coordinates of the outer perimeter of the points. When complete the new polygon C will thus have points 0,0,0,1,2,0, 2,1 I had first looked at OGRPolygon.AddRing wherein A and B above would be OGRLinearRings and then by making a call to C.getExteriorRing() but this seem to report the first ring added. Am I heading in the correct direction or is this something that I will essentially have to do manually by first creating a OGRLinearRing from the vertices of polygon A, then creating a OGRPolygon to which I execute addRing. Then interrogating that ring to see which line segments are common between A and B and removing the ones that are common and adding the line segments that aren’t common. Thanks, Bill William Cassanova | Senior GFS Developer | The Weather Channel | 770.226.2368 | bcassan...@weather.com ___ 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-9494447584 17.2416N 80.1426E ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Fwd: [gdal-dev] kml superoverlay help request
Darn -- meant this to go to the list not just to Harsh -- Forwarded message -- From: Brian Wilson br...@wildsong.biz Date: Mon, Apr 4, 2011 at 11:10 AM Subject: Re: [gdal-dev] kml superoverlay help request To: Harsh Govind govind.ha...@geoeye.com Okay, so I cannot read KMZ w/gdal. I am using version 1.8 running on Ubuntu. Mostly I wanted to confirm that. I hate duplicating other people's work just because I am too dense to understand docs. :-) I never looked at a KMLSUPEROVERLAY before yesterday so I don't know how much variation there is in one. (Though there is XML involved so there could be LOTS of variation... :-) I started to describe the files in this message and decided a URL is easier. http://hupi.org/map/vietnam/50k/ For example, nc4806-50/ http://hupi.org/map/vietnam/50k/nc4806-50/ is the unzipped version of nc4806-50.ziphttp://hupi.org/map/vietnam/50k/nc4806-50.zip (FYI this project is for the Vietnam Helicopter Pilot Association vhpa.organd the rasters are scans of Vietnam war era paper maps.) Brian Wilson Corvallis OR ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
