[gdal-dev] How to correct the envisat N1 image with it's GCPs
Hi,all.
I want to correct the envisat N1 image with it's GCPs,this image
haven't geo-referenced information and projection,but it's GCPs have
geo-referenced information.However I can not get correct results,the
corrected image pixels are all zero.Here is my code:
GDALAllRegister();
GDALDriverH hDriver;
GDALDataType eDT;
GDALDatasetH hDstDS;
GDALDatasetH hSrcDS;
hSrcDS=GDALOpen("D:\\Users\\ASA_IMP_1PNUPA20070408_135835_00162057_00082_26689_3974.N1",GA_ReadOnly);
CPLAssert(hSrcDS!=NULL);
int nGcpCount=GDALGetGCPCount(hSrcDS);
const GDAL_GCP *pGCPs=GDALGetGCPs(hSrcDS);
GDALWarpOptions *psWarpOptions = GDALCreateWarpOptions();
psWarpOptions->pTransformerArg=GDALCreateGCPTransformer(nGcpCount,pGCPs,1,0);
psWarpOptions->pfnTransformer=GDALGCPTransform;
psWarpOptions->eResampleAlg=GRA_NearestNeighbour;
psWarpOptions->hSrcDS=hSrcDS;
psWarpOptions->nBandCount=0;
psWarpOptions->pfnProgress=GDALTermProgress;
double adfDstGeoTransform[6];
int nPixels=0, nLines=0;
GDALSuggestedWarpOutput(psWarpOptions->hSrcDS, GDALGCPTransform,
psWarpOptions->pTransformerArg, adfDstGeoTransform, &nPixels,
&nLines);
hDriver=GDALGetDriverByName("GTiff");
CPLAssert(hDriver!=NULL);
eDT=GDALGetRasterDataType(GDALGetRasterBand(hSrcDS,1));
hDstDS=GDALCreate(hDriver,"D:\\Users\\warp.tif",nPixels,nLines,GDALGetRasterCount(hSrcDS),eDT,NULL);
CPLAssert(hDstDS!=NULL);
psWarpOptions->hDstDS=hDstDS;
char *pszDstWKT=NULL;
OGRSpatialReference oSRS;
oSRS.SetUTM(20,TRUE);
oSRS.SetWellKnownGeogCS("WGS84");
oSRS.exportToWkt(&pszDstWKT);
GDALSetProjection(hDstDS,pszDstWKT);
GDALSetGeoTransform(hDstDS,adfDstGeoTransform);
CPLFree(pszDstWKT);
GDALWarpOperation oOperation;
oOperation.Initialize(psWarpOptions);
oOperation.ChunkAndWarpImage(0,0,nPixels,nLines);
GDALDestroyGenImgProjTransformer(psWarpOptions->pTransformerArg);
GDALDestroyWarpOptions(psWarpOptions);
GDALClose(hDstDS);
GDALClose(hSrcDS);
That's Why?I turn to Anybody who once did this job for some advice. Thank
you!
Kind regards.
--
View this message in context:
http://osgeo-org.1803224.n2.nabble.com/How-to-correct-the-envisat-N1-image-with-it-s-GCPs-tp6524474p6524474.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
[gdal-dev] How to apply a costum shift grid?
Hi, I am working here in Chile and we have a lot of earthquakes here, the last big one like a year ago. So the problem is that I have a lot of georeferenced images, but georeferenced before the earthquake. We thought the best way would be to calculate a shift grid and apply it with gdalwarp to all of the images. The only thing I would have to do is to apply the grid from one datum to the same datum instead of from one datum to another, this should be possible, shouldn´t it? Reading a lot in the mailing-list I found a link to an australian govermental site, where they provide a program to convert from NTv2_ASCII to NTv2_GSB. So I created an Ntv2_ASCII file with our shift values and converted it with this program to an .gsb-file and tried to apply that file with gdalwarp to our images. But no matter what I tried, nothing happened, the shift never was applied. I saw a lot of examples of possible commands searching in the mailing-list and tried everyone, also in nearly every possible combination but nothing lead to an applied shift. So I am a bit desperate right now, hoping someone can help me a bit or give an advice. Here in short what I have to do: Apply a shift grid from UTM 18s WGS84 to UTM 18s WGS84 in order to apply the coordinate changes of our images owing of the earthquake last year. I would apreciate any kind of help and thank a lot in advance, Frederick -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/How-to-apply-a-costum-shift-grid-tp6524901p6524901.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] How to apply a costum shift grid?
Frederick, I'm a geophysicist but never thought that an earthquake could have that side effect of image referencing. Anyway the horizontal deformation caused by a big earthquake is of the order of meter scale. One idea I had is that you can use the shift grid to to relocate previous GCPs and than use those relocated ones in gdalwarp. You can compute 'old' GCPs by interpolating your images both for pixels and metric (UTM) units. The operations would be something like this 1. Get "px py old_UTMx old_UTMy" by interpolating the referenced image at a certain well distributed positions 2. apply the shift grid to old GCPs and get new GCPs "px py new_UTMx new_UTMy" 2. re-register with gdalwarp and new GCPs Of course, this is in absence of a more straight solution where the shift grid is applied directly to the images. Joaquim Luis Hi, I am working here in Chile and we have a lot of earthquakes here, the last big one like a year ago. So the problem is that I have a lot of georeferenced images, but georeferenced before the earthquake. We thought the best way would be to calculate a shift grid and apply it with gdalwarp to all of the images. The only thing I would have to do is to apply the grid from one datum to the same datum instead of from one datum to another, this should be possible, shouldn´t it? Reading a lot in the mailing-list I found a link to an australian govermental site, where they provide a program to convert from NTv2_ASCII to NTv2_GSB. So I created an Ntv2_ASCII file with our shift values and converted it with this program to an .gsb-file and tried to apply that file with gdalwarp to our images. But no matter what I tried, nothing happened, the shift never was applied. I saw a lot of examples of possible commands searching in the mailing-list and tried everyone, also in nearly every possible combination but nothing lead to an applied shift. So I am a bit desperate right now, hoping someone can help me a bit or give an advice. Here in short what I have to do: Apply a shift grid from UTM 18s WGS84 to UTM 18s WGS84 in order to apply the coordinate changes of our images owing of the earthquake last year. I would apreciate any kind of help and thank a lot in advance, Frederick -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/How-to-apply-a-costum-shift-grid-tp6524901p6524901.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 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] datum projection info in ecw
Nicholas I was interested about similar things a few weeks ago and got quick help in this forum. As jean-Claude already mentioned there's a header editor for Windows that allows you to see/edit the datum and projection info. Jean-Claude also created a tool "ecwhed" that allows you to get and set these parameters via the command line, at least under Linux it compiles easily, it requires the ECW SDK. If you create ECW's via GDAL you should use the options -co "PROJ=..." and -co "DATUM=..." to be sure what GDAL writes to the ECW header. For reading ECW files GDAL uses the definitions in the file "ecw_cs.wkt" (on Unix under /usr/local/share/gdal/). There you can add your own projections and datums or modify existing ones, eg. adding datum shift parameters. Programs that use GDAL for raster rendering like QGIS or ArcGis 10 can also work with these new projection definitions if you add them to their own "ecw_cs.wkt" file, Mapserver takes the file of the GDAL installation. Regards Armin On 28/06/2011 03:09, nicholas.g.lawre...@tmr.qld.gov.au wrote: Hello all, Does anyone know where the datum and projection information is stored inside an ecw? Kind regards, * Nicholas Lawrence* Senior Spatial Science Officer | Darling Downs Region / Toowoomba Office * Assets & Operations* Division | Department of Transport and Main Roads Floor 1 | Toowoomba - Phillip Street | 1-5 Phillip Street (cnr Clopton Street) | Toowoomba Qld 4350 PO Box 645 | Toowoomba Qld 4350 P: (07) 46390764 | F: (07) 46390750 E: nicholas.g.lawre...@tmr.qld.gov.au W: www.tmr.qld.gov.au * Tomorrow's Queensland: strong, green, smart, healthy and fair – www.towardQ2.qld.gov.au* P | Please consider the environment before printing this email *** WARNING: This email (including any attachments) may contain legally privileged, confidential or private information and may be protected by copyright. You may only use it if you are the person(s) it was intended to be sent to and if you use it in an authorised way. No one is allowed to use, review, alter, transmit, disclose, distribute, print or copy this email without appropriate authority. If this email was not intended for you and was sent to you by mistake, please telephone or email me immediately, destroy any hardcopies of this email and delete it and any copies of it from your computer system. Any right which the sender may have under copyright law, and any legal privilege and confidentiality attached to this email is not waived or destroyed by that mistake. It is your responsibility to ensure that this email does not contain and is not affected by computer viruses, defects or interference by third parties or replication problems (including incompatibility with your computer system). Opinions contained in this email do not necessarily reflect the opinions of the Department of Transport and Main Roads, Maritime Safety Queensland or endorsed organisations utilising the same infrastructure. *** ___ 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] GDAL/OGR 1.8.1 Advance Warning
Frank a functionality that I would find useful in combination with clients like ArcGIS or Erdas are the Erdas overviews in *.rrd files. When creating overviews with gdaladdo using the "--config USE_RRD YES" option, aux files instead of rrd files are created. They are not fully recognized by ArcGis/Erdas, depending on the image format. For me an ideal solution would therefore be being able to create overviews in standard rrd files (I guess the format is not much different from the one used for the overviews in aux files) and the possibility to create standard Erdas aux files that contain only information like the histogram, but no overviews. Looks to me like the creation of HFA formats supports that already. Clients like Erdas and ArcGis use and create the aux file for any type of image, also for Tiff or ECW files when applying image stretching. Having the possibility to create such aux files with a command line tool for various image formats could be useful in an image archive where clients do not have write access and cannot create neither rrd nor aux files. And the creation could then be automated and performed eg. on a server, and it could also be much faster than clients like ArcGis calculating the histograms. Just my ideas. Greetings Armin On 27/06/2011 14:31, Frank Warmerdam wrote: Folks, I would like to prepare a 1.8.1 release candidate in the next couple days. Developers are encouraged to address any bug fixes they would like promptly. Is there anything folks feel strongly needs to be addressed in 1.8.1 that has not yet made it into the 1.8 branch? Best regards, ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Re: How to apply a costum shift grid?
Hi Joaquim, thanks for your help. What we already did (before calculating a shift grid), was calculating the new GCP´s and I also already applied them with gdal_translate and gdalwarp to the images and it worked well. But we have to change the reference for a very huge region so it would be a lot more efficient and accurate, if in someway we could apply the grid. But if at the end it turns out, that it is not possible to use a shift grid in the way we wanted and needed to, using GCP´s would be the way Thanks again, Frederick -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/How-to-apply-a-costum-shift-grid-tp6524901p6526517.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] Problem Compiling with Oracle (--with-oci)
Just wanted to wrap this up with my final findings for anyone who stumbles onto this thread in the future. While the solution below did allow me to successfully build and connect to oracle, I also wanted to build with support for PostgreSQL/PostGIS. The PostgreSQL client also requires expat, and so my little -with-expat=no trick didn't allow the postgres support to be included in the build. The final solution was to download the oracle instant client (for linux) - both the "basic" client package and the "SDK" package were required. Before configuring, I needed to do the following in the instant client directory: ln -s libclntsh.so.11.1 libclntsh.so ln -s libocci.so.11.1 libocci.so And then I needed to specify the paths to where I unzipped the instant client packages (in /opt) to configure: --with-oci-lib=/opt/instantclient_11_2 --with-oci-include=/opt/instantclient_11_2/sdk/include And that's it (as it should be). No LDFLAGS or messing with LD_LIBRARY_PATH, no ORACLE_HOME even, just here's the libs, here's the includes, go. This works so much better because the instant client has all of it's pre-req's statically linked in (it's a ridiculously huge library as a result...) whereas the libraries that come in the /lib/ dir of the full oracle package do not (and so are only somewhat less ridiculously large). Hope that helps someone, someday. Cheers, Chris Chris Hodgson wrote: Thanks for the confirmation Mike. I'm guessing the oracle instant client was compiled with a bit more care for the use of external developers. However I have managed to get a successful compile after setting the LDFLAGS environment variable to include the oracle lib folder (to get their old expat onto the path): export LDFLAGS=-L/opt/oracle/product/11.2.0/dbhome_1/lib/ and then configured with the gdal expat turned off (if I leave it on I end up with the same original problem): ./configure --with-oci=/opt/oracle/product/11.2.0/dbhome_1/ --with-expat=no I still have to test if this actually lets me connect to oracle. If not I'll download the instant client and try configuring/compiling against that. Thanks, Chris Smith, Michael D ERDC-CRREL-NH wrote: I have the expat 1.95 added via standed RHEL repo and using oracle instant client (11.2) without a problem with GDAL from SVN I use ./configure \ --with-libtiff=internal \ --with-geotiff=internal \ --with-jpeg=internal \ --with-libz=internal \ --with-png=internal \ --with-oci=/oracle/instantclient_11_1 \ --with-geos=/usr/local/bin/geos-config \ --with-curl \ --with-threads \ --with-expat=yes \ --with-libkml \ --with-python Mike -- Michael Smith Remote Sensing/GIS Center US Army Corps of Engineers Hanover, NH ___ 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] GDAL/OGR 1.8.1 Advance Warning
Hi Frank! There is a bug in the current Envisat driver which could be fixed in 1.8.1. Not all bands (MDS) are read properly from the MERIS Level 2 imagery. Below are last lines of the output of gdalinfo MER_RR__2PNPDK20110502_144833_24913102_00097_47956_7579.N1 MDSs are numbered from 1 to 13, then 16 and 19. And in the file MDSs 14-15 and 17-18 also exist. I'm not sure if that's the proper place to report this bug but I just follow your invitation. All the best! Anton Band 1 Block=1121x1 Type=UInt16, ColorInterp=Undefined Description = Norm. rho_surf - MDS(1) Band 2 Block=1121x1 Type=UInt16, ColorInterp=Undefined Description = Norm. rho_surf - MDS(2) Band 3 Block=1121x1 Type=UInt16, ColorInterp=Undefined Description = Norm. rho_surf - MDS(3) Band 4 Block=1121x1 Type=UInt16, ColorInterp=Undefined Description = Norm. rho_surf - MDS(4) Band 5 Block=1121x1 Type=UInt16, ColorInterp=Undefined Description = Norm. rho_surf - MDS(5) Band 6 Block=1121x1 Type=UInt16, ColorInterp=Undefined Description = Norm. rho_surf - MDS(6) Band 7 Block=1121x1 Type=UInt16, ColorInterp=Undefined Description = Norm. rho_surf - MDS(7) Band 8 Block=1121x1 Type=UInt16, ColorInterp=Undefined Description = Norm. rho_surf - MDS(8) Band 9 Block=1121x1 Type=UInt16, ColorInterp=Undefined Description = Norm. rho_surf - MDS(9) Band 10 Block=1121x1 Type=UInt16, ColorInterp=Undefined Description = Norm. rho_surf - MDS(10) Band 11 Block=1121x1 Type=UInt16, ColorInterp=Undefined Description = Norm. rho_surf - MDS(11) Band 12 Block=1121x1 Type=UInt16, ColorInterp=Undefined Description = Norm. rho_surf - MDS(12) Band 13 Block=1121x1 Type=UInt16, ColorInterp=Undefined Description = Norm. rho_surf - MDS(13) Band 14 Block=1121x1 Type=UInt16, ColorInterp=Undefined Description = YS, SPM, Rect. Rho- MDS(16) Band 15 Block=1121x1 Type=UInt16, ColorInterp=Undefined Description = Alpha, OPT - MDS(19) On 27/06/2011 14:31, Frank Warmerdam wrote: Folks, I would like to prepare a 1.8.1 release candidate in the next couple days. Developers are encouraged to address any bug fixes they would like promptly. Is there anything folks feel strongly needs to be addressed in 1.8.1 that has not yet made it into the 1.8 branch? Best regards, ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
