Re: [gdal-dev] decimal rounding issue when re-projecting
Hi, Thanks a lot for the quick answer. Indeed, adding the -tr 20 20 solved the problem. As you pointed out, it should be possible to do the transformation in one step, however I want to keep an intermediate .tif file for visualization. The 20/21m per pixel resolution I had at first, even if gdalwarp does no keep the resolution, is due to the fact that so close to the south pole the distortion/difference between polar stereographic and polar gnomonic is quite small. Again, thanks a lot for the answer, Cheers, Ramiro On 07/16/2015 05:41 PM, Jukka Rahkonen wrote: Ramiro Marco Figuera r.marcofiguera at jacobs-university.de writes: Hi, I'm re-projecting (from stereographic to gnomonic) the PDS LOLA 20m/pix DTMS from the lunar south pole. Im using gdalwarp like this: 'gdalwarp -t_srs '+proj=gnom +lat_0=-90 +lat_ts=-90 +lon_0=0 +k=1 +x_0=0 +y_0=0 +a=1737400 +b=1737400 +units=m +no_defs' topo_stereo.tif topo_gnom.tif' . After that, I'm cropping the DTM to have a smaller region (200km by 200km) around the pole. Then, I just use gdal_translate to export it as XYZ since I need it in this format for my software and converting it to kilometers instead of meters using awk. As this is a gridded data, the resolution should remain the same (20m/pixel), however when I check the first entries of my xyz file the resolution is sometimes 21 m/pixel and sometimes 20 m/pixel, and this happens randomly. Any clue of what may cause this error? Has anyone faced the same issue? Hi, Gdalwarp does not try to keep resolution unchanged and I guess that the reason is to avoid extra resampling. That your output is so close to 20 m/pix is a coincident. Varying 20/21 m pixel size in xyz file may be due to rounding errors. Have you checked the pixel size of topo_gnom.tif with gdalinfo? I would try what happens when running gdalwarp with -tr 20 20 for forcing the output resolution to 20m/pix. You should be able to crop and create 20 m/pixel xyz file with one run by setting the resolution with -tr and selecting the format with -of and defining extents with -te http://www.gdal.org/gdalwarp.html -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- Ramiro Marco Figuera Department of Physics and Earth Sciences Jacobs University Bremen Campus Ring 1, 28759 Bremen, Germany Office: Research III, Room 99b Tel: +49 (0)421 200 3226 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Motion: Adopt FRC48: Geographical networks support
Hi, I finished the work on merging the GSoC2014 Geographical networks support in GDAL to trunk. The RFC (https://trac.osgeo.org/gdal/wiki/rfc48_geographical_networks_support) was corrected. The pull request (https://github.com/OSGeo/gdal/pull/60) created. Travis building passed. I think it's time to vote for adopt the RFC 48 Geographical networks support and to merge the pull request to the GDAL sources trunk. According to https://trac.osgeo.org/gdal/wiki/rfc1_pmc I start the vote and my +1 for adopt. -- Best regards, Dmitry ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Memory error for gdal_grid if using nearest
Hi Even, I have converted it to a Spatialite file for easier download: https://www.wesendit.com/dl/hcjLajYe9F3i/ The problem is still the same. The offending command is: gdal_grid.exe test.sqlite test.tif -ot Float32 -of GTiff -zfield Cond1_mSm -l 02vhidep_raw -a nearest -a invdist works without a problem. Are the two algorithms not using the same search? Since this problem only occurs with files covering France in RGF93/Lambert93 (I have tested two different files, both show the same problem) I wonder whether the range of coordinates of RGF93 may be the issue. All my other files so far never had this problem. Armin On 17/07/2015 01:20, Even Rouault wrote: On Thursday 16 July 2015 21:03:52 Armin Schmidt wrote: I have a very simple point-shapefile which throws various memory allocation errors when I try to grid it with gdal_grid using nearest, but works absolutely fine and fast when using the invdist algorithm. I never had this problem before. Does anyone have any idea what is wrong? If it would help I can provide the shapefile. Armin, That could be useful indeed. From your description, it looks like the building of the spatial index would went wrong with this particular dataset, looping forever or something like that and ending up eating all the memory. Even The stripped down command-line is: gdal_grid.exe 02VHiDep_raw.shp test.tif -ot Float32 -of GTiff -zfield Cond1_mSm -l 02VHiDep_raw -a nearest After taking some time (probably searching for the nearest neighbours), this throws: ERROR 1: CPLMalloc(): Out of memory allocating 64 bytes. FATAL: CPLMalloc(): Out of memory allocating 64 bytes. ERROR 1: TIFFWriteDirectorySec:Out of memory ERROR 2: Cannot allocate 8192 bytes ERROR 1: TIFFWriteDirectorySec:Out of memory ERROR 1: TIFFWriteDirectorySec:Out of memory Grid data type is Float32 Grid size = (256 256). Corner coordinates = (449675.737076 6895223.317256)-(449705.249717 6895209.690215). Grid cell size = (0.114835 0.053024). Source point count = 3280. Algorithm name: nearest. Options are radius1=0.00:radius2=0.00:angle=0.00:nodata=0.00 Armin -- __ Dr. Armin Schmidt Chief Developer, GeodataWIZ Ltd: Geo Data + Visualisation www.GeodataWIZ.com www.GeodataWIZ.com/armin-schmidt Chairman, Internat. Society for Archaeological Prospection www.archprospection.org Honorary Visiting Research Fellow, University of Bradford Department of Archaeological Sciences Honorary Fellow, Durham University, Department of Archaeology http://orcid.org/-0002-4241-5381 Email: armin.r.schm...@gmail.com Now available: Earth Resistance for Archaeologists (2013). Lanham: AltaMira Press Geophysical Data in Archaeology (2013). Oxford: Oxbow Books. http://www.amazon.co.uk/-/e/B0034QC4OW __ ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
