Re: [gdal-dev] Re: Looking for advice on finding neighboring features
Kenn Sebesta wrote: Based on some conversations of the list, I've come to understand a little better what I'm looking for, so I'll update my original question here so it's a bit clearer. I need to write a program that automatically determines elevation profiles based on a predetermined path/route. This data needs to come be in some form that it automatically can be read by further functions in my controls package. I plan to do everything in C, but any other processing language would be acceptable. Ken, If you release the shapefile constraint, GMT's grdtrack program is lightning fast in interpolating a grid into a series of x,y positions. Joaquim Luis ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] GCPs in MEM driver, can we?
Hi,
I have my gdalwarp MEX that works reasonably into converting between projection
systems.
And now I would like to have it working to do warping with GPS, but after hours
of struggling
with it, I don't advance a bit. The GCPs are alway ignored.
I do create the GCPs like this
pasGCPs = (GDAL_GCP *) CPLRealloc( pasGCPs, sizeof(GDAL_GCP) *
nGCPCount );
GDALInitGCPs( 1, pasGCPs + nGCPCount - 1 );
for (i = 0; i nGCPCount; i++) {
pasGCPs[i].dfGCPPixel = ptr_d[i];
pasGCPs[i].dfGCPLine = ptr_d[i+nGCPCount];
pasGCPs[i].dfGCPX = ptr_d[i+2*nGCPCount];
pasGCPs[i].dfGCPY = ptr_d[i+3*nGCPCount];
pasGCPs[i].dfGCPZ = 0;
}
Than I set them
GDALSetGCPs( hSrcDS, nGCPCount, pasGCPs, )
and create a transformer
hTransformArg =
GDALCreateGenImgProjTransformer( hSrcDS, pszSrcWKT, NULL,
pszDstWKT,
nGCPCount == 0 ? FALSE : TRUE,
0, 1 );
but this bloody thing always returns me what I set in
eErr = GDALSuggestedWarpOutput2( hSrcDS, GDALGenImgProjTransform,
hTransformArg,
adfDstGeoTransform, nPixels, nLines,
adfExtent, 0 );
and the warping fails (the output is equal to input)
Is this a MEM driver issue, or an error of mine?
Thanks
Joaquim Luis
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] trunk build is broken under windows with MSVC7.1
Hi,
I just updated but the build (MSVC7.1) hangs with
cl /nologo /MD /EHsc /GR /Ox /W3 /DNDEBUG -I..\..\..\port -I..\..\..\ogr
-I..\..\..\gcore -I..\..\..\alg -I..\..\..\ogr\ogrsf_frmts -I.. -I..\.. -DOGR
-DMITAB_USE_OFTDATETIME /c mitab_utils.cpp
mitab_utils.cpp
cl /nologo /MD /EHsc /GR /Ox /W3 /DNDEBUG -I..\..\..\port -I..\..\..\ogr
-I..\..\..\gcore -I..\..\..\alg -I..\..\..\ogr\ogrsf_frmts -I.. -I..\.. -DOGR
-DMITAB_USE_OFTDATETIME /c mitab_imapinfofile.cpp
mitab_imapinfofile.cpp
mitab_imapinfofile.cpp(391) : error C2601: 'IMapInfoFile::SetCharset' : local fu
nction definitions are illegal
mitab_imapinfofile.cpp(400) : fatal error C1075: end of file found before the le
ft brace '{' at 'mitab_imapinfofile.cpp(310)' was matched
NMAKE : fatal error U1077: 'cl' : return code '0x2'
Stop.
C:\programs\GDALtrunk\gdal\ogr\ogrsf_frmts\mitabcd gmlnmake /NOLOGO /f ma
kefile.vccd ..
The system cannot find the path specified.
...
Joaquim Luis
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Question about ENVI Hdr format. Where to find file sample data? Which file extension?
Daniele Romagnoli wrote: Hi list, I'm extending the ImageIO-Ext's supported formats. Now I'm adding ENVI Hdr format support. 1) Where could I find some sample data available in that format? I have already taken a look at http://download.osgeo.org/gdal/data/... (In case data samples are unavailable I will use gdal_translate -OF ENVI from a sample GeoTIFF.) Daniele, The tutorials here have example files http://www.ittvis.com/ProductServices/ENVI/Tutorials.aspx 2) Are the file extensions for that format .bil .bip .bsq? Traditionally they are .img, but I think it doesn't matter Joaquim Luis ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Memory fragmentation and memory consumption when warping with GCPs
Hi, I managed to solve my problem with the GCPs in MEM driver (and sorry if I bothered some with that thread), which turned up to be due to a bad initialization of the dataset geotransform. After that I wrote a MEX version of gdaltransform to be able to reproject points using GCPs. This MEX works but it revealed serious problems. At least under Matlab. Matlab requires not only LOTS of memory but also that the available memory is continuous. For example, if one needs a variable of 100 Mb the system needs to have a chunk of free memory not less than 100 Mb. Two chunks of 99 and 1 Mb are not enough as we'll have an out memory error. Now, I just realize that when I call a MEX that links against gdal.dll the memory immediately becomes highly fragmented. As an example of my current case, I had the largest chunk of free memory of 1070 Mb and after loading gdal.dll the largest chunk become 540 Mb Eventually due to this memory fragmentation, I could not reproject a file having a large number of GCPs ( 5000 GCPs). By decreasing the number of GCPs to half I was able to perform the operation. So one question is, why warping with GCPs takes such large amount of memory (apparently a chunk of 500 Mb was not enough to process 5000 GCPs)? I also tried with the command line GDAL gdaltransform and here I had no problems. So I'm a bit puzzled. Do all programs depend on the memory fragmentation issue, or is it just a Matlab limitation? (Ah, Windows XP here) As a side note, I also have MEXs that link with the OpenCV library, but those do not sensibly fragment the memory. Thanks Joaquim Luis ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Memory fragmentation and memory consumption when warping with GCPs
Frank Warmerdam wrote: Joaquim Luis wrote: So one question is, why warping with GCPs takes such large amount of memory (apparently a chunk of 500 Mb was not enough to process 5000 GCPs)? Joaquim, Is the memory fragmentation really related to the use of many GCPs? Does the same problem occur with 4 GCPs? Frank, Maybe I was not clear enough, but the memory segmentation has nothing to do with the GCP warping. It results from loading the gdal.dll For example, on a fresh start if I call (one other MEX for reading) gdalread without arguments, it prints the usage on screen. After this, which did not perform any calculus, the memory is already fragmented. The issue with the GCPs is that with a largest chunk of ~500 Mb I'm not able to warp with 5000 GCPs. Joaquim I also tried with the command line GDAL gdaltransform and here I had no problems. So I'm a bit puzzled. Do all programs depend on the memory fragmentation issue, or is it just a Matlab limitation? (Ah, Windows XP here) As a side note, I also have MEXs that link with the OpenCV library, but those do not sensibly fragment the memory. It is possible that OpenCV uses a private heap thereby minimising the amount of fragmentation in the master heap. It might also be that OpenEV just doesn't use that much memory. I suspect you are seeing some heap fragmentation and consumption due to GDAL's block caching mechanism but it is really hard to know. You can influence the amount of memory available for the block cache using GDALSetCacheMax(). I'm not in the habit of monitoring heap fragmentation on Win32. I will say that GDAL normally uses malloc() and free() for memory allocation so that may have some implications for heap effects. Best regards, ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Memory fragmentation and memory consumption when warping with GCPs
Joaquim, OK. Well, generally speaking GDAL should allocate relatively little memory just on loading the DLL (and perhaps calling GDALAllRegister()). So I don't know why you are seeing the problem you see. Frank, It's ok. I was not expecting an easy answer but I think this issue worth reporting. Anyway, the fragmentation (note that there is not a total free memory reduction) is probably originated by all the gdal.dll dependencies that one can see with the Dependency Walker being loaded by the gdal.dll Does this aspect really have anything to do with the number of GCPs? Are you using the GDAL warp algorithm? Oh yes, with 2500 GCPs I can do the warping. And yes I'm using the GDAL warp algorithm (the mex is more or less a copy of gdaltransform) Thanks Joaquim ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Memory fragmentation and memory consumption when warping with GCPs
Does this aspect really have anything to do with the number of GCPs? Are you using the GDAL warp algorithm? Oh yes, with 2500 GCPs I can do the warping. And yes I'm using the GDAL warp algorithm (the mex is more or less a copy of gdaltransform) Sorry for being so dumb. The GCP warping memory problem was due to a stupid error of over allocation - nGCPCount*nGCPCount instead of the needed nGCPCount It works fine now. But the memory fragmentation issue is another story, and that still remains. Joaquim Luis ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] help with gdalwarp
Alex Bernstein wrote: Hi all, Sorry for a newbie question. I've been reading this list and searching elsewhere for a few days now to try to figure this out, but I'm still missing something. I need to reproject a map from Plate Caree projection to Lambert Azimuthal Equal Area projection centered on 0N,15E with gdalwarp. I'm using a Natural Earth II map from http://www.shadedrelief.com/natural2/. The map http://www.nacis.org/data/NE2/NE2_land_only.jpg is 16200x8100 pixels, plate caree, WGS84. It also has a world file http://www.shadedrelief.com/natural2/images/world_16000.zip with following information. 0.02 0.00 0.00 -0.02 -180.00 90.00 Alex, The world file name must follow the conventions. If your file is called NE2_land_only.jpg than the world file name must be either NE2_land_only.jgw or NE2_land_only.wld And, humm, there is much sea water on that ..._land_only image Joaquim Luis ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] help with gdalwarp
Alex Bernstein wrote: On Sun, Jan 4, 2009 at 11:00 PM, Joaquim Luis jl...@ualg.pt wrote: Joaquim, renaming the world file to NE2_land_only.jgw was one of first things I've done, sorry I forgot to mention that. So it's not reason for the problems I'm having with reprojection. The coordinates in world file are specified in degrees, is this how it supposed to be, or do I need to pass any switches to gdalwarp to indicate that? Alex, Sorry, I don't know. Normally Lambert Azimuthal Equal Area should take two standard parallels, but it makes no difference here. I tried gdalwarp -s_srs +proj=eqc +lat_ts=0 +lon_0=0 +datum=WGS84 -t_srs +proj=laea +lat_1=20n +lat_2=60n -co TFW=YES NE2_land_only.jpg NE2_land_only_laea.tif which reports ... Upper Left (-180.011, 89.4085425) ( 0d 0'5.82W, 0d 0'2.91N) Lower Left (-180.011, -89.3968263) ( 0d 0'5.82W, 0d 0'2.91S) Upper Right ( 179.9964220, 89.4085425) ( 0d 0'5.82E, 0d 0'2.91N) Lower Right ( 179.9964220, -89.3968263) ( 0d 0'5.82E, 0d 0'2.91S) Center ( -0.0073446, 0.0058581) ( 0d 0'0.00W, 0d 0'0.00N) but the file is not reprojected either. I don't know if it is related but I found many instances where gdalwarp fails on global files. I reported that twice, last one on ticket http://trac.osgeo.org/gdal/ticket/2305 but unfortunately it didn't deserve any attention. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] help with gdalwarp
Alex Bernstein wrote: Joaquim, Thanks for trying to help. I'm actually just interested in the map of Africa from this global map. May be I'll try to figure out gdal commands to crop and transform just the relevant region. That will work fine. I just tried with Mirone and checked against GMT coastlines and the result is quite satisfactory. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Memory fragmentation and memory consumption when warping with GCPs
Joaquim Luis wrote: After that I wrote a MEX version of gdaltransform to be able to reproject points using GCPs. This MEX works but it revealed serious problems. At least under Matlab. Matlab requires not only LOTS of memory but also that the available memory is continuous. For example, if one needs a variable of 100 Mb the system needs to have a chunk of free memory not less than 100 Mb. Two chunks of 99 and 1 Mb are not enough as we'll have an out memory error. Now, I just realize that when I call a MEX that links against gdal.dll the memory immediately becomes highly fragmented. As an example of my current case, I had the largest chunk of free memory of 1070 Mb and after loading gdal.dll the largest chunk become 540 Mb Hello, I follow up on the memory fragmentation issue. I found that the fragmentation is caused by the ECW driver. If compiled without that driver, GDAL doesn't provoke any sensible fragmentation. Joaquim Luis ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] gdalwarp on a file + world file - different limits
Hi, For the next version of GMT we have extended the ability of the ps2raster program to take a postscript file generated by GMT either create a world file, or even further, to call gdalwarp to create a true geotiff file. Next is an example on how it will work pscoast -JS-55/-60/15c -R-77/-55/-57.5/-48r -Df -Gred -P -Bg2 --BASEMAP_TYPE=plain --FRAME_PEN=0.1p out.ps ps2raster out.ps -Tt -W+ -V (which executes this command) gdalwarp -s_srs +proj=stere +lat_0=-60 +lon_0=-55 +k=1 +x_0=0 +y_0=0 +a=6378137.000 +b=6356752.314245 out.tif out.tiff But when I compare the gdalinfo output of the two files they do not agree. Why are the LR coords from the geotiff file different from the tif + .tfw? And where do they come from? Thanks Joaquim Luis # -- THE .TFW CONTENTS 677.678633953751# x_inc 0.0 0.0 -677.201365837256 # y_inc -1389588.373683023000 # X-UL 1335922.909317081300# Y-UL # --- # WHAT DOES GDALINFO SAY ABOUT THE .TIF + .TFW gdalinfo out.tif Upper Left (-1389927.213, 1336261.510) Lower Left (-1389927.213, 329263.079) Upper Right ( -188402.995, 1336261.510) Lower Right ( -188402.995, 329263.079) # --- # WHAT DOES GDALINFO SAY ABOUT THE (GEO).TIFF gdalinfo out.tiff Upper Left (-1389927.213, 1336261.510) Lower Left (-1389927.213, 329523.865) Upper Right ( -188074.869, 1336261.510) Lower Right ( -188074.869, 329523.865) ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdalwarp on a file + world file - different limits
Frank, I'm afraid there was nothing so thought in the use of gdalwarp. Yes, the idea is to assign a coordinate system. Since the world file is meant for referencing linear referencing, it could not correctly describe (for instance) a Mercator projected image. So I thought in using gdalwarp. The fact that the pixels in the TFW are not exactly square is beyond our control. Recall that we start with a postscript image and want to end up with an as-good-as-possible geotiff image. Thanks Joaquim Joaquim Luis wrote: (which executes this command) gdalwarp -s_srs +proj=stere +lat_0=-60 +lon_0=-55 +k=1 +x_0=0 +y_0=0 +a=6378137.000 +b=6356752.314245 out.tif out.tiff Joaquim, I'm curious why you use the above command. What is it intended to do? If it is just to assign the coordinate system you could use gdal_translate with -a_srs. Perhaps the goal is also to rotate non-north up files to be north up? But when I compare the gdalinfo output of the two files they do not agree. Why are the LR coords from the geotiff file different from the tif + .tfw? And where do they come from? ... # -- THE .TFW CONTENTS 677.678633953751# x_inc 0.0 0.0 -677.201365837256# y_inc -1389588.373683023000# X-UL 1335922.909317081300# Y-UL I see the file represented by the TFW does not exactly have square pixels. I presume gdalwarp has developed a square pixel size, and the resulting file had to have it's extents extended a bit to account for the altered pixel size. Perhaps the gdalwarp was actually done to square the pixels? Or perhaps the tfw was improperly computed and the pixels were never really intended to be non-square? Best regards, ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Non documented (nice, uf) behaviour
Hi, Still on the ps2raster issue that I mentioned 2 days ago, I was getting a mysterious crashing in Windows when executing a system call with a gdal_translate command. The is not related to GDAL at all but maybe to the quotes needed to wrap the +proj=... arguments. I finally managed to solve the issue by writing the proj string into a file and use that file as argument to -a_srs But the man page states that ... or a file WKT -a_srs srs_def: Override the projection for the output file. The srs_def may be any of the usual GDAL/OGR forms, complete WKT, PROJ.4, EPSG:n or a file containing the WKT. I'm not complaining (well on the contrary), but we may need to document this. Since what version is it possible to provide a Proj4 string in a file for -a_srs? (I'm using the GDAL trunk) Thanks Joaquim Luis ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Non documented (nice, uf) behaviour
I'm not complaining (well on the contrary), but we may need to document this. Since what version is it possible to provide a Proj4 string in a file for -a_srs? Joaquim, Underlying the -a_srs function is the OGRSpatialReference::SetFromUserInput() method which does mention that proj.4 strings are accepted from a file. The problem is that it is not really practical to describe all coordinate system specification methods everywhere they are used. I have added a brief note in the introductory material on the utilities pages indicating files with several formats are supported. Frank, Thanks and sorry for not be clear enough. When I said we I was thinking on the GMT, because if it was a very new thing we could have to warn users to have a such GDAL version. Joaquim ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] erosion/dilation in gdal ?
Frank Warmerdam wrote: Johan Nouvel wrote: Hello all, Is there a way to do erosion/dilatation on image in gdal ? I've looked in alg.h, but I've seen no straight way to do such thing. Johan, As you very probably know those are operations of the image processing world. If you don't know it yet have a look at the OpenCV library. It is amazingly fast, but doesn't know anything about coordinates. Joaquim Luis ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: Fwd: Re[4]: [gdal-dev] gdalwarp: mercator to lambert azimutal equeal area
Hi, A couple of things, 1. Planar world is not 44.000.000 meters wide. It follows from the meter definitions that it is 40 000 000 meters 2. Mercator maps cannot span to +/- 90 degrees latitude 3. The images in www.oera.net/How2/TextureMaps2.htm are not Mecator 4. and changing something like 179.12345 to 180.0 . You should not do that. Coordinates in the world file are that of the CENTER of the top left pixel 5. The whole thing was easy task with Mirone. I used the first image on that page and with it just do: Put this inside a file named EarthMap_2500x1250.jgw 0.144000 0.0 0.0 -0.144000 -179.928000 89.928000 and now gdalwarp EarthMap_2500x1250.jpg -s_srs +proj=latlong -t_srs +proj=laea EarthMap_2500x1250.jpg dest.jpg Which will show ... another manifestation of the gdalwarp bug (http://trac.osgeo.org/gdal/ticket/2305) when dealing with global files Joaquim Luis I tried georeferencing one of these images ( http://www.oera.net/How2/TextureMaps2.htm ) using MapWindow GIS; the pogram generated a .jgw file, which then I fixed by replacing , by . and changing something like 179.12345 to 180.0 . Then I tried again this command: gdalwarp -s_srs +proj=merc -t_srs +proj=laea world.jpg dest.jpg Ok, program now does not complain for any error... but what I get as output is EXACTLY the SAME image!!! What's wrong now? And how do I specify the center of the Lambert projection to be on north pole? *** BEGIN FORWARDED MESSAGE *** On 09/02/2009 at 13.47 jumpjack jumpj...@libero.it wrote: From: jumpjack jumpj...@libero.it To: Wendy Fay Stevenson steve...@erau.edu CC: gdal-dev@lists.osgeo.org Date: Tue, 10 Feb 2009 18:48:45 +0100 Subject: Re[4]: [gdal-dev] gdalwarp: mercator to lambert azimutal equeal area Thanks, but I can't yet understand... I have a map of the whole world. It is 640 pixel wide. Planar world is 44.000.000 meters wide so which number should I specify as A?? The same applies for E. About C and F: which coordinates should I specify? Lat and Lon? This would be 90,-180, I guess, being the map centered on Lat,Lon=0,0 and 360° wide and 180° tall. Thanks for your pacience. (Please reply on the list, others could be interested!) bye, Jumpjack *** REPLY SEPARATOR *** On 09/02/2009 at 13.47 Wendy Fay Stevenson wrote: As long as the world file is the same name as the input file to gdalwarp, it will work. As for specifying the world file: A: number of meters across / number of pixels across D B: 0 E: -1 * number of meters in length / number of pixels in length C and F specify the center of the top left pixel in eastings and northings, i.e. where on the projection the first pixel corresponds to. *** END FORWARDED MESSAGE *** ___ 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] Converting from Lambert (LCC) to latlong/mercator
Brian, The left side of your image contains a ... legend, so it's not part of the map. How can any program guess what is legend and where the map starts? Joaquim Luis I am still battleing this conversion. I was just informed, via IRC, that gdal won't overwrite existing files, so I may have been making a difference, but not knowing it. In any case, I tossed together a simple script, that thus far, does nothing... #!/bin/sh rm -rf nn.tif n-merc.tif echo '*** Translate ***' gdal_translate n.tif nn.tif -of gtiff -CO TFW=YES -mo TIFFTAG_XRESOLUTION= -mo TIFFTAG_YRESOLUTION= -a_ullr -115d0 56d0 -105d0 54d0 -a_srs +proj=lcc +lat_0=54 +lon_0=-115 +lat_1=49.33 +lat_2=54.66 +x_0=0 +y_0=0 +datum=NAD27 +ellps=clrk80 echo '*** Warp***' gdalwarp -t_srs +proj=merc +datum=WGS84 nn.tif n-merc.tif open n-merc.tif I have also posted the source file I am working with, albeit scaled down and converted so its not 140mb. http://game-sat.com/~brian/north.png What concerns me is what gdalinfo gives me for the intermediate step, as the georeferenced coordinates are dead wrong. If I remove the a_srs to assign it as being an actual lambert conformal projection, it doesn't even have the georeferenced options, just the first ones. $ gdalinfo nn.tif Driver: GTiff/GeoTIFF Files: nn.tif Size is 11696, 4208 Coordinate System is: PROJCS[unnamed, 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[Lambert_Conformal_Conic_2SP], PARAMETER[standard_parallel_1,49.33], PARAMETER[standard_parallel_2,54.66], PARAMETER[latitude_of_origin,54], PARAMETER[central_meridian,-115], PARAMETER[false_easting,0], PARAMETER[false_northing,0], UNIT[metre,1, AUTHORITY[EPSG,9001]]] Origin = (-115.000,56.000) Pixel Size = (0.000854993160055,-0.000475285171103) Metadata: AREA_OR_POINT=Area TIFFTAG_SOFTWARE=Adobe Photoshop CS3 Macintosh TIFFTAG_DATETIME=2009:02:21 16:15:49 TIFFTAG_XRESOLUTION=0 TIFFTAG_YRESOLUTION=0 TIFFTAG_RESOLUTIONUNIT=2 (pixels/inch) Image Structure Metadata: INTERLEAVE=PIXEL Corner Coordinates: Upper Left (-115.000, 56.000) (115d 0'6.32W, 54d 0'1.81N) Lower Left (-115.000, 54.000) (115d 0'6.32W, 54d 0'1.75N) Upper Right (-105.000, 56.000) (115d 0'5.77W, 54d 0'1.81N) Lower Right (-105.000, 54.000) (115d 0'5.77W, 54d 0'1.75N) Center (-110.000, 55.000) (115d 0'6.04W, 54d 0'1.78N) Band 1 Block=11696x1 Type=Byte, ColorInterp=Red Band 2 Block=11696x1 Type=Byte, ColorInterp=Green Band 3 Block=11696x1 Type=Byte, ColorInterp=Blue On Sat, Feb 21, 2009 at 9:55 PM, Brian Murray idle...@gmail.com wrote: I'm trying to get all of it. :) It appears like a_allr is ok, but then when I apply the definition, it only grabs a few meters of the real map... I think I must have to set the scale to something. I just don't know what yet... I am going to sleep on it. I found some sites that have some calculations for that now. On Sat, Feb 21, 2009 at 9:47 PM, Wendy Fay Stevenson steve...@erau.edu wrote: Um, it looks like it's doing what you're asking it to do. What corner points are you wanting? ___ 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] Converting from Lambert (LCC) to latlong/mercator
Brian Murray wrote: I know. I left that on there in the mean time while I figured out the translations. It wasn't even bending the map at all before. The software just sees the image as a blob of data, that you have to tell it how to transform, so it really didn't care that the map had a legend left on it. In my last post, I describe how I finally got it to work. :) Good for you, ... but are you sure it worked? I mean, are you sure that it is correctly referenced? At half way of the description I just quit following it (sorry, too complicated for me). Joaquim Luis On Sun, Feb 22, 2009 at 12:59 PM, Joaquim Luis jl...@ualg.pt wrote: Brian, The left side of your image contains a ... legend, so it's not part of the map. How can any program guess what is legend and where the map starts? Joaquim Luis I am still battleing this conversion. I was just informed, via IRC, that gdal won't overwrite existing files, so I may have been making a difference, but not knowing it. In any case, I tossed together a simple script, that thus far, does nothing... #!/bin/sh rm -rf nn.tif n-merc.tif echo '*** Translate ***' gdal_translate n.tif nn.tif -of gtiff -CO TFW=YES -mo TIFFTAG_XRESOLUTION= -mo TIFFTAG_YRESOLUTION= -a_ullr -115d0 56d0 -105d0 54d0 -a_srs +proj=lcc +lat_0=54 +lon_0=-115 +lat_1=49.33 +lat_2=54.66 +x_0=0 +y_0=0 +datum=NAD27 +ellps=clrk80 echo '*** Warp***' gdalwarp -t_srs +proj=merc +datum=WGS84 nn.tif n-merc.tif open n-merc.tif I have also posted the source file I am working with, albeit scaled down and converted so its not 140mb. http://game-sat.com/~brian/north.png What concerns me is what gdalinfo gives me for the intermediate step, as the georeferenced coordinates are dead wrong. If I remove the a_srs to assign it as being an actual lambert conformal projection, it doesn't even have the georeferenced options, just the first ones. $ gdalinfo nn.tif Driver: GTiff/GeoTIFF Files: nn.tif Size is 11696, 4208 Coordinate System is: PROJCS[unnamed, 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[Lambert_Conformal_Conic_2SP], PARAMETER[standard_parallel_1,49.33], PARAMETER[standard_parallel_2,54.66], PARAMETER[latitude_of_origin,54], PARAMETER[central_meridian,-115], PARAMETER[false_easting,0], PARAMETER[false_northing,0], UNIT[metre,1, AUTHORITY[EPSG,9001]]] Origin = (-115.000,56.000) Pixel Size = (0.000854993160055,-0.000475285171103) Metadata: AREA_OR_POINT=Area TIFFTAG_SOFTWARE=Adobe Photoshop CS3 Macintosh TIFFTAG_DATETIME=2009:02:21 16:15:49 TIFFTAG_XRESOLUTION=0 TIFFTAG_YRESOLUTION=0 TIFFTAG_RESOLUTIONUNIT=2 (pixels/inch) Image Structure Metadata: INTERLEAVE=PIXEL Corner Coordinates: Upper Left (-115.000, 56.000) (115d 0'6.32W, 54d 0'1.81N) Lower Left (-115.000, 54.000) (115d 0'6.32W, 54d 0'1.75N) Upper Right (-105.000, 56.000) (115d 0'5.77W, 54d 0'1.81N) Lower Right (-105.000, 54.000) (115d 0'5.77W, 54d 0'1.75N) Center (-110.000, 55.000) (115d 0'6.04W, 54d 0'1.78N) Band 1 Block=11696x1 Type=Byte, ColorInterp=Red Band 2 Block=11696x1 Type=Byte, ColorInterp=Green Band 3 Block=11696x1 Type=Byte, ColorInterp=Blue On Sat, Feb 21, 2009 at 9:55 PM, Brian Murray idle...@gmail.com wrote: I'm trying to get all of it. :) It appears like a_allr is ok, but then when I apply the definition, it only grabs a few meters of the real map... I think I must have to set the scale to something. I just don't know what yet... I am going to sleep on it. I found some sites that have some calculations for that now. On Sat, Feb 21, 2009 at 9:47 PM, Wendy Fay Stevenson steve...@erau.edu wrote: Um, it looks like it's doing what you're asking it to do. What corner points are you wanting? ___ 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] weeding out x,y,z points
nicholas.g.lawre...@mainroads.qld.gov.au wrote: A client has a very large (millions of records) ascii file consisting solely of x,y,z co-ordinates. They would like to reduce the number of records by weeking out points that are too close to each other. Can GDAL or OGR weed out 3D points based on proximity to each other? A job for GMT's blockmean or blockmedian. Joaquim Luis ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] weeding out x,y,z points
Okay, I downloaded the Manpages. My initial reading is that blockmean and blockmedian work by averaging the values. blockmedian does not do point average. It does take the median point inside each bin. However, if the number of points inside a bin is even than it takes the average of the two central points. My client says that they want the resulting data points to be a subset of the original data points, that is the process should delete points, not re-calculate new ones that are an average. Well, you (or the client) do what you want, but that is not the correct procedure because it may introduce aliasing. What will be the condition to decide the reference point towards which the others are compared? Joaquim ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] create 25D MultiPolygon how to
Mateusz Loskot wrote: for(Roadway::RoadWayArray::iterator itrw = _roadwayArr.begin(); itrw != _roadwayArr.end();itrw++) ++itrw; if you care about performance. Mateusz, Just curious. Why should that impact on performance? Joaquim Luis ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Questions about projects of GSoC 2009
Jorge Arévalo wrote: Hello, Thanks for the link Mateusz. OK, I need your opinion. I've been working during 1 year (still working) in a project that uses gdal library (developing some code), and Postgis, to transform vectorial data (MIF files) on PNG tiles to show over google maps. I use Postgis to perform a previous merge of some vectorial data. Then, I transform the vectorial data in raster files, and burn the polygons over them using given colors. Finally, I transform these raster files in PNG tiles with gdal2tiles. Guys, Maybe this interests you. The GMT tool ps2raster (CVS version) is now able to create KML code from any -- GMT-complicate-as-much-as-you-want -- images. Joaquim Luis ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] unresolved external symbol _GDALRegister caused by a home build of HDF4
Hi, Being victim of a dll hell provoked by Matlab distributing a private zlib1.dll that casts the a hell out in my MEXs I decided to try to escape it by building one myself but with a different name. Well things are not so simple and I had to rebuild not only zlib but also jpeg, szip, curl (this bloody one was particularly painful) and HDF4. After that the final step was to rebuild GDAL using the above dlls (ah, I'm on Windows), but here a very strange thing happens. When I do a fresh build I get these errors at the end compileds\vc71/lib/libcurl_imp_mir.lib wsock32.lib wldap32.lib winmm.lib gcore \Version.res /out:gdal16.dll /implib:gdal_i.lib Creating library gdal_i.lib and object gdal_i.exp gdalallregister.obj : error LNK2019: unresolved external symbol _GDALRegister_HTTP referenced in function _gdalallregis...@0 gdalallregister.obj : error LNK2019: unresolved external symbol _GDALRegister_WMS referenced in function _gdalallregis...@0 gdalallregister.obj : error LNK2019: unresolved external symbol _GDALRegister_WCS referenced in function _gdalallregis...@0 ... gdalallregister.obj : error LNK2019: unresolved external symbol _GDALRegister_netCDF referenced in function _gdalallregis...@0 gdalallregister.obj : error LNK2019: unresolved external symbol _GDALRegister_GMT referenced in function _gdalallregis...@0 gdal16.dll : fatal error LNK1120: 9 unresolved externals However, if I first build GDAL using an official HDF4.r2 (the one I was using before) and with successfully ends I change the nmake.opt to use now the HDF4 (r4) that I built than the GDAL build process ends fine and I get a workable gdal.dll I'm puzzled with this. Where do those errors of unresolved external symbols in GDALAllRegister come from in the first instance? Thanks Joaquim Luis ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] extract vector/raster data from GeoPDF
Brent Fraser wrote: I see the example calculation of the transformation matrix, and a statement I created a GeoPDF by running the Postscript file through Ghostscript to create a Postscript file that looks like this But I don't see where the georeferencing is written into PDF to make it a GeoPDF. Is it a Ghostscript command line? Brent, One only has to convert it to pdf using ghostscript. I did it with GMT's ps2raster, like that ps2raster quad.ps -Tf -A Joaquim Luis Brent Klokan Petr Přidal wrote: Hi, There is a great blog post (and the linked worked example post with details): http://geopdf.blogspot.com/2009/02/geopdf-map-for-worked-example.html It shows you how to create geopdf via GhostScript - so there is already a practical open-source example how to encode the georeference into the PDF/PS according the OGC standard - for use in Acrobat Reader. To add support for such tag in MapServer, which generates pdf dynamicaly via pdflib, should not be totally problematic. Decoding is not as hard either, there are nice libraries like poppler (http://poppler.freedesktop.org/), which allows you to parse vectors (and convert them to SVG for example) or rasterize the PDF files (into TIFF,...) via Cairo. The work is in assigning correct geographic coordinates to the coordinate system internally used in PDF files and especially write the bridge to the outside world (with GDAL/OGR). I am afraid that authors of the GeoPDF standard would not like this, as it seems that the idea of GeoPDF is see it in the Acrobat, print it, but that's all. At least I think so, because they discontinued their Geopdf2geotiff product and all the conversion tools are just one way - into GeoPDF. Please correct me... Anyway, in this moment you can quite easily use utility like pdfimages to extract full quality image tiles from any GeoPDF (like those from USGS) and merge it based on their location in PDF into one GDAL file via VRT (gdalbuildvrt) with a bit of hacking. This is what I did for my favorite USGS DRG of Grand Canyon ;-). Look at: http://klokan.mzk.cz/~klokan/geopdf/ - soon I will update the MapTiler.org overlay examples... Unfortunately all PDF parsing libraries I know are GPL, and that means we can't use them for the gdal driver - because of the license issues. But to create a GPL utility for converting GeoPDF to anything what GDAL/OGR supports should be OK. Poppler can be the best base of such GDAL-based utility for reading/rasterizing of the GeoPDF files. Now just find a sponsor and time to make it ;-). Best, Klokan Petr Pridal ___ 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] extract vector/raster data from GeoPDF
Brent,
I was also digging a bit on this matter. It's true that the blogger only opens
our appetite as there is no more details on how to do it generally. I mean, for
UTM maps it has become fairly obvious how one can do it. The relevant part in
the
PS file is
[ {ThisPage}
/LGIDict
/Description Title
/CTM [(35.28267) (0) (0) (35.28267) (205188.64) (3207094.8)]
/Projection
/Description (WGS 84 UTM 16N)
/ProjectionType (TC)
/Datum (WGE)
/CentralMeridian (-87.0)
/OriginLatitude (0.0)
/FalseEasting (50.0)
/FalseNorthing (0.0)
/ScaleFactor (0.999600)
/Type /Projection
/Type /LGIDict
/Version (2.1)
/PUT pdfmark
However, there is no more info on how to program in this TerraGo way
A next post shads a bit more lite on the matter.
http://geopdf.blogspot.com/2009/02/geopdf-and-geops-with-adobe-style.html
As you can see in the quada.ps file there is an alternative Adobe way,
which encodes the referencing as
% embed georegistation info
[ {ThisPage}
/VP [
/Type /Viewport
/BBox[0 0 dh dv]
/Name Title
/Measure
/Type /Measure
/Subtype /GEO
/Bounds[0 0 0 1 1 1 1 0]
/GPTS[29.0 -90.0 30.0 -90.0 30.0 -89.0 29.0 -89.0]
/LPTS[0.024324 0.039461 0.051689 0.978774 0.975675 0.961136 0.957432
0.022122]
/GCS
/Type /PROJCS
/WKT
(PROJCS[WGS_1984_UTM_Zone_16N,GEOGCS[GCS_WGS_1984,DATUM[D_WGS_1984,SPHEROID[WGS_1984,6378137,298.257223563]],PRIMEM[Greenwich,0],UNIT[Degree,0.017453292519943295]],PROJECTION[Transverse_Mercator],PARAMETER[latitude_of_origin,0],PARAMETER[central_meridian,-87],PARAMETER[scale_factor,0.9996],PARAMETER[false_easting,50],PARAMETER[false_northing,0],UNIT[Meter,1]])
]
/PUT pdfmark
Now this is more familiar, except for the
/LPTS[0.024324 0.039461 0.051689 0.978774 0.975675 0.961136 0.957432 0.022122]
part that, contrary to the promise has not been explained where it comes from.
I think I could implement the first encoding type in GMT's ps2raster (if I knew
all the specs)
Second type would be even easier ... if we had a way to translate the GMT
projection syntax into
WKT, which we don't.
Joaquim
Joaquim,
Doing the format conversion from .ps to pdf is one thing (and there
are several ways to do it), but embedding the georeferencing in the PDF
to make it a GeoPDF is the interesting bit. I haven't found any open
source project capable of do that. Or even capable of writing the PDF
elements (e.g. Frames) necessary for writing the GeoPDF information.
But I remain hopeful...
Brent
Joaquim Luis wrote:
Brent Fraser wrote:
I see the example calculation of the transformation matrix, and a
statement I created a GeoPDF by running the Postscript file through
Ghostscript to create a Postscript file that looks like this
But I don't see where the georeferencing is written into PDF to make
it a GeoPDF. Is it a Ghostscript command line?
Brent,
One only has to convert it to pdf using ghostscript.
I did it with GMT's ps2raster, like that
ps2raster quad.ps -Tf -A
Joaquim Luis
Brent
Klokan Petr Přidal wrote:
Hi,
There is a great blog post (and the linked worked example post
with details):
http://geopdf.blogspot.com/2009/02/geopdf-map-for-worked-example.html
It shows you how to create geopdf via GhostScript - so there is
already a practical open-source example how to encode the georeference
into the PDF/PS according the OGC standard - for use in Acrobat
Reader. To add support for such tag in MapServer, which generates pdf
dynamicaly via pdflib, should not be totally problematic.
Decoding is not as hard either, there are nice libraries like poppler
(http://poppler.freedesktop.org/), which allows you to parse vectors
(and convert them to SVG for example) or rasterize the PDF files (into
TIFF,...) via Cairo.
The work is in assigning correct geographic coordinates to the
coordinate system internally used in PDF files and especially write
the bridge to the outside world (with GDAL/OGR).
I am afraid that authors of the GeoPDF standard would not like this,
as it seems that the idea of GeoPDF is see it in the Acrobat, print
it, but that's all. At least I think so, because they discontinued
their Geopdf2geotiff product and all the conversion tools are just one
way - into GeoPDF. Please correct me...
Anyway, in this moment you can quite easily use utility like
pdfimages to extract full quality image tiles from any GeoPDF (like
those from USGS) and merge it based on their location in PDF into one
GDAL file via VRT (gdalbuildvrt) with a bit of hacking. This is what I
did for my favorite USGS DRG of Grand Canyon ;-).
Look at: http://klokan.mzk.cz/~klokan/geopdf/ - soon I will update the
MapTiler.org overlay examples...
Unfortunately all PDF parsing libraries I know are GPL, and that means
we can't use them for the gdal driver - because of the license issues.
But to create a GPL utility for converting GeoPDF to anything what
GDAL/OGR supports should
Re: [gdal-dev] extract vector/raster data from GeoPDF
Peter J Halls wrote: A bit of googling determines that the 'Adobe way' structure, together with its elements, is defined in the ISO PDF definition - ISO 32000-1 (2008). Looking at this with a PostScript Developer hat, the /LPTS has to be associated with scaling / transforming the GPTS coordinates to the page coordinate system. There is a need to refer to the standard! Yes, And the TerraGo way comes possibly from this document GeoPDF Encoding Best Practice Version 2.2 http://portal.opengeospatial.org/files/?artifact_id=2 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] extract vector/raster data from GeoPDF
Brent Fraser wrote: Joaquim, Interesting! As Peter pointed out, the LPTS tag is the transformation matrix to go from projected coords to page coords, and is created by forming the UTM-page coordinates tranformation (from the information in the CTM tag below) and inverting it (there's a brief mention near the end of http://geopdf.blogspot.com/2009/02/georegistration-worked-example.html) Since the TerraGo way has been superceded by the Adobe/ISO way (thank goodness!), it makes it easier to identify the reference system definition in GDAL, so there may be some hope for GDAL and GeoPDF. Now I need to think about my requirements for reading and writing GeoPDFs. Write a Postscript driver for GDAL? Figure out how to write the equivalent info into a PDF using Mapserver/Cairo? Yikes! Brent, I am on this list more to keep learning (as the present case) than as a core GDAL user (but I use GDAL a lot in Mirone). In fact I am much more a GMT user where I also do some development. I mentioned it before here but probably it slipped away, the GMT program ps2raster can write world files and create GeoTIFFs (from system calls to GDAL) from postscript files created by GMT. I think that it wouldn't be very hard to extend ps2raster's ability to write GeoPDFs if, as I said before, there was a way to get a WKT from a -J... GMT syntax. Anyway, it wouldn't be a GDAL solution and a write-only one so I don't know what else to tell you. Joaquim ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] extract vector/raster data from GeoPDF
Brent Fraser wrote: Since the TerraGo way has been superceded by the Adobe/ISO way (thank goodness!), it makes it easier to identify the reference system definition in GDAL, so there may be some hope for GDAL and GeoPDF. Still on this matter, the GeoPDF http://www.terragotech.com/blog/quada.pdf written in the Adobe way is not recognized as a GeoPDF by my Acrobat with the TerraGo Toolbar and it crashes Chrome when trying to download it!!! ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Missing msvcr80.dll ?
Mateusz Loskot wrote: Joaquim Luis wrote: Harsh Govind wrote: And unlike previous versions (msvcrt71) you cannot copy over 8.0 versions dlls from somewhere to your application directory in order to make it work. The solution per Martin's suggestion is to install vcredist.exe. Excuse the ingenuity, but than why build GDAL with MSVC 2003? Why introducing this pain? What is the gain? One could ask why to build GDAL using GCC 3.x+ ? It's perfectly valid to ask users to install re-distributable package of C/C++ Run Time libraries as it is valid to ask for version 5 or 6 of libc. Fortunately I build my own binaries so I can chose the level of pain. Joaquim Luis ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] extract vector/raster data from GeoPDF
Brent Fraser wrote: User error. I had to turn on the Tools - Analysis - Geospatial Location Tool to get the scrolling Lat/Lon. That's right, thanks Joaquim ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] converting ascci to geotiff
Riki Tiki wrote: Hi, Phase 1) let's assume i convert the geotiff - file1.tif to ascii grid file - file2.txt... Phase 2) later on i change some of the values of file2.txt, now i want to again convert the file2.txt (with changed data part...) to geotiff with the projection information of file1.tif... Can you help me to work around this phase? Riki, What type of modifications you want to do on the .tif file? It would be easier if they can be done with a tool that does not imply format conversion. When you convert to ascii, in what format will the data be? The fact that it is in ascii doesn't imply that it hasn't a format. If the ascii file is on the form (x, y, z) you'll have to regrid it again in order convert it back to, for instance, geotiff. In the GDAL world that is done by gdal_grid. Joaquim luis ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] ERROR 6: SetNoDataValue() not supported for this dataset.
Hi, In this example I get the (apparently innocuous) error message below. The file is correctly converted, but why is it complaining? gdal_translate w020n40.Bathymetry.srtm lixo.tiff ERROR 6: SetNoDataValue() not supported for this dataset. Input file size is 4800, 6000 0...10...20...30...40...50...60...70...80...90...100 - done. w020n40.Bathymetry.hdr BYTEORDER M LAYOUTBIL NROWS 6000 NCOLS 4800 NBANDS1 NBITS 16 PIXELTYPE SIGNEDINT BANDROWBYTES 9600 TOTALROWBYTES 9600 BANDGAPBYTES 0 NODATA-32768 ULXMAP-19.99583 ULYMAP39.99583 XDIM 0.008 YDIM 0.008 Joaquim Luis ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] ERROR 6: SetNoDataValue() not supported for this dataset.
Yes, strange it is. I'm using trunk as well (from yesterday) but I don't get it when I use FWTools. Even weirder, I used GTiff just as an easy example but the original place where I saw it is with my gdalread MEX, which only reads a dataset and does not attempt to write it anywhere. Even Rouault wrote: Selon Joaquim Luis jl...@ualg.pt: I can't reproduce your issue with trunk, nor can I understand how it can happen. This error message is thrown when a driver doesn't implement the SetNoDataValue() method. But the GTiff driver has supported it for ages. Hi, In this example I get the (apparently innocuous) error message below. The file is correctly converted, but why is it complaining? gdal_translate w020n40.Bathymetry.srtm lixo.tiff ERROR 6: SetNoDataValue() not supported for this dataset. Input file size is 4800, 6000 0...10...20...30...40...50...60...70...80...90...100 - done. w020n40.Bathymetry.hdr BYTEORDER M LAYOUTBIL NROWS 6000 NCOLS 4800 NBANDS1 NBITS 16 PIXELTYPE SIGNEDINT BANDROWBYTES 9600 TOTALROWBYTES 9600 BANDGAPBYTES 0 NODATA-32768 ULXMAP-19.99583 ULYMAP39.99583 XDIM 0.008 YDIM 0.008 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
[gdal-dev] gdaldem Roughness description
Hi, At least in my understanding the gdaldem manual's description for the Roughness is misleading. It states Roughness is the the largest inter-cell difference of a central pixel and its surrounding cell, as defined in Wilson et al (2007, Marine Geodesy 30:3-35). From that I understood that R = MAX(Zi-Zcentral) where Zi runs over all pixels in the rectangular neighborhood. However, what the code computes (correctly according to the paper it refers to) is R = Zmax - Zmin that is also known as the range filter in image processing. Joaquim Luis ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Minimalist GDAL 1.6.2 / 1.6.3 binaries for Windows to work around Xerces binary conflicts?
Jason, In what concerns TheMathWorks (Matlab), it's not only xercers that you must worry about but also netCDF, zlib1 and very likely some others. For example many ML releases used an old, or not compatible, zlib1.dll that simply got in the way and screwed everything. Now they are more modern and use manifest, which potentially screw you in the same way. I solved that by creating (recompiling) zlib1, netcdf, libjpeg, ... with different names so that they be called and used peacefully from my GDAL based mexs (which don't link against Xerces). Joaquim Luis Tamas, Thank you for the specific instructions on that. It sounds very easy. I will try it out this afternoon. I know what you mean, that it is difficult to decide on a combination of dependencies that meets the needs of everyone. I thought that maybe the presence of a minimalist Windows binary on the main download page indicated that the GDAL team thought that the minimalist combination was worthwhile to produce on a regular basis. But I can see how choosing things will be a slippery slope that the team would not want to go down. As it stands, even with your helpful instructions and SDK, it is not possible to use GDAL with Xerces support in conjunction with MATLAB, ArcGIS, or other projects that also leverage Xerces and do the same thing that GDAL does: compile Xerces with dynamic linking and retain the default name of the DLL. The ultimate solution to this problem is to have the various projects that use Xerces adopt a naming or binding convention that prevents the problem from occurring. Ideally the Xerces team would recognize this problem and provide guidance. (I have not tried to raise it with them.) Absent that, perhaps statically linking with Xerces, or changing the DLL name to something specific to GDAL, would be appropriate. Of course, this is a classic game theory problem: all the players (GDAL, ESRI, MathWorks, and others) would prefer that the *other* players take the effort to compile Xerces in the non-default manner, so that they can continue to use the default compilation. I am hoping that eventually the GDAL team would take an interest in this and make a change; getting through the corporate development processes of ESRI and MathWorks is very hard. Nonetheless, those organizations are just as much responsible for the problem as GDAL, and I am not offering a negative critique of anyone. I very much appreciate the efforts of the GDAL team, who save me countless hours in various ways, even if you don't ever fix this problem. It is just sad when the dreams of efficient modularity and reuse do not fully deliver, despite everyone's best efforts, and one finds oneself the loser by reaching for too much interoperability. (Sorry for the dramatic statement.) ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Minimalist GDAL 1.6.2 / 1.6.3 binaries for Windows to work around Xerces binary conflicts?
Jason Roberts wrote: Hi Joaquim, Thanks for sharing your experience with that. Fortunately I have not hit the compatibility problem with other libraries. Perhaps it is because I'm using the MATLAB Compiler / MATLAB Component Runtime (MCR, not mex, and only referencing a very limited number of MATLAB functions and toolboxes. My guess is that those other libraries are delay loaded or explicitly loaded, and that I'm just getting lucky by not using MATLAB to read netCDFs, for example. Hmm, I use the compiler as well, but not that pretend-to-be-a-compiler-one. I use the good old one 6.5 true compiler. The approach you recommend, renaming those common libraries, seems like a good way to deal with it. Actually, I'm afraid it's not that simple. We can't just rename the dlls, we have to rebuild them with a different name. Frank W mentioned in a private email that he thought that GDAL is using binaries provided by the Xerces team. If that is indeed the case, then this Xerces compatibility issue may arise from ESRI or MathWorks compiling their own Xerces, rather than using the one provided by the Xerces team. In that case, I would say that ESRI and MathWorks are breaking interoperability, and I'd have a hard time making a case that GDAL should do anything different... Absolutely true according to my experience. TMW, which I know better, behaves like it has the King in the belly (a Portuguese saying). They just don't give a shit for the official libraries and ship their own ones, which wouldn't be a problem if it didn't interfere with the outside world, but they do. I had also troubles with ArcGis that installed old incompatible zlib1.dll under Windows/system32. Just imagine the chaos that it produced on the classroom machines (for that one I'm free, since by principle I don't get nearer than 5 m to a computer with Arcs in it). ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] How to supress std io of gdal?
I have also reported troubles of this type that unfortunately slipped across the last two gdal releases without being addressed. http://trac.osgeo.org/gdal/ticket/3195 Here the problem is even worst as the errors are print to stdout Joaquim Luis Sam, Is there a way to redirect it to some other buffer? Like an internal stream which can then be properly propagated via exceptions or written into a log? It is probably not as sophisticated as you want or need but have you tried that: gdalinfo out.tif stdout.txt 2 stderr.txt Regards, Ivan Thanks Sam -- NEU: Mit GMX DSL über 1000,- ¿ sparen! http://portal.gmx.net/de/go/dsl02 ___ 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] Warp a file from two separate Lat and Long
Luisa, I normally restrain to propose GMT solutions here, but I'll open one more exception now as this problem seams easy to solve with it and also because I have o idea how to do it with GDAL. For this, if your grids are not in netCDF, you will need a GMT built with GDAL support (I have one for Windows in Mirone's download page) Use grd2xyz to construct a x,y,z (lon,lat,val) that will be instantaneously georeferenced # Below the '=gd' is not part of the file's name but instead the instruction to direct GMT to use GDAL to read the grids # No need for this if grids are netCDF grd2xyz grid_withd_data=gd -Z val.z grd2xyz grid_withd_lon=gd -Z lon.x grd2xyz grid_withd_lat=gd -Z lat.y # Now paste the 3 columns paste lon.x lat.y val.z data.xyz Probably at this point you will need to interpolate the data.xyz file to create a new grid as the lon lats are likely not north-south aligned (satellite data?) and not equispaced. Joaquim Luis Greetings I've used GDAL a few times but this is the first time that I'm lost on what I can do with GDAL to solve my problem. I have 3 separate files, one with my data, other with Lattitude and another with Longitude. They have the same size and, as an example, it means that Pixel (1,1) of data is located in latitude retrieved from Pixel (1,1) from latitude and longitude (pixel (1,1) from longitude). All of them are in WGS84 but without GCP's points. I need to create a georreferenced/rectified Geotiff with this data and, to do that, I need lat and Long. How can I do this? Thanks Best regards, Luisa Peña S.Paulo, Brazil ___ 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] make install -- copy shapefil.h into the include dir
Hi, I have a MEX that links against shapelib and works fine. However, I just tried to link it against GDAL since it has the same ability to read shapefiles in OGR and it also works. All I had to do was to copy the shapefil.h from ...\gdal\ogr\ogrsf_frmts\shape to ...\gdal\include so can I ask as a kind of enhancement request that the shapefil.h be moved to the include dir by the make install procedure so that for the next GDAL release I can have my makefiles link that MEX to GDAL only and therefore drop the need of having also a shapelib instaled? Thanks Joaquim Luis ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] make install -- copy shapefil.h into the include dir
Even, Thanks for the feedback. I think I understand what you mean but on the other hand I got puzzled as well. Glad that my memory is not too rotten with age as I remember one of your mails that ended up as ticket #1810 http://trac.osgeo.org/gdal/ticket/1810 where you explained that (and this is my interpretation of it), on Windows the --with-hide-internal-symbols behavior is the default one. But I'm testing on Windows and it worked fine with the link to gdal_i.lib. If it works here, why should it fail on *nix? Joaquim Joaquim, I'm not sure this is a good idea. Shapelib and its header file is an internal dependency of GDAL/OGR and should probably remain as such. I'd note we made recently necessary changes to some utilities (gdaltindex comes to mind) to use OGR API and drop their explicit dependency to shapelib. I'd note that, in some builds of GDAL, shapelib symbols embedded in the Shapefile driver could even not be exported (for example if configure is run with --with-hide-internal-symbols) Le Thursday 25 February 2010 17:49:23 Joaquim Luis, vous avez écrit : Hi, I have a MEX that links against shapelib and works fine. However, I just tried to link it against GDAL since it has the same ability to read shapefiles in OGR and it also works. All I had to do was to copy the shapefil.h from ...\gdal\ogr\ogrsf_frmts\shape to ...\gdal\include so can I ask as a kind of enhancement request that the shapefil.h be moved to the include dir by the make install procedure so that for the next GDAL release I can have my makefiles link that MEX to GDAL only and therefore drop the need of having also a shapelib instaled? Thanks 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
[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\frmtscd 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] gdalwarp's default nodata value
On 12-05-2010 05:55, Chaitanya kumar CH wrote: Joaquim, On Wed, May 12, 2010 at 5:07 AM, Joaquim Luis jl...@ualg.pt mailto:jl...@ualg.pt wrote: Hi, Before filling a ticket I would like to ask here if this gdalwarp behavior is the intended one. When I convert a grid from geogs to UTM the nodatavalues are filled with zeros. I get the expected behaviour if I use the -dstnodata with a numeric value, but I found no way tom tell it use NaN. Summary This puts zeros on the nodata zone, but I don't find it correct as 0 is not exactly a natural nodata value. For my habits NaN is the natural no data value. NaN should always be treated as a special case in coding. Imagine performing a type conversion. Since we usually deal with real world data, we know the data value range. We should be able to choose a nodata value not in the data range. Hi Chaitanya, Taking your argument of the real world data, it is why the default choice of zero for nodata is one of worst possible choices. At least for the case of floating point data. Imagine that the input grid has zeros as perfectly valid values, how will any application be able to distinguish between the good and the bad zeros on the warped result? gdalwarp -s_srs +proj=latlong -t_srs +proj=utm +zone=29 +datum=WGS84 swath_grid.grd lixo_utm.tiff Furthermore when I load the lixo_utm.tiff in Mirone is does not recognize a nodata value, whilst if I do this instead gdalwarp -s_srs +proj=latlong -t_srs +proj=utm +zone=29 +datum=WGS84 -dstnodata 1 swath_grid.grd lixo_utm.tiff than 1 is recognized as the nodata. I have not investigated the metadata to see why the 0 is not set to represent the nodata. Perhaps swath_grid.grd doesn't have a nodata value set. The grid was created by GMT (it always sets a nodata value defaulting no NaN) but that is not the problem. I dug a bit more on this and actually there is no problem at all in what respects recognizing the nodata value even when I let gdalwarp use the default value of zero. But my real problem is with my gdalwarp_mex MEX file used in Mirone. Even if I add this for (i = 0; i nBands; i++) GDALSetRasterNoDataValue( GDALGetRasterBand(hDstDS, i+1),999.0); the warped dataset has the correct nodata value in its metadata but the array still has zeros where it should have 999.0 I checked again against the gdalwarp.cpp code and the only difference I'm able to identify is that in gdalwarp_mex I'm using the MEM driver (I have to since data never lands on hard disk). I'm lost on this one. Joaquim ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdalwarp's default nodata value
On 12-05-2010 15:58, Chaitanya kumar CH wrote: Joaquim, GDALSetRasterNoDataValue() sets only the metadata. It doesn't actually change the nodata pixels. We need to process each pixel to do this. Or you could just create a VRT mentioning the source and vrt nodata values. Chaitanya, Thanks, but sorry I don't get it. I thought that it was up to the warping machinery to use the nodata value that it was instructed to and put them in the array positions of nodatavalue. If, at a certain point, it decides to put zeros at some memory addresses than at that point it should simply put the nodata value. It seams quite logic this reasoning no? Please no VRTs since this is a pure memory operation. http://www.gdal.org/gdal_vrttut.html http://www.gdal.org/gdalbuildvrt.html On Wed, May 12, 2010 at 6:33 PM, Joaquim Luis jl...@ualg.pt mailto:jl...@ualg.pt wrote: On 12-05-2010 05:55, Chaitanya kumar CH wrote: Joaquim, On Wed, May 12, 2010 at 5:07 AM, Joaquim Luis jl...@ualg.pt mailto:jl...@ualg.pt wrote: Hi, Before filling a ticket I would like to ask here if this gdalwarp behavior is the intended one. When I convert a grid from geogs to UTM the nodatavalues are filled with zeros. I get the expected behaviour if I use the -dstnodata with a numeric value, but I found no way tom tell it use NaN. Summary This puts zeros on the nodata zone, but I don't find it correct as 0 is not exactly a natural nodata value. For my habits NaN is the natural no data value. NaN should always be treated as a special case in coding. Imagine performing a type conversion. Since we usually deal with real world data, we know the data value range. We should be able to choose a nodata value not in the data range. Hi Chaitanya, Taking your argument of the real world data, it is why the default choice of zero for nodata is one of worst possible choices. At least for the case of floating point data. Imagine that the input grid has zeros as perfectly valid values, how will any application be able to distinguish between the good and the bad zeros on the warped result? gdalwarp -s_srs +proj=latlong -t_srs +proj=utm +zone=29 +datum=WGS84 swath_grid.grd lixo_utm.tiff Furthermore when I load the lixo_utm.tiff in Mirone is does not recognize a nodata value, whilst if I do this instead gdalwarp -s_srs +proj=latlong -t_srs +proj=utm +zone=29 +datum=WGS84 -dstnodata 1 swath_grid.grd lixo_utm.tiff than 1 is recognized as the nodata. I have not investigated the metadata to see why the 0 is not set to represent the nodata. Perhaps swath_grid.grd doesn't have a nodata value set. The grid was created by GMT (it always sets a nodata value defaulting no NaN) but that is not the problem. I dug a bit more on this and actually there is no problem at all in what respects recognizing the nodata value even when I let gdalwarp use the default value of zero. But my real problem is with my gdalwarp_mex MEX file used in Mirone. Even if I add this for (i = 0; i nBands; i++) GDALSetRasterNoDataValue( GDALGetRasterBand(hDstDS, i+1),999.0); the warped dataset has the correct nodata value in its metadata but the array still has zeros where it should have 999.0 I checked again against the gdalwarp.cpp code and the only difference I'm able to identify is that in gdalwarp_mex I'm using the MEM driver (I have to since data never lands on hard disk). I'm lost on this one. Joaquim -- 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] gdalwarp's default nodata value
Software ASCII Grid (.grd) GSBG (rw+): Golden Software Binary Grid (.grd) GS7BG (ro): Golden Software 7 Binary Grid (.grd) COSAR (ro): COSAR Annotated Binary Matrix (TerraSAR-X) TSX (ro): TerraSAR-X Product COASP (ro): DRDC COASP SAR Processor Raster R (rwv): R Object Data Store PNM (rw+): Portable Pixmap Format (netpbm) DOQ1 (ro): USGS DOQ (Old Style) DOQ2 (ro): USGS DOQ (New Style) ENVI (rw+v): ENVI .hdr Labelled EHdr (rw+v): ESRI .hdr Labelled GenBin (ro): Generic Binary (.hdr Labelled) PAux (rw+): PCI .aux Labelled MFF (rw+): Vexcel MFF Raster MFF2 (rw+): Vexcel MFF2 (HKV) Raster FujiBAS (ro): Fuji BAS Scanner Image GSC (ro): GSC Geogrid FAST (ro): EOSAT FAST Format BT (rw+): VTP .bt (Binary Terrain) 1.3 Format LAN (ro): Erdas .LAN/.GIS CPG (ro): Convair PolGASP IDA (rw+): Image Data and Analysis NDF (ro): NLAPS Data Format EIR (ro): Erdas Imagine Raw DIPEx (ro): DIPEx LCP (rov): FARSITE v.4 Landscape File (.lcp) RIK (ro): Swedish Grid RIK (.rik) USGSDEM (rw): USGS Optional ASCII DEM (and CDED) GXF (ro): GeoSoft Grid Exchange Format HTTP (ro): HTTP Fetching Wrapper BAG (ro): Bathymetry Attributed Grid HDF5 (ro): Hierarchical Data Format Release 5 HDF5Image (ro): HDF5 Dataset NWT_GRD (ro): Northwood Numeric Grid Format .grd/.tab NWT_GRC (ro): Northwood Classified Grid Format .grc/.tab ADRG (rw+v): ARC Digitized Raster Graphics SRP (rov): Standard Raster Product (ASRP/USRP) BLX (rw): Magellan topo (.blx) Rasterlite (rw): Rasterlite WKTRaster (ro): PostGIS WKT Raster driver SAGA (rw+v): SAGA GIS Binary Grid (.sdat) Joaquim, I believe what you see is the expected behaviour. You must keep in mind that there are 2 notions : 1) nodata value -- setting it is no more than just setting a tag on the raster band. It doesn't change the pixel values by itself as Chaintanya explained 2) initialization of the pixel data of the target image with a given value When you use the -dstnodata option, gdalwarp will automagically do both : 1) Set the target nodata value 2) Initialize the target image with that nodata value (remind of removing the target file if it already exists) If you specify nothing, then 0 is used to fill the target image but the nodata tag is not set. The initialization of the pixel data of the target image is in fact done through the INIT_DEST warping option. See http://gdal.org/structGDALWarpOptions.html#0ed77f9917bb96c7a9aabd73d4d06e08 For example, gdalwarp src.tif dst.tif -wo INIT_DEST=255 If you specify no INIT_DEST warping option, then gdalwarp uses the dstnodata value if it's specified with -dstnodata and set it as the INIT_DEST value too. I've also tested -dstnodata nan and to my great surprise, it actually works ! However I'm not sure if all applications can deal with the nan string put in the 42113 tag used by GDAL for the Nodata value in TIFF. So maybe I've not understood what your problem is, but everything seems to work as expected on my side. Best regards, Even Le Wednesday 12 May 2010 01:37:07 Joaquim Luis, vous avez écrit : Hi, Before filling a ticket I would like to ask here if this gdalwarp behavior is the intended one. When I convert a grid from geogs to UTM the nodatavalues are filled with zeros. I get the expected behaviour if I use the -dstnodata with a numeric value, but I found no way tom tell it use NaN. Summary This puts zeros on the nodata zone, but I don't find it correct as 0 is not exactly a natural nodata value. For my habits NaN is the natural no data value. gdalwarp -s_srs +proj=latlong -t_srs +proj=utm +zone=29 +datum=WGS84 swath_grid.grd lixo_utm.tiff Furthermore when I load the lixo_utm.tiff in Mirone is does not recognize a nodata value, whilst if I do this instead gdalwarp -s_srs +proj=latlong -t_srs +proj=utm +zone=29 +datum=WGS84 -dstnodata 1 swath_grid.grd lixo_utm.tiff than 1 is recognized as the nodata. I have not investigated the metadata to see why the 0 is not set to represent the nodata. Thanks 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] gdalwarp's default nodata value
papszWarpOptions = CSLSetNameValue(papszWarpOptions, INIT_DEST, nan );
than I get zeros again in place of the nodata.
Works for me. You'll have to use your debugger I'm afraid
For the rec, VS2010 and a quite recent trunk version.
papszWarpOptions = CSLSetNameValue(papszWarpOptions, INIT_DEST, NO_DATA
); ...
psWO-padfSrcNoDataReal = (double *)
CPLMalloc(psWO-nBandCount*sizeof(double)); psWO-padfSrcNoDataImag =
(double *) CPLMalloc(psWO-nBandCount*sizeof(double)); for (i = 0; i
nBands; i++) {
psWO-padfSrcNoDataReal[i] = 500.;
psWO-padfSrcNoDataImag[i] = 0.0;
GDALSetRasterNoDataValue( GDALGetRasterBand(hDstDS, i+1),
pdfDstNodata[0]); }
Hum, do you realize that you set padfSrcNoDataReal ? INIT_DEST=NO_DATA will
fetch from padfDstNoDataReal as stated in the above doc...
Ghrr, blind copy-paste is-what-it-was
THANKS
psWO-padfDstNoDataReal[i] = mxGetNaN();// ( mxGetNaN() -- a
Matlab API function)
Works fine now.
Joaquim
Read the error message again ;-) does not support direct output file
creation-- netCDF driver indeed only supports CreateCopy(), not Create()
(-- random access) which is required by gdalwarp.
The drivers that are supported as output driver for gdalwarp will have a '+'
in the output of gdalinfo --formats. Look at the difference betwenn GeoTIFF
and netCDF:
GTiff (rw+v): GeoTIFF
netCDF (rw): Network Common Data Format
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdalwarp's default nodata value
On 13-05-2010 18:38, Even Rouault wrote: Joaquim, For the rec, VS2010 and a quite recent trunk version. Ah, this is the reason for the different results we got. On Windows, atof(nan) returns 0... but on Linux it returns a nan number. I've pushed quite a few changes to trunk to improve the situation on Windows and other changes for all platforms to fix the case when we compare pixel values to nodata value and the nodata value is nan. Indeed, the test value == dfNoDataValue that was generally used fails if value == nan and dfNoDataValue == nan, because nan != nan... Oui, c'est le danger des nains Thanks for the info (and work of course) Joaquim ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Does anyone have built/compiled 64 bit versions of either FWTools or gdal
On 02-06-2010 16:39, John Mitchell wrote: Does anyone have built/compiled 64 bit versions of either FWTools or gdal for: a.) Windows 64 bit I do that +/- regularly on Win7 with VS2010. No problem at all. The main work was to compile all other libs that I link gdal with. Joaquim b.) Linux 64 bit Thanks, John ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] How to represent multi-dimensional array
Don't know if this is what you are looking for but if those netCDF files are of a similar type that one can get from the poet site (http://poet.jpl.nasa.gov/), Mirone has a tool called Aquamoto (a tool original developed to show time stamps of a tsunami propagation models) that loads those files and show their content interactively with the help of a slider. Joaquim Hi folks, I have a dataset that is a 4-dimensional array of values: time,x,y,z We're currently using netcdf to store it, which is well suited to this kind of data. However, we also need to get it into a GIS (Arc in this case), and I'm trying to find a good way to do that. Both Arc and gdalinfo do strange things if I simply point them at the netcdf file. GDAL seems to (arbitrarily?) see it as a 9064 band data set, so it is taking particular slice (I think I'm getting a bunch of (time, z) 2-d bands. Anyway, I suspect that if I re-arrange the axis in the netcdf file, I might get something more reasonable, but my question is: What is a good format to ex[press this to a GIS system? I'm imaging multiple files, maybe geo-tiff, but how to I express time and elevation in a way that is natural to GIS? thanks for your thoughts, -Chris ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Geotiff AREA_OR_POINT
On 28-06-2010 23:21, Michael Sumner wrote: Am I correct in interpreting this post to mean that the pixel-is-area and pixel-is-point tiffsare read the exact same way by GDAL, with the only difference being in the value of theAREA_OR_POINT metadata key? Should viewers then be looking forthe AREA_OR_POINT key in addition to the georeferencing information, and shift thedisplay to center the top-left pixel on (0,0) if it's set to Point? That's my understanding, it's just a metadata tag there for use if you need it. I would say that viewers should only modify their behaviour from Area if they have the distinction for centre point vs. cell based views. I've seen it used to set centre-based TIN-like renderings, vs. cell-based image renderings - but there's nothing in the GDAL raster storage model that prevents you taking on either interpretation AFAIK, though the default is cell-based. (There can be a problem interpreting more flexible array formats like NetCDF, that can store irregularly spaced coordinate vectors for, say, the centres of cells on the X axis - and there's rarely any metadata (in the file) to say explicitly that it's centre- not corner-based. ) Cheers, Mike. netCDF grids created by GMT have always (~20 years) made that distinction and store that information. Joaquim ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] vsizip vsigzip on Win
Hi, I'm trying to access ziped files on Windows using the /vsizip but it fails most of times According to docs, this should work no? gdalinfo c:/vsizip/m_gmt_so/tmp/N37W008.hgt.zip/N37W008.hgt but it doesn't. I get ERROR 4: `c:/vsizip/m_gmt_so/tmp/N37W008.hgt.zip/N37W008.hgt' does not exist in the file system, and is not recognised as a supported dataset name. However, I'm able to make it work by using the unix pathname syntax gdalinfo /vsizip/m_gmt_so/tmp/N37W008.hgt.zip/N37W008.hgt but even this only works when I run the command from the root dir, that is from C:\ If run it from any another location I get the same error message. Joaquim Luis ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] vsizip vsigzip on Win
Sorry for the noise. I found that the correct syntax is gdalinfo /vsizip/c:\m_gmt_so\tmp\N37W008.hgt.zip\N37W008.hgt and like that it works fine. Joaquim Hi, I'm trying to access ziped files on Windows using the /vsizip but it fails most of times According to docs, this should work no? gdalinfo c:/vsizip/m_gmt_so/tmp/N37W008.hgt.zip/N37W008.hgt but it doesn't. I get ERROR 4: `c:/vsizip/m_gmt_so/tmp/N37W008.hgt.zip/N37W008.hgt' does not exist in the file system, and is not recognised as a supported dataset name. However, I'm able to make it work by using the unix pathname syntax gdalinfo /vsizip/m_gmt_so/tmp/N37W008.hgt.zip/N37W008.hgt but even this only works when I run the command from the root dir, that is from C:\ If run it from any another location I get the same error message. 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
[gdal-dev] errors compiling r20250
Hi, I'm getting these compiling errors. I did build the trunk version from yesterday without any problem c:\programs\gdaltrunk\gdal\ogr\ogrsf_frmts\gml\gmlreaderp.h(274) : error C2143: syntax error : missing ';' before '*' c:\programs\gdaltrunk\gdal\ogr\ogrsf_frmts\gml\gmlreaderp.h(274) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int c:\programs\gdaltrunk\gdal\ogr\ogrsf_frmts\gml\gmlreaderp.h(274) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int c:\programs\gdaltrunk\gdal\ogr\ogrsf_frmts\gml\gmlreaderp.h(275) : error C2146: syntax error : missing ';' before identifier 'oParser' c:\programs\gdaltrunk\gdal\ogr\ogrsf_frmts\gml\gmlreaderp.h(275) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int c:\programs\gdaltrunk\gdal\ogr\ogrsf_frmts\gml\gmlreaderp.h(275) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int NMAKE : fatal error U1077: 'C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\BIN\cl.EXE' : return code '0x2' Joaquim ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Re: cut a .dem file
On 08-09-2010 16:38, Carmelo Terrasi wrote: Yes, you're right, if I need a portion I have to use that utility. Thank you so much Hermann, regards, Carmelo Not so simple. The problem will be that your bmp image is not referenced but the DEM is, so you'll need to find the correspondence between the (row,column) coordinates of the bmp image and the (x,y) coords of the model. That means referencing the image (bmp) to the grid (dem). Joaquim 2010/9/8 Hermann Peifer pei...@gmx.eu mailto:pei...@gmx.eu On 08/09/2010 15:26, Carmelo Terrasi wrote: Hello everybody, does anybody know how to cut a smaller dem file from another one??? I have my original file /terrain.dem /but my /image.bmp/ is smaller so I would cut a portion just to create another suitable dem file for my /image.bmp/ Is it possible to do it or am I off-board? Look at the -srcwin and -projwin options at http://gdal.org/gdal_translate.html Hermann ___ 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] KML binay?
Hi, Excuse if this is only marginally GDAlish. Anyone know if it is possible to create binary KML? I know about KMZ but that's not what I'm after. What I wanted is to try to use GE as visualizer of LIDAR data. That is, to go directly from LAS to KML (binary). Thanks Joaquim Luis ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Why not netCDF output?
Thanks Even, I think that's the second time you explain me that (sorry, an easy thing to forget), but the docs could be a bit clearer about this. For example *--formats* List all raster formats supported by this GDAL build (read-only and read-write) and exit. The format support is indicated as follows: 'ro' is read-only driver; 'rw' is read or write (ie. supports CreateCopy); 'rw+' is read, write and update (ie. supports Create). so I though the + was for updating A second point is that the command I used shows a bug in gdalwarp. In that the lixo.grd is a grid extracted from one the etopo_something (actually a regrid version created by me) saning [-180 180] [0 90] and the bug is that at dateline there is a stripe of nodata. Since the grid is too big to post in a ticket, can you please try to reproduce this? Joaquim Joaquim, The valid formats for the output of gdalwarp are formats that support the Create() method, not just the CreateCopy() method. This is indicated by (rw+) : the + indicates that Create() is supported. The difference between Create() and CreateCopy() is mainly that Create() allows writing of pixel data in random order, which is needed by gdalwarp. You can try in 2 steps : 1) gdalwarp -of VRT lixo.grd [other_options] temp.vrt 2) gdal_translate -of netCDF temp.vrt proj.grd Best regards, Even Hi While running this command gdalwarp -s_srs +proj=latlong -t_srs +proj=ortho +lon_0=-42 +lat_0=40 +ellps=WGS84 -of netCDF lixo.grd proj.grd I get Output driver `netCDF' not recognised or does not support direct output file creation. The following format drivers are configured (a format list where netCDF is not listed) but if I ask gdalwarp the list of formats, netCDF is listed there as (rw). Furthermore gdalwarp --format netCDF Format Details: Short Name: netCDF Long Name: Network Common Data Format Extension: nc Help Topic: frmt_netcdf.html Supports: CreateCopy() - Create dataset by copying another. ?? 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] Why not netCDF output?
On 27-09-2010 20:39, Even Rouault wrote: Le lundi 27 septembre 2010 21:20:02, Joaquim Luis a écrit : Thanks Even, I think that's the second time you explain me that (sorry, an easy thing to forget), but the docs could be a bit clearer about this. For example *--formats* List all raster formats supported by this GDAL build (read-only and read-write) and exit. The format support is indicated as follows: 'ro' is read-only driver; 'rw' is read or write (ie. supports CreateCopy); 'rw+' is read, write and update (ie. supports Create). so I though the + was for updating What would you suggest to be clearer ? Well, using your own words, and to not extend the wording too much. Something like ... 'rw+' is read, write and update (ie. supports Create). Note: The valid formats for the output of gdalwarp are formats that support the Create() method, not just the CreateCopy() method. Yes I reproduce it too. I managed to solve it by increasing the SAMPLE_STEPS warping option to 60 for example (input source is 5120 x 2560). See http://gdal.org/structGDALWarpOptions.html for more explanations gdalwarp world.tif -t_srs +proj=ortho +lon_0=-42 +lat_0=40 +ellps=WGS84 out.tif -overwrite -wo SAMPLE_STEPS=60 Thanks. It worked for me too. I have followed this issue that is recurrent here in different disguises. If it was easy to solve you guys would have done it long ago, but about a warning message when this problem arises? I mean, is there any doable way to detect a posteriori that the shit happened and the SAMPLE_STEPS can help clean it? Joaquim ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Why not netCDF output?
Yes, that's probably doable, but clearly not trivial. I add a hard time (look at how ugly/complicated the code now looks...) doing something similar in GDALSuggestedWarpOutput2() to guess the extent of the target extent when such discontinuities in the reprojection occur (and it probably doesn't solve 100% situations). Something similar (in spirit) would probably be needed in GDALWarpOperation::ComputeSourceWindow(). Yes, big it is and I confess that I didn't even try to comprehend what it does. But my suggestion was perhaps simpler (in mind). My idea was to just give a warning that a discontinuity had occurred and advise that the SAMPLE_STEPS can be of much help. And how to detect the discontinuity? Sure that's the key question, but on the current case the -180 and the 180 points should be coincident on the target grid, or at least very, very close (in terms of target grid steps). If they aren't ... ring the bell Well just a thought. Joaquim ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] building with PDF driver on Windows
Hi, I tried to build GDAL on Win with PDF support and CV2010 Well that's an adventure. Instructions on how to build poppler are completely absent (but there is on CMake list file that we may try to guess what's essential from the optional stuff). Building free type raised an error somewhere (something about an already defined INT32) Next, there was this error (easily fixed with a pair of '/') C:/programs/compa_libs/poppler\goo/gtypes.h(31) : error C2371: 'GBool' : redefinition; different bas ic types ..\..\port\cpl_port.h(169) : see declaration of 'GBool' But finally I stopped at the errors bellow. I see in the nmake.opt that it links also against liblcms-1.lib. I don't know this one but Google seams indicate that it is Little CMS (color management engine). Is that so? And the errors below are they explained by the fact that I'm not linking against this lib? Clearly, we need a bit more info on how build with PDF support. Thanks Joaquim 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(resolvexlinks.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 link /nologo /dll /INCLUDE:_OGRFeatureStylePuller /INCLUDE:_OSRValidate /INCLUDE:_OPTGetPr ojectionMethods /INCLUDE:_OGR_G_GetPointCount /INCLUDE:_OGRRegisterAll /INCLUDE:_gdalsimpleimagew...@36 /INCLUDE:_gdalreprojectim...@48 /INCLUDE:_gdalcomputemediancut...@32 /INCLUDE:_gdalditherrgb2...@28 /INCLUDE:_octnewcoordinatetransformat...@8 port\*.obj gcore\*.obj alg\*.obj frmts\o\*.obj ogr\ogrsf_frmts\ogrsf_frmts.lib ogr\ogr.lib C:\programs\compa_libs\hdf-4.2.5\compileds\vc10_32\lib\hm425m.lib C:\programs\compa_libs\hdf-4.2.5\compileds\vc10_32\lib\hd425m.lib Ws2_32.lib c:\programs\Geo_DSDK-7.0.0.2167\lib\Release_md\lti_dsdk_dll.lib advapi32.lib user32.lib C:\progs_cygw\netcdf-3.6.3\compileds\VC10_32\lib\libnetcdf.lib C:\programs\proj4\compileds\VC10_32\lib\proj_i.lib C:\programs\compa_libs\hdf5-1.8.4-patch1\compileds\vc10_32\dll\hdf5dll.lib C:\program s\compa_libs\curl-7.20.0\compileds\vc10_32/lib/libcurl_imp.lib wsock32.lib wldap32.lib winmm.lib C:\programs\compa_libs\poppler\buildVC2010_32\Release/poppler.lib C:\programs\compa_libs\freetype-2.4.3\objs\win32\vc2008\freetype243.lib advapi32.lib gdi32.lib gcore\Version.res /out:gdal17.dll /implib:gdal_i.lib Creating library gdal_i.lib and object gdal_i.exppdfdataset.obj : error LNK2019: unresolved external symbol public: void __thiscall PDFDoc::displayP ageSlice(class OutputDev *,int,double,double,int,int,int,int,int,int,int,int,int (__cdecl*)(void *), void *,int (__cdecl*)(class Annot *,void *),void *) (?displaypagesl...@pdfdoc@@QAEXPAVOutputDev@@HN np6ah...@z1p6ahpavannot@@1...@z1@Z) referenced in function public: virtual enum CPLErr __thisc all PDFRasterBand::IReadBlock(int,int,void *) (?ireadbl...@pdfrasterband@@UAE?AW4CPLErr@@hh...@z) pdfdataset.obj : error LNK2019: unresolved external symbol public: __thiscall SplashOutputDev::SplashOutputDev(enum SplashColorMode,int,int,unsigned char *,int,int) (??0SplashOutputDev@@q...@w4splashcolormode@@hhpa...@z) referenced in function public: virtual enum CPLErr __thiscall PDFRasterBand:: IReadBlock(int,int,void *) (?ireadbl...@pdfrasterband@@UAE?AW4CPLErr@@hh...@z) gdal17.dll : fatal error LNK1120: 2 unresolved externals NMAKE : fatal error U1077: 'C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\BIN\link.EXE' : return code '0x460' ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] building with PDF driver on Windows
On 14-10-2010 18:32, Even Rouault wrote: Le jeudi 14 octobre 2010 17:01:06, Joaquim Luis a écrit : Hi, I tried to build GDAL on Win with PDF support and CV2010 Well that's an adventure. I trust you and didn't even try this way. Instead I just downloaded the kde-win32 installer, used the packager mode (or whatever it is called. I'm just quoting from my memory of doing this a few weeks ago), and selected the poppler, freetype and lcms packages and their developement packages. The only requirement for GDAL is poppler, freetype and lcms appears to be poppler requirements on this KDE build. But those lib only work with MSVC 2008 if I remember. Even, Hmm, on a further check those symbols are from poppler so it's not a lcms fault. I get another error building poppler referring iconv.h that I ignore either but selected as a no dependency in CMake, but this affect the creation of a poppler-cpp.lib, not poppler.lib so I'm not sure it relates to the GDAL error. I would like to build these dependencies myself because: 1. I don't want to use anything that dares to create manifests dependencies 2. I want to be able to build 64 bits versions too. Anyway, I found these warnings too that are unrelated to this PDF driver issue json_util.c json_util.c(62) : warning C4013: 'open' undefined; assuming extern returning int json_util.c(71) : warning C4013: 'read' undefined; assuming extern returning int json_util.c(74) : warning C4013: 'close' undefined; assuming extern returning int json_util.c(109) : warning C4013: 'write' undefined; assuming extern returning int ogrsf_frmts.lib(resolvexlinks.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 and many blabla ... possible loss of data warnings. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] building with PDF driver on Windows + ?
Thanks, this is obsolete now. I've just removed that. This dates back to when KMLSUPEROVERLAY needed external minizip. Now minizip has been imported in GDAL source tree and this is no longer needed. Nice. So I got two for the price of one. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] building with PDF driver on Windows + ?
Brent, From memory, as I don't find the CMake cash with exact details. I first built freetype, which I think is mandatory, and than because I already had them built but don't know if they are a must-be, I added also zlib, jpeg to the CMake list. My first error was to not select 'splash' because I didn't know what it was but it's part of poppler and needs to be selected. I did not include any Qt stuff and probably some other. Once it is built (I used only VC2010) there is the mess of the includes. You will need to include the root directory where the whole poppler tree lives, plus that ../poppler plus still one other dir that holds only one .h file. I moved that .h to one of the other places and now use this (my names) in nmake.opt POPPLER_CFLAGS = -IC:/programs/compa_libs -IC:/programs/compa_libs/poppler Good luck Joaquim I'm about to embark on compiling Poppler on Windows to get Geospatial PDF support in GDAL. Any recommendations with respect to compiler version, dependencies, CMake options, etc? Thanks! Brent Fraser On 10/14/2010 3:23 PM, Joaquim Luis wrote: Did I mention before that the propeller (sorry, poppler) doesn't have any building instructions for Windows? Well, the CMakeLists.txt is incomplete and does not add the contents of the splash directory to the project. After adding all *.cc from 'splash' to project, GDAL is happy with the poppler.lib and now gdalinfo says ... KMLSUPEROVERLAY (rw): Kml Super Overlay XYZ (rwv): ASCII Gridded XYZ HF2 (rwv): HF2/HFZ heightfield raster PDF (rov): Geospatial PDF but I'm now confused with the presence of the KMLSUPEROVERLAY because my nmake.opt has # Uncomment out the following to enable KML Super-Overlay support. #KMLSUPEROVERLAY_SUPPORTED = YES #MINIZIP_INCLUDE = -I$(OSSIM_HOME)\minizip\src #MINIZIP_LIBRARY = $(OSSIM_HOME)\minizip\release\minizip.lib Not complaining. Just reporting. Joaquim On 14-10-2010 18:32, Even Rouault wrote: Le jeudi 14 octobre 2010 17:01:06, Joaquim Luis a écrit : Hi, I tried to build GDAL on Win with PDF support and CV2010 Well that's an adventure. I trust you and didn't even try this way. Instead I just downloaded the kde-win32 installer, used the packager mode (or whatever it is called. I'm just quoting from my memory of doing this a few weeks ago), and selected the poppler, freetype and lcms packages and their developement packages. The only requirement for GDAL is poppler, freetype and lcms appears to be poppler requirements on this KDE build. But those lib only work with MSVC 2008 if I remember. Even, Hmm, on a further check those symbols are from poppler so it's not a lcms fault. I get another error building poppler referring iconv.h that I ignore either but selected as a no dependency in CMake, but this affect the creation of a poppler-cpp.lib, not poppler.lib so I'm not sure it relates to the GDAL error. I would like to build these dependencies myself because: 1. I don't want to use anything that dares to create manifests dependencies 2. I want to be able to build 64 bits versions too. Anyway, I found these warnings too that are unrelated to this PDF driver issue json_util.c json_util.c(62) : warning C4013: 'open' undefined; assuming extern returning int json_util.c(71) : warning C4013: 'read' undefined; assuming extern returning int json_util.c(74) : warning C4013: 'close' undefined; assuming extern returning int json_util.c(109) : warning C4013: 'write' undefined; assuming extern returning int ogrsf_frmts.lib(resolvexlinks.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 and many blabla ... possible loss of data warnings. ___ 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] building with PDF driver on Windows + ?
On 17-10-2010 19:24, Brent Fraser wrote: Joaquim, Many thanks for the info. I may go the kde-win32 route for now to skip the building of poppler.lib, but I expect that eventually I may need to build it from source, especially for mapserver. Right, and From memory, as I don't find the CMake cash with exact details. obviously I meant cache not cash ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] building with PDF driver on Windows + ?
Tamas, I didn't notice that but on the other hand I never run it enough times to make it happen. Joaquim Hi poppler gurus, I've also compiled poppler.lib (version 0.14.4) with various versions of MSVC, but it seems to generate double free memory corruptions in gdal. A single run of pdf.py (from the autotest suite) seems to complete successfully, however running the script multiple times (in a batch) could eventually generate a crash. Has anyone run into the same issue? Best regards, Tamas 2010/10/17 Joaquim Luis jl...@ualg.pt mailto:jl...@ualg.pt On 17-10-2010 19:24, Brent Fraser wrote: Joaquim, Many thanks for the info. I may go the kde-win32 route for now to skip the building of poppler.lib, but I expect that eventually I may need to build it from source, especially for mapserver. Right, and From memory, as I don't find the CMake cash with exact details. obviously I meant cache not cash ___ gdal-dev mailing list gdal-dev@lists.osgeo.org mailto: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] gdaldem color-relief color_text_files
Now that the ability to read GMT .cpt palettes was added to trunk I'll make a little advertise on the Mirone's Color Palette tool. It has over a hundred internal color scales and one can manipulate each one of them with lifter and/or click-and-drags. At the end, the color scale can be exported as continuous or discrete GMT palettes. It looks like this http://w3.ualg.pt/~jluis/mirone/files/ChangePalette2.html Joaquim This isn't quite what you need, but for creating thematic colour schemes, http://colorbrewer2.org/ is a rather neat tool. I suppose it wouldn't be too much of a stretch to interpolate between the colours it generates for a full 256 pallette. -JD From: gdal-dev-boun...@lists.osgeo.org [mailto:gdal-dev-boun...@lists.osgeo.org] On Behalf Of Mark Millman Sent: 15 October 2010 01:17 To: gdal-dev@lists.osgeo.org Subject: [gdal-dev] gdaldem color-relief color_text_files I am in need of some color_text files to use with the gdaldem color-relief utility to create color relief versions of Slope, Aspect, Roughness, TRI, TPI maps. I seems to me that these ought to be pretty standard and as my skill set is on the developer side rather than the cartographer side of things I am hoping that some generous cartographer out there has already created some eye candy quality color_text_files for this purpose. Thanks in advance. Mark __ This email has been scanned for Virtalis Ltd by the MessageLabs Email Security System. __ ... ___ 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] gdaldem color-relief color_text_files
Even, Thanks. It was when I wrote it long time ago. Now fixed. Joaquim, by the way the link to GDAL on Mirone home page (http://w3.ualg.pt/~jluis/mirone) is broken. It should point to http://gdal.org and not to http://remotesensing.org/gdal Le mardi 19 octobre 2010 12:08:14, Joaquim Luis a écrit : Now that the ability to read GMT .cpt palettes was added to trunk I'll make a little advertise on the Mirone's Color Palette tool. It has over a hundred internal color scales and one can manipulate each one of them with lifter and/or click-and-drags. At the end, the color scale can be exported as continuous or discrete GMT palettes. It looks like this http://w3.ualg.pt/~jluis/mirone/files/ChangePalette2.html Joaquim This isn't quite what you need, but for creating thematic colour schemes, http://colorbrewer2.org/ is a rather neat tool. I suppose it wouldn't be too much of a stretch to interpolate between the colours it generates for a full 256 pallette. -JD From: gdal-dev-boun...@lists.osgeo.org [mailto:gdal-dev-boun...@lists.osgeo.org] On Behalf Of Mark Millman Sent: 15 October 2010 01:17 To: gdal-dev@lists.osgeo.org Subject: [gdal-dev] gdaldem color-relief color_text_files I am in need of some color_text files to use with the gdaldem color-relief utility to create color relief versions of Slope, Aspect, Roughness, TRI, TPI maps. I seems to me that these ought to be pretty standard and as my skill set is on the developer side rather than the cartographer side of things I am hoping that some generous cartographer out there has already created some eye candy quality color_text_files for this purpose. Thanks in advance. Mark __ This email has been scanned for Virtalis Ltd by the MessageLabs Email Security System. __ ... ___ 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 mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdalinfo and scale/offset
Kyle,
Yes, that is much better but (sorry for one other 'but') what about
formats that do not know anything about scale/offset?
(Surfer format is one comes right to my mind)
In those cases conversion would definitively go wrong. Issue a
screaming warning in than?
Joaquim
Joaquim,
With my code I wrote today, the offset and scale are set on the
GDALRasterBand itself. If I do the following:
gdal_translate lixo.grd lixo.tif
gdalinfo lixo.tif -mm
I get:
Driver: GTiff/GeoTIFF
Files: lixo.tif
lixo.tif.aux.xml
Size is 21, 21
Coordinate System is `'
Origin = (-10.500,10.500)
Pixel Size = (1.000,-1.000)
Metadata:
NC_GLOBAL#Conventions=COARDS/CF-1.0
NC_GLOBAL#title=lixo.grd
NC_GLOBAL#history=grdmath -R-10/10/-10/10 -I1 X Y MUL = lixo.grd
NC_GLOBAL#GMT_version=4.5.4
z#long_name=z
z#_FillValue=nan
z#actual_range=-1, 1
z#scale_factor=0.01
x#long_name=x
x#actual_range=-10, 10
y#long_name=y
y#actual_range=-10, 10
Image Structure Metadata:
INTERLEAVE=BAND
Corner Coordinates:
Upper Left ( -10.500, 10.500)
Lower Left ( -10.500, -10.500)
Upper Right ( 10.500, 10.500)
Lower Right ( 10.500, -10.500)
Center ( 0.000, 0.000)
Band 1 Block=21x21 Type=Float32, ColorInterp=Gray
Computed Min/Max=-100.000,100.000
NoData Value=nan
Offset: 0, Scale:0.01
Metadata:
NETCDF_VARNAME=z
where you can see the offset and scale reported at the band level.
This is not just metadata anymore, it belongs to GDALRasterBand.
if I run:
gdal_translate -unscale lixo.grd lixo_uscale.tif
gdalinfo -mm lixo_unscale.tif
Files: lixo_uscale.tif
lixo_uscale.tif.aux.xml
Size is 21, 21
Coordinate System is `'
Origin = (-10.500,10.500)
Pixel Size = (1.000,-1.000)
Metadata:
NC_GLOBAL#Conventions=COARDS/CF-1.0
NC_GLOBAL#title=lixo.grd
NC_GLOBAL#history=grdmath -R-10/10/-10/10 -I1 X Y MUL = lixo.grd
NC_GLOBAL#GMT_version=4.5.4
z#long_name=z
z#_FillValue=nan
z#actual_range=-1, 1
z#scale_factor=0.01
x#long_name=x
x#actual_range=-10, 10
y#long_name=y
y#actual_range=-10, 10
Image Structure Metadata:
INTERLEAVE=BAND
Corner Coordinates:
Upper Left ( -10.500, 10.500)
Lower Left ( -10.500, -10.500)
Upper Right ( 10.500, 10.500)
Lower Right ( 10.500, -10.500)
Center ( 0.000, 0.000)
Band 1 Block=21x21 Type=Float32, ColorInterp=Gray
Computed Min/Max=-1.000,1.000
NoData Value=nan
Metadata:
NETCDF_VARNAME=z
The data in the tif is unscaled or unpacked.
I don't know if this is clear, I apologize for all the snippets. I,
like Even, have no strong feelings for gdalinfo reporting
scaled/unscaled data.
kss
#
Kyle Shannon
Physical Science Technician
RMRS Fire Sciences Lab
Fire, Fuels Smoke - RWU 4405
5775 Highway 10 W.
Missoula, MT 59808
(406)829-6954
kshan...@fs.fed.us mailto:kshan...@fs.fed.us
#
On Thu, Oct 28, 2010 at 12:35 PM, Joaquim Luis jl...@ualg.pt
mailto:jl...@ualg.pt wrote:
Even
Thanks for pointing into this that I was not aware of as it would
be the main point of my answer to Kyle's question.
But still, as it is referred in the ticket (sorry for lousy
formatting but I never learn how to do it better) the main issue
occurred in the conversion to another format (geotiff for that
matter). So though an option exists ('unscale') to account for
offset/scale the natural expectancy is that the conversion does
not change the data values.
Redoing the tickets example we can see (not shown than because I
thought it of lesser interest)
C:\SVN\mironeWC\src_C\tgdalinfo lixo.tiff -mm
Driver: GTiff/GeoTIFF
Files: lixo.tiff
Size is 21, 21
Coordinate System is `'
Origin = (-10.500,10.500)
Pixel Size = (1.000,-1.000)
Metadata:
NC_GLOBAL#Conventions=COARDS/CF-1.0
NC_GLOBAL#title=lixo.grd
NC_GLOBAL#history=grdmath -R-10/10/-10/10 -I1 X Y MUL = lixo.grd
NC_GLOBAL#GMT_version=4.5.4
z#long_name=z
z#_FillValue=1.#QNAN0e+000
z#actual_range=-1, 1
z#scale_factor=0.01
x#long_name=x
x#actual_range=-10, 10
y#long_name=y
y#actual_range=-10, 10
Image Structure Metadata:
INTERLEAVE=BAND
Corner Coordinates:
Upper Left ( -10.500, 10.500)
Lower Left ( -10.500, -10.500)
Upper Right ( 10.500, 10.500)
Lower Right ( 10.500, -10.500)
Center ( 0.000, 0.000)
Band 1 Block=21x21 Type=Float32, ColorInterp=Gray
Computed Min/Max=-100.000,100.000
It's true that we can still see a trace of the previous info about
the scale
z#actual_range=-1, 1
z#scale_factor=0.01
but a user would need to be very very attentive to realize
[gdal-dev] GMT5-alpha available
People, This info may interest this community of programmers. The alpha version of the next generation of GMT is now available (CVS only). High-level GMT functionality is now accessible via GMT modules callable from C/C++. For more information, please visit gmt.soest.hawaii.edu/5 Joaquim Luis ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Something is broken on Win install
Hi, After compiling everything in trunk with no problems the devinstall step stops with ... C:\programs\GDALtrunk\gdal\frmtscd ecw nmake /nologo /f makefile.vc plugin cd .. || exit 1 cd .. cd apps nmake /nologo /f makefile.vc cd .. mkdir ..\WIN64\bin mkdir C:\programs\GDALtrunk\gdal\compileds\VC10_64\data A subdirectory or file C:\programs\GDALtrunk\gdal\compileds\VC10_64\data already exists. xcopy /y /r /d /f gdal17.dll ..\WIN64\bin C:\programs\GDALtrunk\gdal\gdal17.dll - C:\programs\GDALtrunk\WIN64\bin\gdal17.dll 1 File(s) copied cd frmts nmake /nologo /f makefile.vc plugins-install for %d in ( ecw ) do cd %d nmake /nologo /f makefile.vc plugin-install cd .. || exit 1 C:\programs\GDALtrunk\gdal\frmtscd ecw nmake /nologo /f makefile.vc plugin-install cd .. || exit 1 mkdir ..\WIN64\bin\gdalplugins A subdirectory or file ..\WIN64\bin\gdalplugins already exists. xcopy /y /r /d /f gdal_ECW_JP2ECW.dll ..\WIN64\bin\gdalplugins 0 File(s) copied cd ..\apps nmake /nologo /f makefile.vc install copy *.exe ..\WIN64\bin gdaladdo.exe The system cannot find the path specified. 0 file(s) copied. NMAKE : fatal error U1077: 'copy' : return code '0x1' Stop. The problem seams to be that it's trying to put things in ..\WIN64\bin which I never told it to do. My nmake.opt has !IFDEF WIN64 GDAL_HOME = C:\programs\GDALtrunk\gdal\compileds\VC10_64 !ELSE !IF $(MSVC_VER) = 1600 GDAL_HOME = C:\programs\GDALtrunk\gdal\compileds\VC10_32 ... So everything should go inside C:\programs\GDALtrunk\gdal\compileds\VC10_64\... as they used to do until today. Joaquim ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Something is broken on Win install
On 13-11-2010 18:02, Frank Warmerdam wrote: Joaquim Luis wrote: cd ..\apps nmake /nologo /f makefile.vc install copy *.exe ..\WIN64\bin gdaladdo.exe The system cannot find the path specified. 0 file(s) copied. NMAKE : fatal error U1077: 'copy' : return code '0x1' Stop. The problem seams to be that it's trying to put things in ..\WIN64\bin which I never told it to do. My nmake.opt has !IFDEF WIN64 GDAL_HOME = C:\programs\GDALtrunk\gdal\compileds\VC10_64 !ELSE !IF $(MSVC_VER) = 1600 GDAL_HOME = C:\programs\GDALtrunk\gdal\compileds\VC10_32 ... Joaquim, I don't know why this is happening in your case. I tried a clean build and install on windows (32 bit) from trunk and had no problem. Best regards, Frank, I found it. I had just rebuild GMT on the same command window and it looks that I had a variablr name contamination from the GMT build. Starting with a new command window worked fine again. Sorry for the noise. Joaquim ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Frank Eats Crow - or Fixing PixelIsPoint Interpretation
Frank, Wouldn't this apply to the netCDF grids as well? GMT has always made the distinction on the area vs point representation. The grids created by GMT hold that information on the global attribute node_offset. As for other netCDF CF grids created elsewhere it is also possible to find which model is used by checking the grid limits vs array size because for the same limits the PixelIsArea model has one less row and column than the PixelIsPoint. Joaquim Folks, After 15 years of denial, and bullheadedness it is now time for me to admit my interpretation of PixelIsPoint in GeoTIFF files is wrong. To that end I have prepared a brief RFC discussing how I intend to fix it. I'd appreciate comment before calling for a vote. http://trac.osgeo.org/gdal/wiki/rfc33_gtiff_pixelispoint Mmmm, crow - it tastes just like chicken! Best regards, ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Frank Eats Crow - or Fixing PixelIsPoint Interpretation
On 16-11-2010 15:54, Frank Warmerdam wrote: Ivan Lucena wrote: Frank, Although I agree with your answer to Joaquim's question I would like to extend the subject a little bit. If I understood the RFC33 correctly the CreateCopy()'s of others driver will not going to fell the effect of that change. I mean, the GeoTransform will still be based on the center of the pixel. That is good. But for the sake of data quality, for driver/formats that support both reference modes, I believe it will be important to carry away that information to the output. If you take the outputted raster and use it in surface analysis or 3D visualization packages it will be better to know where the pixel reference really is. Right? IMHO, for those driver, including GTIFF itself, would be nice to know what was the pixel reference of the source dataset in order to make a decision to write reference in a PixelIsPoint or PixelIsArea fashion. should we establish some automatic and standard way of dealing with that? Ivan, In fact, I strongly disagree with conflating the sampling technique of the sensor (area average vs. point sample) with the georeferencing. And for formats that can store the georeferencing based on either a top left corner of top left pixel vs. a center of top left pixel form, I see no value in distinguishing them. There is no real significance. So, in my opinion, the only reason we might consider doing something with the GMT driver at this point is if we decide that the node_offset is really intended to indicate something about the sampling nature of the sensor. If so, we might want to set it based on the AREA_OR_POINT metadata on write and set the AREA_OR_POINT metadata on read. I don't know enough about the GMT format to know if there is intended to be some physical significance to the node_offset setting. I will note that the AREA_OR_POINT metadata item is already well defined in the GDAL Data Model document. It says: AREA_OR_POINT: May be either Area (the default) or Point. Indicates whether a pixel value should be assumed to represent a sampling over the region of the pixel or a point sample at the center of the pixel. This is not intended to influence interpretation of georeferencing which remains area oriented. Frank, Ivan I was not sure that my question was 100% related to this RFC but I guess my reasoning (a bit like Ivan) is, if it is acknowledged that GeoTiff can have both models why that information is not carried on when converting to other formats that also distinguish between Area vs Point? I cannot answer to the question if there is any particular physical meaning on the PixelIsPoint representation (which in GMT is represented by node_offset = 0). Maybe not or maybe yes. The thing is many people can create netCDF grids with different softwares. Regarding this point, we should not be talking specifically on the GMT driver because it deals with the old and deprecated format. Now GMT creates only netCDF CF files (which are dealt with the generic netCDF format). Joaquim ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] ECMWF's GRIBs and NetCDFs
On 30-11-2010 15:03, António Rocha wrote: Hi I'm using ECMWF's GRIB files and, I realized that there is a small error in geolocation (that can be fixed with gdal_translate). But, since I changed to winGRASS (that uses gdal1.5) I'm not able to use ECMWF's GRIB. Since ECMWF's data is also provided in NetCDF, I would like to know if there is any known issue on using NetCDF data in GDAL1.5? (I didn't find anything). António, A few http://trac.osgeo.org/gdal/ticket/1672 http://trac.osgeo.org/gdal/ticket/3797 but probably the most important one (the flip up-down issue) http://trac.osgeo.org/gdal/ticket/3575 Joaquim Thanks Antonio R. __ Information from ESET NOD32 Antivirus, version of virus signature database 5661 (20101130) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.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] Re: OpenCL, GDAL, and You
Hi, Gave this a try on Windows (relatively simple to build) with CUDA and indeed the difference in speed is big. Petty that the result is quite broken. My test was with this projection gdalwarp -t_srs +proj=sinu mundo.tiff lixo32.tiff Joaquim I'm working on the trunk OpenCL build on my Mac now. ** First, on my mac I get an error at the end of make: [...] ./ogr/.libs/ogr_srs_xml.o ./ogr/.libs/ograssemblepolygon.o ./ogr/.libs/ogr2gmlgeometry.o ./ogr/.libs/gml2ogrgeometry.o ./ogr/.libs/ogr_expat.o /opt/local/lib/libsqlite3.dylib -L/opt/local/lib -L/usr/local/lib /usr/local/lib/libexpat.dylib /usr/local/lib/libjpeg.dylib /usr/local/lib/libtiff.dylib /usr/local/lib/libpng12.dylib -lpthread -ldl /opt/local/lib/libcurl.dylib /opt/local/lib/libidn.dylib -lssl -lcrypto -lz -lOpenCL-install_name /usr/local/lib/libgdal.1.dylib -compatibility_version 16 -current_version 16.0 -Wl,-single_module ld: library not found for -lOpenCL collect2: ld returned 1 exit status make[1]: *** [libgdal.la] Error 1 make: *** [check-lib] Error 2 seth:gdal-svn-trunk-2010.12.17 sprice$ To fix this, I changed OPENCL_LIB = -lOpenCL to OPENCL_LIB = -framework OpenCL in GDALMmake.opt. * Why is USE_CLAMP_TO_DST_FLOAT in there? I would think that is required even if it isn't on ATI. I'm not sure who inserted its use, but I'm just wondering if the reasoning is documented somewhere. * I had to make this change to alg/gdalwarpkernel_opencl.c to get it to build without a build option error. @@ -1168,7 +1168,7 @@ //Assemble the compiler arg string for speed. All invariants should be defined here. sprintf(buffer, -cl-fast-relaxed-math -Werror -D FALSE=0 -D TRUE=1 -%s +%s -D iSrcWidth=%d -D iSrcHeight=%d -D iDstWidth=%d -D iDstHeight=%d -D useUnifiedSrcDensity=%d -D useUnifiedSrcValid=%d -D useDstDensity=%d -D useDstValid=%d -D useImag=%d @@ -1176,9 +1176,9 @@ -D nXRadius=%d -D nYRadius=%d -D nFiltInitX=%d -D nFiltInitY=%d -D PI=%015.15lff -D outType=%s -D dstMinVal=%015.15lff -D dstMaxVal=%015.15lff -D useDstNoDataReal=%d -D vecf=%s %s -D doCubicSpline=%d --D useUseBandSrcValid=%d -D iCoordMult=%d, +-D useUseBandSrcValid=%d -D iCoordMult=%d , /* FIXME: Is it really a ATI specific thing ? */ -(warper-imageFormat == CL_FLOAT warper-bIsATI) ? -D USE_CLAMP_TO_DST_FLOAT=1 : , +(warper-imageFormat == CL_FLOAT warper-bIsATI) ? -D USE_CLAMP_TO_DST_FLOAT=1 : , warper-srcWidth, warper-srcHeight, warper-dstWidth, warper-dstHeight, warper-useUnifiedSrcDensity, warper-useUnifiedSrcValid, warper-useDstDensity, warper-useDstValid, warper-imagWorkCL != NULL, After doing all of the above to make things compile, I don't get the bug described below. I'm working off of the latest trunk daily. ~Seth On Dec 8, 2010, at 1:12 PM, Even Rouault wrote: Seth, Thanks for your help. It's more than a little strange that none of those image sizes work. Perhaps it's a problem with the image format? Can you verify that the given format should work? The image format was CL_UNORM_INT8 (for GDT_Byte) Looking at the spec, it might also be a problem with the 'sz' argument. What value is that passing? It's 1. I managed to found the following workaround that enables gdalwarp to complete (see http://trac.osgeo.org/gdal/changeset/21220 that basically passes a dummy buffer instead of a NULL pointer). However the visual result of the warping is really poor. I see 4 ghost images shifted. For better understanding I've attached the source image (small_world_b1.tif) and the result of bilinear resampling (but I get similar weird visual effects with cubic, cubic spline or lanczos) gdalwarp -rb small_world_b1.tif out_bilinear.tif Best regards, Even small_world_b1.tifout_bilinear.tif ___ 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: Fwd: Re: [gdal-dev] FWTools and GDAL 1.7.0
On 06-01-2011 21:42, Christopher Barker wrote: On 1/6/11 12:31 PM, Jason Roberts wrote: Here are some comments on specific parts of your mail: Program Files\GDAL\1.6\gdal.dll and Program Files\GDAL\1.6\gdal.dll Those would be reasonable locations for GDAL to live if the GDAL team decided to distribute the GDAL binaries using an installer that adhered to the best practices on Windows. I *think* we're heading for a consensus to do that, but not many people have been on this thread. Hi, I have been following this with attention and sometimes I thought I had something to say but than it has many python specific issues, which I'm not versed at all. My experience with other installers is GMT Mirone. Here I simply put the gdal dll and ALL its dependencies (determined by careful Dependency Walker analysis) in the same directory as the other exes. Since this must be in the PATH, the gdal package goes along. But this solution normally doesn't care about the gdal exes. Also a word about the best practice on Windows. I really don't see anything not even good in that practice to put them in Program Files. Having directories with blanks in their name give nothing but future problems when running command line programs (I have seen that happen many times). The GMT Mirone installs propose as default a C:\programs diectory. Let me remember that Program Files is not a unique name. For example in Portugues Win versions it is called O Meus Programas (Horror). Remember also that MS used to have Documents and Settings but now on Win7 it's only Users. Incidentally, Windows does support both symbolic and hard links, although it is not widely known, and I'm not sure I'd recommend their use for this particular problem. I've heard that, but never seen it done. It works pretty well, the command is mklink and works much like on *nix BUT exists only on Vista and Win7. Time to time, it has been raised also the hypothesis to put the dlls in windowes\system32. PLEASE, PLEASE don't even think on that. It's the easiest way of making the worst dll-hell. I learned that after spending many hours trying to understand why GDAL was not working in the classroom computers. It turned out to be an very old zlib1.dll put there by ArcS* Joaquim ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: Fwd: Re: [gdal-dev] FWTools and GDAL 1.7.0
Perhaps that's why the standard place for Python is NOT in Program Files Yes, there is wisdom. That being said, Program Files does seem to work fine for me most of the time. And for the (1 - most) times that it didn't work you knew how to fix it (enclosing the full path with ) but many people don't know it. By the way, isn't there some new stuff about side by side installs or something -- that's supposed to help dll hell? I think you are referring to the manifests but here also MS has changed their mind (aleluia). VC2010 doesn't have them anymore which IMO is a compelling reason to use this compiler whenever possible. Joaquim ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: Fwd: Re: [gdal-dev] FWTools and GDAL 1.7.0
On 07-01-2011 15:07, Jason Roberts wrote: Tamas, WIX looks like a great technology for building the installation package. I've never used it but I took a quick look and it seems to provide what is needed. As I understand it, you are pondering whether it would be better to have GDAL in Program Files\OSGeo\GDAL or in Program Files\GDAL. Is it simply a question aesthetics or principle, in which it seems proper to put all OSgeo projects under Program Files\OSGeo, but there could be problems coordinating the efforts of multiple projects to adhere to that carefully and not mash each other's files? If that summarizes the issue, then I'd recommend going with the more practical, less principled approach: put GDAL in Program Files\GDAL, and OSGeo4W in Program Files\OSGeo4W. It could get messy if both installers have to be able to create the Program Files\OSGeo directory but not necessarily delete it when they are uninstalled, because there could be another OSGeo project in there. Let me just recall that OSGeo4W proposes the default install directory as C:\OSGeo4W This is just my opinion and I feel quite at rest because I'm able to build GDAL and install it wherever I wont, but I would really hate that an installer would force me to install in a location contrary to my will. In particular when that location has blanks in the name (Program Files). But, as I said it's just my private view. Joaquim ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Modis L1B SWATH: georef problem hdf to geotiff
Anna, I wonder how ENVI does the warping and if there isn't any hidden trick that must be applied. I did the warping in Mirone where I can choose to do a gdalwarp or warping using a totally independent code (from Matlab) and the results are equal and ... wrong. Joaquim hi all, excuse me for not giving up. i undertook some additional tests, and i got the same problems i described below. But i can't believe that nobody is working with gdal and modis level 1b data. At least this format is listet as supported at http://www.gdal.org/frmt_hdf4.html. So my question: does anybody in this list work with modis level 1b? If yes, is the georeference of the resulting image ok or does somebody knows an workaround? maybe the answer is, that it is not possible to warp modis level 1b data with gdal because the modis geolocation (mod3xxx) file is missing? i appreciate any help. cheers anna *Von:* Chaitanya kumar CH chaitanya...@gmail.com *Gesendet:* 19.01.2011 10:13:49 *An:* anna auge annaa...@web.de *Betreff:* Re: [gdal-dev] Modis L1B SWATH: georef problem hdf to geotiff Anna, Check a couple of GCPs to rule out bad data. If they are OK, file a ticket at http://trac.osgeo.org/gdal/newticket On Wed, Jan 19, 2011 at 1:23 PM, anna auge annaa...@web.de mailto:annaa...@web.de wrote: So it is a problem with gdalwarp and the GCPs ín the GeoTiff. Do you have any hints how to go on with this problem? Cheers, Anna *Von:* Nikolaos Hatzopoulos nhat...@gmail.com mailto:nhat...@gmail.com *Gesendet:* 19.01.2011 01:33:43 *An:* anna auge annaa...@web.de mailto:annaa...@web.de *Betreff:* Re: [gdal-dev] Modis L1B SWATH: georef problem hdf to geotiff You are right, I notice that there isn't any difference from the band_1.tiff and band_1_warp.tiff --Nikos Hatzopoulos On Mon, Jan 17, 2011 at 8:15 AM, anna auge annaa...@web.de mailto:annaa...@web.de wrote: Hi all, I am trying to convert modis level 1B data (type SWATH) to geotiff following these steps. 1) Examining the HDF gdalinfo d:\modis\1b\MOD021KM.A2011008.0850.005.2011008195744.hdf gdalinfo HDF4_EOS:EOS_SWATH:d:\modis\1b\MOD021KM.A2011008.0850.005.2011008195744.hdf:MODIS_SWATH_Type_L1B:EV_1KM_RefSB 2) Extracting the 1. band of the subdataset MODIS_SWATH_Type_L1B:EV_1KM_RefSB gdal_translate -of GTiff -b 1 HDF4_EOS:EOS_SWATH:d:\modis\1b\MOD021KM.A2011008.0850.005.2011008195744.hdf:MODIS_SWATH_Type_L1B:EV_1KM_RefSB d:\modis\1b\band_1.tiff 4) Warping the image to WGS84 gdalwarp -t_srs EPSG:4326 d:\modis\1b\band_1.tiff d:\modis\1b\band_1_warp.tiff The example dataset, which i am using, can be downloaded here ftp://ladsftp.nascom.nasa.gov/allData/5/MOD021KM/2011/008//MOD021KM.A2011008.0850.005.2011008195744.hdf And now to my problem: I get always an certain shift (http://www.flickr.com/photos/54033867@N00/5363471425/in/photostream/), which is avoided if i am using the Georeference MODIS option in ENVI (http://www.flickr.com/photos/54033867@N00/5364083966/in/photostream/). I also tried a few workarounds, f.g. http://thread.gmane.org/gmane.comp.gis.gdal.devel/10482, but nothing worked properly. As far as I understand gdal supports Modis L1B SWATH, so what I am doing wrong? Any help is appreciated. Regards Anna P.S. I am using FWTools 2.4.7 on Windows WEB.DE http://WEB.DE DSL Doppel-Flat ab 19,99 €/mtl.! Jetzt mit gratis Handy-Flat! *http://produkte.web.de/go/DSL_Doppel_Flatrate/2* ___ gdal-dev mailing list gdal-dev@lists.osgeo.org mailto:gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev NEU: FreePhone - kostenlos mobil telefonieren und surfen! Jetzt informieren: *http://produkte.web.de/go/webdefreephone* ___ gdal-dev mailing list gdal-dev@lists.osgeo.org mailto:gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- Best regards, Chaitanya kumar CH. /tʃaɪθənjə/ /kʊmɑr/
[gdal-dev] Fail to build with OpenJpeg
Hi, My attempt to build gdal (trunk) on Windows with OpenJpeg failed with these errors C:\programs\GDALtrunk\gdal\frmtscd openjpeg nmake /nologo /f makefile.vc cd .. || exit 1 cl /nologo /MD /EHsc /Ox /D_CRT_SECURE_NO_DEPRECATE /D_CRT_NONSTDC_NO_DEPRECATE /DNDEBUG /W4 /wd4127 /wd4251 /wd4275 /wd4786 /wd4100 /wd4245 /wd4206 /wd4018 /wd4389 -I..\..\port -I..\..\ogr -I..\..\gcore -I..\..\alg -I..\..\ogr\ogrsf_frmts -IC:\programs\compa_libs\openjpeg_v1_4\libopenjpeg -DOGR_ENABLED /c openjpegdataset.cpp openjpegdataset.cpp openjpegdataset.cpp(80) : error C2146: syntax error : missing ';' before identifier 'JP2OpenJPEGDataset_Read' openjpegdataset.cpp(80) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int openjpegdataset.cpp(80) : error C2061: syntax error : identifier 'OPJ_UINT32' I greped for OPJ_UINT32 in the OpenJpeg source and on GDAL's) and there was no sign of it. I am using openjpeg_v1_4_source_r697 as per its web site. Joaquim ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Fail to build with OpenJpeg
On 09-03-2011 02:59, Angelos Tzotsos wrote: Hi Joaquim, In order to build with OpenJpeg, you must use the unreleased version 2.0 of OpenJpeg. Try the following: http://code.google.com/p/openjpeg/downloads/detail?name=openjpeg_v2_alpha_0.zip Thanks Angelos, but with this version I'm not even able to build OpenJpeg as it hangs on CMake with this error Could NOT find TIFF (missing: TIFF_LIBRARY TIFF_INCLUDE_DIR) Easy to fix the above by pointing into its local libtiff directory but compilation hangs latter on with (only first of many) Error1error C2373: 'opj_stream_create' : redefinition; different type modifiers C:\programs\compa_libs\OpenJPEG_V2_Alpha\Development\libopenjpeg\cio.c228 1openjpeg Also, since it comes with a libtif.lib it would not likely compile for Win64 which is may main goal to try this. Regards Joaquim Regards, Angelos On 03/09/2011 03:23 AM, Joaquim Luis wrote: Hi, My attempt to build gdal (trunk) on Windows with OpenJpeg failed with these errors C:\programs\GDALtrunk\gdal\frmtscd openjpeg nmake /nologo /f makefile.vc cd .. || exit 1 cl /nologo /MD /EHsc /Ox /D_CRT_SECURE_NO_DEPRECATE /D_CRT_NONSTDC_NO_DEPRECATE /DNDEBUG /W4 /wd4127 /wd4251 /wd4275 /wd4786 /wd4100 /wd4245 /wd4206 /wd4018 /wd4389 -I..\..\port -I..\..\ogr -I..\..\gcore -I..\..\alg -I..\..\ogr\ogrsf_frmts -IC:\programs\compa_libs\openjpeg_v1_4\libopenjpeg -DOGR_ENABLED /c openjpegdataset.cpp openjpegdataset.cpp openjpegdataset.cpp(80) : error C2146: syntax error : missing ';' before identifier 'JP2OpenJPEGDataset_Read' openjpegdataset.cpp(80) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int openjpegdataset.cpp(80) : error C2061: syntax error : identifier 'OPJ_UINT32' I greped for OPJ_UINT32 in the OpenJpeg source and on GDAL's) and there was no sign of it. I am using openjpeg_v1_4_source_r697 as per its web site. Joaquim ___ 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] Fail to build with OpenJpeg
On 09-03-2011 16:28, Tamas Szekeres wrote: I had to do the following tweaks in order to compile openjpegv2 from SVN. Index: CMakeLists.txt === --- CMakeLists.txt(revision 660) +++ CMakeLists.txt(working copy) @@ -50,6 +50,7 @@ IF(WIN32) IF(BUILD_SHARED_LIBS) ADD_DEFINITIONS(-DOPJ_EXPORTS) +ADD_DEFINITIONS(-DUSE_OPJ_DEPRECATED) ELSE(BUILD_SHARED_LIBS) ADD_DEFINITIONS(-DOPJ_STATIC) ENDIF(BUILD_SHARED_LIBS) Index: openjpeg.h === --- openjpeg.h(revision 660) +++ openjpeg.h(working copy) @@ -37,7 +37,7 @@ #define OPJ_API #define OPJ_CALLCONV #else -#define OPJ_CALLCONV __stdcall +#define OPJ_CALLCONV //__stdcall #ifdef OPJ_EXPORTS #define OPJ_API __declspec(dllexport) #else BTW: The compiled binaries/libs/headers (including x64) are available to download from: http://vbkto.dyndns.org/sdk/ Thank you very much Tamas. I guess that to build the X64 you had to point it to a X64 libtiff.lib that you have build yourself as well? And, sorry, which one of your files has the libs and includes? Not this one: release-1600-x64-gdal-mapserver.zip http://vbkto.dyndns.org/sdk/Download.aspx?file=release-1600-x64-gdal-mapserver.zip perhaps this? gdal-19dev-1600-x64-core.msi http://vbkto.dyndns.org/sdk/Download.aspx?file=release-1600-x64-gdal-mapserver%5Cgdal-19dev-1600-x64-core.msi I confess that I don't like the .msi installers because i never know what else the they do besides installing the package. Joaquim Best regards, Tamas 2011/3/9 Joaquim Luis jl...@ualg.pt mailto:jl...@ualg.pt On 09-03-2011 02:59, Angelos Tzotsos wrote: Hi Joaquim, In order to build with OpenJpeg, you must use the unreleased version 2.0 of OpenJpeg. Try the following: http://code.google.com/p/openjpeg/downloads/detail?name=openjpeg_v2_alpha_0.zip Thanks Angelos, but with this version I'm not even able to build OpenJpeg as it hangs on CMake with this error Could NOT find TIFF (missing: TIFF_LIBRARY TIFF_INCLUDE_DIR) Easy to fix the above by pointing into its local libtiff directory but compilation hangs latter on with (only first of many) Error1error C2373: 'opj_stream_create' : redefinition; different type modifiers C:\programs\compa_libs\OpenJPEG_V2_Alpha\Development\libopenjpeg\cio.c 2281openjpeg Also, since it comes with a libtif.lib it would not likely compile for Win64 which is may main goal to try this. Regards Joaquim Regards, Angelos On 03/09/2011 03:23 AM, Joaquim Luis wrote: Hi, My attempt to build gdal (trunk) on Windows with OpenJpeg failed with these errors C:\programs\GDALtrunk\gdal\frmtscd openjpeg nmake /nologo /f makefile.vc http://makefile.vc cd .. || exit 1 cl /nologo /MD /EHsc /Ox /D_CRT_SECURE_NO_DEPRECATE /D_CRT_NONSTDC_NO_DEPRECATE /DNDEBUG /W4 /wd4127 /wd4251 /wd4275 /wd4786 /wd4100 /wd4245 /wd4206 /wd4018 /wd4389 -I..\..\port -I..\..\ogr -I..\..\gcore -I..\..\alg -I..\..\ogr\ogrsf_frmts -IC:\programs\compa_libs\openjpeg_v1_4\libopenjpeg -DOGR_ENABLED /c openjpegdataset.cpp openjpegdataset.cpp openjpegdataset.cpp(80) : error C2146: syntax error : missing ';' before identifier 'JP2OpenJPEGDataset_Read' openjpegdataset.cpp(80) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int openjpegdataset.cpp(80) : error C2061: syntax error : identifier 'OPJ_UINT32' I greped for OPJ_UINT32 in the OpenJpeg source and on GDAL's) and there was no sign of it. I am using openjpeg_v1_4_source_r697 as per its web site. Joaquim ___ gdal-dev mailing list gdal-dev@lists.osgeo.org mailto:gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org mailto: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] accessing zip files by URL
Hi, How do we access to a compressed files by URL? We can do that, can't we? As an example I try this (on Windows) gdalinfo /vsizip/C:\http://dds.cr.usgs.gov/srtm/version2_1/SRTM30/w020n90/w020n90.dem.zip ERROR 4: `/vsizip/C:\http://dds.cr.usgs.gov/srtm/version2_1/SRTM30/w020n90/w020n90.dem.zip' does not exist in the file system, and is not recognised as a supported dataset name. and this gdalinfo /vsizip//http://dds.cr.usgs.gov/srtm/version2_1/SRTM30/w020n90/w020n90.dem.zip but the error message is similar. The idea is to fetch the data directly into GMT, but first I need to understand well how it works. Thanks Joaquim Luis ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] accessing zip files by URL
Even, Chaitanya Thanks for hint. I did read the http://trac.osgeo.org/gdal/wiki/UserDocs/ReadInZip but it hasn't any mention to the need of using vsicurl I was about to do the tests you did, so thank you also for that. The point here is not to read that file in particular. I just wanted to use one as example and one that is not a *.tar.gz that the docs say it won't work. Ok, I have enough information to make it possible to read some compressed files sitting somewhere in the web and have the data land directly in the internals of GMT. Thanks Joaquim Joaquim, The correct syntax would be : gdalinfo /vsizip/vsicurl/http://dds.cr.usgs.gov/srtm/version2_1/SRTM30/w020n90/w020n90.dem.zip/W020N90.DEM or just : gdalinfo /vsizip/vsicurl/http://dds.cr.usgs.gov/srtm/version2_1/SRTM30/w020n90/w020n90.dem.zip because the zip file only contains one single file (W020N90.DEM) ... But the W020N90.DEM inside the zip file isn't directly recognized by GDAL (even if you download it and unzip the file). It's just a RAW file, that neads an header to tell the dimension, georeferencing, datatype etc, so the above won't directly work. You can for example create a VRT that refers to the raw file : VRTDataset rasterXSize=4800 rasterYSize=6000 GeoTransform-20, 8.3338e-03, 0, 90, 0, -8.3338e-03/GeoTransform VRTRasterBand dataType=Int16 band=1 subClass=VRTRawRasterBand NoDataValue-/NoDataValue SourceFilename relativetoVRT=0/vsizip/vsicurl/http://dds.cr.usgs.gov/srtm/version2_1/SRTM30/w020n90/w020n90.dem.zip/SourceFilename ByteOrderMSB/ByteOrder /VRTRasterBand /VRTDataset I've deduced this VRT from the http://dds.cr.usgs.gov/srtm/version2_1/SRTM30/w020n90/w020n90.hdr.zip file that sits next to the .dem.zip file. It's a shame that they didn't put the .hdr and the .dem file inside the same zip. It would have they been possible to open it directly... With the SRTM3 in HGT format, you can directly do : gdalinfo /vsizip/vsicurl/http://dds.cr.usgs.gov/srtm/version2_1/SRTM3/Africa/N00E006.hgt.zip Best regards, Even Hi, How do we access to a compressed files by URL? We can do that, can't we? As an example I try this (on Windows) gdalinfo /vsizip/C:\http://dds.cr.usgs.gov/srtm/version2_1/SRTM30/w020n90/w020n90.de m.zip ERROR 4: `/vsizip/C:\http://dds.cr.usgs.gov/srtm/version2_1/SRTM30/w020n90/w020n90.d em.zip' does not exist in the file system, and is not recognised as a supported dataset name. and this gdalinfo /vsizip//http://dds.cr.usgs.gov/srtm/version2_1/SRTM30/w020n90/w020n90.dem. zip but the error message is similar. The idea is to fetch the data directly into GMT, but first I need to understand well how it works. Thanks 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] accessing zip files by URL
Great, thanks Joaquim Le jeudi 24 mars 2011 19:03:57, Joaquim Luis a écrit : Even, Chaitanya Thanks for hint. I did read the http://trac.osgeo.org/gdal/wiki/UserDocs/ReadInZip but it hasn't any mention to the need of using vsicurl Yes I am aware that it is lightly documented. I've added recently a few pointers though : - in the GDALOpen() doc : http://gdal.org/gdal_8h.html#e97be045eb4701183ad332ffce29745b which points to : http://gdal.org/cpl__vsi_8h.html#4f791960f2d86713d16e99e9c0c36258 Which mentions : This special file handler can be combined with other virtual filesystems handlers, such as /vsizip. For example, /vsizip//vsicurl/path/to/remote/file.zip/path/inside/zip Perhaps a more didactic page would be needed in the wiki. Any taker :-) ? I remind that the wiki is open in writing for everyone with an osgeo id... I was about to do the tests you did, so thank you also for that. The point here is not to read that file in particular. I just wanted to use one as example and one that is not a *.tar.gz that the docs say it won't work. Ah... well actually reading in a .tar or a .tar.gz is now supported ( http://gdal.org/cpl__vsi_8h.html#d6dd983338849e7da4eaa88f6458ab64 ). Seems that I have changed my mind since. But seeking will still be very slow of course (especially if you combine with /vsicurl !). Ok, I'm going to rectify the page about that point. Ok, I have enough information to make it possible to read some compressed files sitting somewhere in the web and have the data land directly in the internals of GMT. Thanks Joaquim Joaquim, The correct syntax would be : gdalinfo /vsizip/vsicurl/http://dds.cr.usgs.gov/srtm/version2_1/SRTM30/w020n90/w02 0n90.dem.zip/W020N90.DEM or just : gdalinfo /vsizip/vsicurl/http://dds.cr.usgs.gov/srtm/version2_1/SRTM30/w020n90/w02 0n90.dem.zip because the zip file only contains one single file (W020N90.DEM) ... But the W020N90.DEM inside the zip file isn't directly recognized by GDAL (even if you download it and unzip the file). It's just a RAW file, that neads an header to tell the dimension, georeferencing, datatype etc, so the above won't directly work. You can for example create a VRT that refers to the raw file : VRTDataset rasterXSize=4800 rasterYSize=6000 GeoTransform-20, 8.3338e-03, 0, 90, 0, -8.3338e-03/GeoTransform VRTRasterBand dataType=Int16 band=1 subClass=VRTRawRasterBand NoDataValue-/NoDataValue SourceFilename relativetoVRT=0/vsizip/vsicurl/http://dds.cr.usgs.gov/srtm/version2_1/ SRTM30/w020n90/w020n90.dem.zip/SourceFilename ByteOrderMSB/ByteOrder /VRTRasterBand /VRTDataset I've deduced this VRT from the http://dds.cr.usgs.gov/srtm/version2_1/SRTM30/w020n90/w020n90.hdr.zip file that sits next to the .dem.zip file. It's a shame that they didn't put the .hdr and the .dem file inside the same zip. It would have they been possible to open it directly... With the SRTM3 in HGT format, you can directly do : gdalinfo /vsizip/vsicurl/http://dds.cr.usgs.gov/srtm/version2_1/SRTM3/Africa/N00E0 06.hgt.zip Best regards, Even Hi, How do we access to a compressed files by URL? We can do that, can't we? As an example I try this (on Windows) gdalinfo /vsizip/C:\http://dds.cr.usgs.gov/srtm/version2_1/SRTM30/w020n90/w020n90 .de m.zip ERROR 4: `/vsizip/C:\http://dds.cr.usgs.gov/srtm/version2_1/SRTM30/w020n90/w020n9 0.d em.zip' does not exist in the file system, and is not recognised as a supported dataset name. and this gdalinfo /vsizip//http://dds.cr.usgs.gov/srtm/version2_1/SRTM30/w020n90/w020n90.d em. zip but the error message is similar. The idea is to fetch the data directly into GMT, but first I need to understand well how it works. Thanks 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] accessing zip files by URL
Ah... well actually reading in a .tar or a .tar.gz is now supported ( http://gdal.org/cpl__vsi_8h.html#d6dd983338849e7da4eaa88f6458ab64 ). Seems that I have changed my mind since. But seeking will still be very slow of course (especially if you combine with /vsicurl !). Ok, I'm going to rectify the page about that point. Even, Still one further point on this matter. This works fine with the promised slowness (fair enough) gdalinfo /vsitar/vsicurl/http://edcftp.cr.usgs.gov/pub/data/gtopo30/global/w020n90.tar.gz/W020N90.DEM but the file name is case dependent. I mean, this doesn't work gdalinfo /vsitar/vsicurl/http://edcftp.cr.usgs.gov/pub/data/gtopo30/global/w020n90.tar.gz/w020n90.dem I'm not sure what is the right thing to do here but as a Win (and occasional Mac or Linus) user I guess that I was expecting no case dependency. Joaquim ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] accessing zip files by URL
GDAL can not fix the fact that: http://edcftp.cr.usgs.gov/pub/data/gtopo30/global/w020n90.tar.gz/w020n90.dem is a 404. -- Chris Sure, the browsers are not yet GDAL compliant and cannot see directly inside compressed files. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] accessing zip files by URL
I understand all that and even though I'm a win user I always try to be very careful with case names (basically, I avoid upper cases). But while it is easy to see the case of the real file (I know that urls are case sensitive) it's not so easy so clear to know what's inside a compressed file on the internet because if you know it it means one already have it in the local file system. Since is up to gdal to read the contents of the compressed file and get its data (NOT the file itself) it seams to me that there would be no danger in being case insensitive. But this is really a minor point (once you know why it didn't work on the first time), I know. Joaquim Even, Still one further point on this matter. This works fine with the promised slowness (fair enough) gdalinfo /vsitar/vsicurl/http://edcftp.cr.usgs.gov/pub/data/gtopo30/global/w020n90.t ar.gz/W020N90.DEM but the file name is case dependent. I mean, this doesn't work gdalinfo /vsitar/vsicurl/http://edcftp.cr.usgs.gov/pub/data/gtopo30/global/w020n90.t ar.gz/w020n90.dem I'm not sure what is the right thing to do here but as a Win (and occasional Mac or Linus) user I guess that I was expecting no case dependency. GDAL's behaviour with the case sensitivity in a virtual file path is completely OS independant. Actually filenames in archives are case sensitive. I have just made a .tar.gz with 2 filenames that only differ by their case : $ tar tvzf aa.tar.gz -rw-r--r-- even/even 2 2011-03-24 23:54 Aa -rw-r--r-- even/even 3 2011-03-24 23:54 aa And the same with a zip file : $ unzip -l aa.zip Archive: aa.zip Length DateTimeName - -- - 2 2011-03-24 23:54 Aa 3 2011-03-24 23:54 aa - --- 5 2 files Admitedly a windows user will not be very happy when he uncompresses those archives in a real filesystem ;-) I will also note that URLs are also case sensitive. http://edcftp.cr.usgs.gov/pub/data/gtopo30/global/w020n90.tar.gz is a valid URL, but http://edcftp.cr.usgs.gov/pub/data/gtopo30/global/w020n90.tar.gZ is not So I'm not sure that there's really a point in making the lookup of filenames inside the archive case insensitive. Joaquim ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Windows link issue with Poppler/PDF
Jeff, I get the same thing (VS2010 ). I could only link the 0.14 built for 32 bits. For 64 there were some other problems that I don't remember anymore. Joaquim Hello, On windows using Visual Studio 2008 I have compiled poppler.lib (from poppler-0.16.4, using cmake), excellent, and if I cd to /frmts/pdf and 'nmake /f makefile.vc' there are no problems; however during GDAL's link I get the following error: *** poppler.lib(GlobalParams.obj) : error LNK2005: _DllMain@12 already defined in gdaldllmain. obj Creating library gdal_i.lib and object gdal_i.exp gdal19dev.dll : fatal error LNK1169: one or more multiply defined symbols found NMAKE : fatal error U1077: 'C:\Program Files\Microsoft Visual Studio 9.0\VC\BIN\link.EXE ' : return code '0x491' Stop. *** (I have tried both GDAL-1.8.0 and trunk, same error) Anyone see what I am doing wrong, or give me some hints as to how to solve this DLLMain already defined problem? Thanks. -jeff ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Windows link issue with Poppler/PDF
On 10-04-2011 19:03, Jeff McKenna wrote: Hello Joaquim, Oh ok thanks, I will try with poppler 0.14.x as you recommend. (I can add to the GDAL linker flags /FORCE:MULTIPLE and it will compile, but that is not good practice I imagine) Should I file this issue in GDAL Trac? Perhaps, but maybe Tamas has something to say about this. Joaquim -jeff On 11-04-10 2:52 PM, Joaquim Luis wrote: Jeff, I get the same thing (VS2010 ). I could only link the 0.14 built for 32 bits. For 64 there were some other problems that I don't remember anymore. Joaquim Hello, On windows using Visual Studio 2008 I have compiled poppler.lib (from poppler-0.16.4, using cmake), excellent, and if I cd to /frmts/pdf and 'nmake /f makefile.vc' there are no problems; however during GDAL's link I get the following error: *** poppler.lib(GlobalParams.obj) : error LNK2005: _DllMain@12 already defined in gdaldllmain. obj Creating library gdal_i.lib and object gdal_i.exp gdal19dev.dll : fatal error LNK1169: one or more multiply defined symbols found NMAKE : fatal error U1077: 'C:\Program Files\Microsoft Visual Studio 9.0\VC\BIN\link.EXE ' : return code '0x491' Stop. *** (I have tried both GDAL-1.8.0 and trunk, same error) Anyone see what I am doing wrong, or give me some hints as to how to solve this DLLMain already defined problem? Thanks. -jeff ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Dateline gap
Jerl, I would do that with GMT. By using ps2raster you can convert any GMT figure (in geogs of course) into KML, and GMT has excellent care of date line transition issues. Joaquim Hello: I stopped by the #gdal channel on IRC to ask this question. Thank you for the help provided there. I thought it might be better if I asked a question here so I can better explain what's going on in one spot and not flood the channel. I understand this is a pixel center vs pixel edge issue. My ultimate goal is to get from a netCDF file to a google map overlay contour. The general steps I've taken, which work all the way up to about 178.29 then it just cuts off. netCDF - color-relief PNG using gdaldem color-relief ... PNG - Geocoded PNG using gdal_translate -a_srs EPSG:4326 -outsize 4096 4096 -a_ullr -180.25 90.25 180.25 -90.25 on the PNG (Have also tried this with just -180 90 180 -90 PNG - tiles using gdal2tiles.py -s EPSG:4326 -z 0 -n -w google on the Geocoded PNG I guess first question, is my methodology sound? Maybe there's a better way/tool to approach the problem. Following is the output from gdalinfo, other than that, what information might I be able to provide that could help? Thank you, Jerl gdalinfo for the source netcdf: (My apologies, I'm not certain what is relevant so I'm including most everything.) Driver: netCDF/Network Common Data Format Files: test.nc Size is 721, 361 Coordinate System is `' Origin = (-180.250,90.250) Pixel Size = (0.500,-0.500) Metadata: NC_GLOBAL#Conventions=CF-1.0 NC_GLOBAL#cdm_data_type=GRID NC_GLOBAL#file_format=GEMPAK NC_GLOBAL#location=test.grd NC_GLOBAL#history=Direct read of GEMPAK into NetCDF-Java 4.0 API NC_GLOBAL#_CoordinateModelRunDate=2011-04-12T00:00:00Z UVIN_NONE#long_name=testdata UVIN_NONE#units= UVIN_NONE#missing_value=-9.999000e+03 UVIN_NONE#VectorComponentFlag=gridRelative time#long_name=forecast time time#units=minute since 2011-04-12T00:00:00Z time#_CoordinateAxisType=Time lat#units=degrees_north lat#long_name=latitude coordinate lat#standard_name=latitude lat#grid_spacing=0.5 degrees_north lat#_CoordinateAxisType=Lat lon#units=degrees_east lon#long_name=longitude coordinate lon#standard_name=longitude lon#grid_spacing=0.5 degrees_east lon#_CoordinateAxisType=Lon Corner Coordinates: Upper Left (-180.250, 90.250) Lower Left (-180.250, -90.250) Upper Right ( 180.250, 90.250) Lower Right ( 180.250, -90.250) Center ( 0.000, 0.000) gdalinfo of geocoded PNG: Driver: PNG/Portable Network Graphics Files: testWorld.png testWorld.png.aux.xml Size is 4096, 4096 Coordinate System is: GEOGCS[WGS 84, DATUM[WGS_1984, SPHEROID[WGS 84,6378137,298.257223563, AUTHORITY[EPSG,7030]], AUTHORITY[EPSG,6326]], PRIMEM[Greenwich,0, AUTHORITY[EPSG,8901]], UNIT[degree,0.01745329251994328, AUTHORITY[EPSG,9122]], AUTHORITY[EPSG,4326]] Origin = (-180.000,90.000) Pixel Size = (0.08789062500,-0.04394531250) Image Structure Metadata: INTERLEAVE=PIXEL Corner Coordinates: Upper Left (-180.000, 90.000) (180d 0'0.00W, 90d 0'0.00N) Lower Left (-180.000, -90.000) (180d 0'0.00W, 90d 0'0.00S) Upper Right ( 180.000, 90.000) (180d 0'0.00E, 90d 0'0.00N) Lower Right ( 180.000, -90.000) (180d 0'0.00E, 90d 0'0.00S) Center ( 0.000, 0.000) ( 0d 0'0.01E, 0d 0'0.01N) Band 1 Block=4096x1 Type=Byte, ColorInterp=Red Mask Flags: PER_DATASET ALPHA Band 2 Block=4096x1 Type=Byte, ColorInterp=Green Mask Flags: PER_DATASET ALPHA Band 3 Block=4096x1 Type=Byte, ColorInterp=Blue Mask Flags: PER_DATASET ALPHA Band 4 Block=4096x1 Type=Byte, ColorInterp=Alpha ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Dateline gap
Jerl, I suggested the ps2raster way because it's one that I know well (I'm supposed to) but probably there is also a GDAL solution (that I don't know). Since ps2raster is a GMT program I suggest that you make this questions in the GMT list. However, since I kind of start this I'll give some further infos here. Regarding the error message you got the explanation is simple. ps2raster takes a POSTSCRIPT file and converts it into other formats using ghoscript. If the ps file was created by GMT, it will detect the projection information stored as PS comments and use it to create a kml file (or geotiff btw). That means in principle ANY figure created with GMT and using plain geographical coordinates can be converted to KML. But you used ps2raster directly with the netcdf file, which is not possible at all. Finally, the netcdf file is a bit strange too. What are the coordinates? 0 512 0 512 doesn't sound like real coordinates. Joaquim Hello: I'm having a hard time getting anything to work with the files I have. Maybe the files need to be changed or translated? Joaquim mentioned they need to be in geogs but I'm not sure how to go about checking for that or converting to that if need be. I've included output from one of the tests I ran. It works the same way with all my files no matter what the data inside is. One thing I thought was strange was that I used the -A option, and in the error message it tells me to use the -A options. Command: ps2raster -A -D./tests -E720 -TG -V -W+k testNETCDF.nc Output: ps2raster: Processing testNETCDF.nc: Find HiResBoundingBox Error: /undefined in CDF Operand stack: Execution stack: %interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 1878 1 3 %oparray_pop 1877 1 3 %oparray_pop 1861 1 3 %oparray_pop 1755 1 3 %oparray_pop --nostringval-- %errorexec_pop .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- Dictionary stack: --dict:1151/1684(ro)(G)-- --dict:0/20(G)-- --dict:70/200(L)-- Current allocation mode is local Current file position is 5 ps2raster: GMT FATAL ERROR: The file testNETCDF.nc has no BoundingBox in the first 20 lines or last 256 bytes. Use -A option. gdalinfo for netcdf: Driver: netCDF/Network Common Data Format Files: testNETCDF.nc Size is 512, 512 Coordinate System is `' Metadata: NC_GLOBAL#Conventions=COARDS NC_GLOBAL#calendar=standard NC_GLOBAL#comments=File NC_GLOBAL#model=geos/das NC_GLOBAL#center=gsfc Subdatasets: SUBDATASET_1_NAME=NETCDF:testNETCDF.nc:max_temp SUBDATASET_1_DESC=[15x601x1201] max_temp (32-bit floating-point) SUBDATASET_2_NAME=NETCDF:testNETCDF.nc:min_temp SUBDATASET_2_DESC=[15x601x1201] min_temp (32-bit floating-point) SUBDATASET_3_NAME=NETCDF:testNETCDF.nc:prcp SUBDATASET_3_DESC=[15x601x1201] prcp (32-bit floating-point) Corner Coordinates: Upper Left (0.0,0.0) Lower Left (0.0, 512.0) Upper Right ( 512.0,0.0) Lower Right ( 512.0, 512.0) Center ( 256.0, 256.0) Thank you, Jerl On Tue, Apr 12, 2011 at 7:24 PM, Joaquim Luisjl...@ualg.pt wrote: Jerl, I would do that with GMT. By using ps2raster you can convert any GMT figure (in geogs of course) into KML, and GMT has excellent care of date line transition issues. Joaquim Hello: I stopped by the #gdal channel on IRC to ask this question. Thank you for the help provided there. I thought it might be better if I asked a question here so I can better explain what's going on in one spot and not flood the channel. I understand this is a pixel center vs pixel edge issue. My ultimate goal is to get from a netCDF file to a google map overlay contour. The general steps I've taken, which work all the way up to about 178.29 then it just cuts off. netCDF -color-relief PNG using gdaldem color-relief ... PNG -Geocoded PNG using gdal_translate -a_srs EPSG:4326 -outsize 4096 4096 -a_ullr -180.25 90.25 180.25 -90.25 on the PNG (Have also tried this with just -180 90 180 -90 PNG -tiles using gdal2tiles.py -s EPSG:4326 -z 0 -n -w google on the Geocoded PNG I guess first question, is my methodology sound? Maybe there's a better way/tool to approach the problem. Following is the output from gdalinfo, other than that, what information might I be able to provide that could help? Thank you, Jerl gdalinfo for the source netcdf: (My apologies, I'm not certain what is relevant so I'm including most everything.) Driver: netCDF/Network Common Data Format Files: test.nc Size is 721, 361 Coordinate System is `' Origin = (-180.250,90.250) Pixel Size = (0.500,-0.500) Metadata: NC_GLOBAL#Conventions=CF-1.0 NC_GLOBAL#cdm_data_type=GRID NC_GLOBAL#file_format=GEMPAK NC_GLOBAL#location=test.grd NC_GLOBAL#history=Direct read of GEMPAK into
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] Using gdalwarp with HDF files- problem reading proejction
António, I don't know what is a WGS 84 Spherical Radius. WGS84 is an ellipsoid with Equatorial radius of 6378.137 km (flattening 1/298.2572235630) Why you are getting that info? Well, that's because it is encoded in the file (and apparently not the one you expected). Joaquim Greetings I have a dataset (in HDF) and I need to convert its projection. When I do gdalinfo I get this information: Coordinate System is: GEOGCS[Unknown datum based upon the Clarke 1866 ellipsoid, DATUM[Not specified (based on Clarke 1866 spheroid), SPHEROID[Clarke 1866,6378206.4,294.9786982139006, AUTHORITY[EPSG,7008]]], PRIMEM[Greenwich,0], UNIT[degree,0.0174532925199433]] Origin = (-10.0013888,45.0013890) Pixel Size = (0.0027778,-0.0027778) But this is odd. I was suppose to get Plate-Carrée with geographic Lat/Long and Ref ellipsoid WGS 84 Spherical Radius= Equatorial Radius=Re= 6378,14km) Why am I no obtaining this information? Nevertheless, has this any impact or shall I use *-s_srs and define it do Plate Carée (EPSG:??) ? *Thanks Antonio __ Information from ESET NOD32 Antivirus, version of virus signature database 6272 (20110707) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.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
[gdal-dev] PDF via podofo
Hi, I am still having troubles with a build with PDF support. I used to have a working solution for my gdalread MEX by using poppler 0.14, however now GDAL gives an error when linking with it (something about a member that does not exist). So I turned again to 0.16 and managed to compile everything. But now Matlab just crash when I read a pdf (repeat, before it used to work). Next I tried the podofo (funny name) library. Everything compiles fine but a PDF driver does not exit when print the available drivers (and obviously, reading pdf does not work). I also noted that grepping PODOFO_ENABLED for the entire GDAL tree, it only shows up once, in nmake.opt. Ah, it's a Windows build that I'm talking about. Joaquim Luis ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] PDF via podofo
On 12-07-2011 12:20, Even Rouault wrote: Le mardi 12 juillet 2011 12:59:31, Joaquim Luis a écrit : Hi, I am still having troubles with a build with PDF support. I used to have a working solution for my gdalread MEX by using poppler 0.14, however now GDAL gives an error when linking with it (something about a member that does not exist). Error at compile time about fillGooString() missing, with a very recent trunk ? If so, I've just fixed it when testing compilation on CentOS 6 that ships with poppler 0.12.4. Exactly. So I turned again to 0.16 and managed to compile everything. But now Matlab just crash when I read a pdf (repeat, before it used to work). Hum I guess you run into cross-heap issues related to different versions of the MSVC Runtime... Perhaps but I am very careful in maintaining separate directories with libs compiled with a certain compiler (I swap between VS2010 and Intel 32, 64) and than always link with the libs created with the same compiler. That's why I want to be able to compile all dependencies that I use to build GDAL. Next I tried the podofo (funny name) library. Everything compiles fine but a PDF driver does not exit when print the available drivers (and obviously, reading pdf does not work). I also noted that grepping PODOFO_ENABLED for the entire GDAL tree, it only shows up once, in nmake.opt. Yes, there was something missing in frmts/makefile.vc. I think I've just fixed it (untested though) So 'svn update' and retry Thanks, I'll try it later today. Joaquim Ah, it's a Windows build that I'm talking about. 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] PDF via podofo
Evan, It seams to work now. I say seams because with podofo it also requires to have available pdftoppm gdal_translate lixo.pdf lixo.tiff Input file size is 1239, 1754 0'pdftoppm' is not recognized as an internal or external command, but since your fix to build with poppler 0.14 works just fine again and this doesn't oblige to carry any other 3rth prog I'm staying within this solution. Thanks again Joaquim On 12-07-2011 12:20, Even Rouault wrote: Le mardi 12 juillet 2011 12:59:31, Joaquim Luis a écrit : Hi, I am still having troubles with a build with PDF support. I used to have a working solution for my gdalread MEX by using poppler 0.14, however now GDAL gives an error when linking with it (something about a member that does not exist). Error at compile time about fillGooString() missing, with a very recent trunk ? If so, I've just fixed it when testing compilation on CentOS 6 that ships with poppler 0.12.4. Exactly. So I turned again to 0.16 and managed to compile everything. But now Matlab just crash when I read a pdf (repeat, before it used to work). Hum I guess you run into cross-heap issues related to different versions of the MSVC Runtime... Perhaps but I am very careful in maintaining separate directories with libs compiled with a certain compiler (I swap between VS2010 and Intel 32, 64) and than always link with the libs created with the same compiler. That's why I want to be able to compile all dependencies that I use to build GDAL. Next I tried the podofo (funny name) library. Everything compiles fine but a PDF driver does not exit when print the available drivers (and obviously, reading pdf does not work). I also noted that grepping PODOFO_ENABLED for the entire GDAL tree, it only shows up once, in nmake.opt. Yes, there was something missing in frmts/makefile.vc. I think I've just fixed it (untested though) So 'svn update' and retry Thanks, I'll try it later today. Joaquim Ah, it's a Windows build that I'm talking about. 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 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] converting lines to linestrings
On 27-08-2011 17:27, Frank Warmerdam wrote: On 11-08-27 02:10 AM, Zoltan Szecsei wrote: Hi, I'm not sure if this is the correct list to address this on, but I have lots of files, each with a bunch of lines that start stop on each others ends and I need to convert them into line strings, file by file. Is there a command-line (batch) way I can do this? They are currently in DGN (v8) format but I can convert them to SHP, MID/MIF or whatever. What I'm looking to do is to create a batch pipeline that, file by file, will take each line, and if either of its ends are within 0.5m of another line-end, then join them together to form one line string, then output that snapped up data to disk. (any format) Zoltan, I do not believe you can accomplish this with ogr2ogr. But it is certainly possible to write a script, for instance in python, that would accomplish this in combination with the OGR API. That is the approach I would take. Hi, The GMT program 'gmtstitch' will do just that but you will have to convert the DGN files to gmt with ogr2ogr Joaquim ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Re: gdal_rasterize output off by one pixel/cell
On 29-08-2011 22:10, Burton-Kelly, Matthew wrote: Thanks Even for making the fix! Is there documentation anywhere for how to apply changes like this? I apologize but I am just getting into this type of development. I thought I was able to install the latest nightly build today, but I'm not sure. Running Mac OS X. If anyone has any pointers I would really appreciate them off-list. Thanks, Matt Matt, I never tried it as I always (re)build from SVN but that implies having previously built the dependencies, but homebrew (no Fink, no MacPorts, HOMEBREW) has a GDAL formula that contemplates svn build. Maybe it's worth to give it a try. Joaquim ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] OGR_G_ExportToWkt make MEX crash
Hi,
I wrote a OGR C MEX wrapper to use in Matlab which already works in many
cases.
However, I had a situation when trying to fetch the reference info. The
chunk of code below now works, but if I use the commented line that calls
OGR_G_ExportToWkt
than Matlab crashes at that line. However, using the OSRExportTo...
functions works fine.
I'm I doing something forbidden or ...
heers
Joaquim
hSRS = OGR_L_GetSpatialRef(hLayer);/* Do not free it later */
if (hSRS) {
char*pszWKT = NULL, *pszProj4 = NULL;
mxArray*mxPrjRef;
/*OGR_G_ExportToWkt (hSRS, pszWKT); */ == THIS
CALL MAKE THE MEX CRASH
if (OSRExportToProj4(hSRS, pszProj4) == OGRERR_NONE) {
mxPrjRef = mxCreateString (pszProj4);
mxSetField (out_struct, 0, SRSProj4, mxPrjRef);
}
if (OSRExportToPrettyWkt(hSRS, pszWKT, 1) == OGRERR_NONE) {
mxPrjRef = mxCreateString (pszWKT);
mxSetField (out_struct, 0, SRSWkt, mxPrjRef);
}
}
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
