Re: [gdal-dev] Call for discussion on RFC68: C++11 compilation mode

RFC68 was voted on and adopted: https://lists.osgeo.org/pipermail/gdal-dev/2017-September/047139.html On Tue, Sep 5, 2017 at 2:46 AM, Even Rouault wrote: > Hi Tamas, > > > > this is great! Thanks > > > > Even > > > > > Hi Even, > > > > > > The new SDK-s have now been added. > > > > > > Best rega

Re: [gdal-dev] Improve clipping of shapefiles

On 11 September 2017 at 21:09, Paul Meems wrote: > I have a large shapefile with over 2.8 million shapes (fishnet) and I have a > border file with only 1 multipolygon. > > I'm trying to clip the fishnet with the border. > Using code is takes about 5 min. using command line it takes even longer. >

Re: [gdal-dev] Opening gridded xyz data that is out of order

I wonder if GDAL shouldn't suggest sorting as a means of fixing the issue, possibly with Mark's command? On Sep 11, 2017 7:32 AM, "Andreas Neumann" wrote: > Hi Mark (and others), > > Your sort command worked like a charm. It was also very fast! > > Now gdalinfo produces this nice information out

Re: [gdal-dev] git(hub) migration ?

Whatever option we go with, I agree that it is important to maintain the full history of code and tickets. In addition to the "svn blame" example that Even gave, being able to track the provenance of each line of code is also good practice for legal reasons. Daniel On 2017-09-06 2:40 PM, Eve

Re: [gdal-dev] RFC68: C++11 compilation mode - Call for vote on adoption

I declare RFC68 passed with the following votes: Even +1 Jukka +1 Daniel +0 Howard +1 Kurt +1 I appreciate all the discussion and the non-PSC folks who weighed in. I will update the RFC and begin staging a pull request targeted for Oct 1 or shortly thereafter. -kurt On Fri, Sep 8, 2017 at 2:49

Re: [gdal-dev] Opening gridded xyz data that is out of order

Hi Joaquim, Interesting. Thanks for sharing. As always with OpenSource there are more solutions than just one ;-) Yes, I am aware about the missing data in the lower right corner - this is outside of the province and outside of my area of interest. Thanks and greetings, Andreas On 11.09.

Re: [gdal-dev] Opening gridded xyz data that is out of order

Yes - I am aware of gdal_translate and gdalwarp to translate formats. Thanks a lot. I am very happy that this was so easy to solve and now I can use this data in QGIS. I think the data provider just concatenated chunks of existing files and did not care about the order. I will ask them to run

Re: [gdal-dev] Opening gridded xyz data that is out of order

You could have done it with GMT as well gmtinfo DTM_swissALTI3D_XYZ.txt -I2 -R2708001/2717999/1210001/121 xyz2grd -R2708001/2717999/1210001/121 -I2 -GDTM_swissALTI3D_XYZ.grd DTM_swissALTI3D_XYZ.txt and you get a netCDF grid (it can do GeoTIFs too but would need to go see the docs)

Re: [gdal-dev] Opening gridded xyz data that is out of order

This will do the same, just replace the EPSG code number: gdal_translate -ot Float32 -a_srs EPSG:25833 ../xyz/390_5820.dhhn92.txt ../2007.390_5820.dhhn92.25833.tif Mark ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/l

Re: [gdal-dev] Opening gridded xyz data that is out of order

Hi Mark (and others), Your sort command worked like a charm. It was also very fast! Now gdalinfo produces this nice information output: Driver: XYZ/ASCII Gridded XYZ Files: dtmav_sorted.xyz Size is 5000, 5000 Coordinate System is `' Origin = (2708000.000,121.000) Pix

Re: [gdal-dev] Opening gridded xyz data that is out of order

You must sort the data beforehand - the y position must be sorted properly (ASC or DESC) Standard linux sort program: sort -k2 -n -k1 392_5810.xyz -o 392_5810.sort.xyz (2nd column (y) as numeric, then first column (x) -o = output file As a zip file you can also do: unzip -p 390_5820.zip | sort

Re: [gdal-dev] Opening gridded xyz data that is out of order

On lundi 11 septembre 2017 15:43:47 CEST Andreas Neumann wrote: > Hi, > > I received a DTM from a Swiss province (OpenData) which is of the > following format: > > One coordinate per line, already gridded. See f.e. > > 2708001.00 1218001.00 1541.52 > 2708003.00 1218001.00 1542.35 > 2708005.00 12

Re: [gdal-dev] Opening gridded xyz data that is out of order

Can you transform the file and swap the y & x when they are in an alternative order with your choice of python/perl/awk? On Mon, Sep 11, 2017 at 6:51 AM, Andreas Neumann wrote: > Hi, > > Forgot to mention the link to the file, just in case you have time testing > - see https://services.geo.zg.ch

Re: [gdal-dev] Opening gridded xyz data that is out of order

Hi, Forgot to mention the link to the file, just in case you have time testing - see https://services.geo.zg.ch/temp/dtmav.zip (138 MB zipped file). Thanks, Andreas On 11.09.2017 15:43, Andreas Neumann wrote: Hi, I received a DTM from a Swiss province (OpenData) which is of the followin

[gdal-dev] Opening gridded xyz data that is out of order

Hi, I received a DTM from a Swiss province (OpenData) which is of the following format: One coordinate per line, already gridded. See f.e. 2708001.00 1218001.00 1541.52 2708003.00 1218001.00 1542.35 2708005.00 1218001.00 1542.98 2708007.00 1218001.00 1543.58 2708009.00 1218001.00 1544.20 2708

Re: [gdal-dev] Improve clipping of shapefiles

Can't really help you with the OGR part, however, I wrote utilities do solve this (really) fast for calculating grids based on this type of intersection. Speed is often a matter of using specific tools utilizing the characteristics of the problem, i.c. the fishnet regularities. Can you share the sh

[gdal-dev] Improve clipping of shapefiles

I have a large shapefile with over 2.8 million shapes (fishnet) and I have a border file with only 1 multipolygon. I'm trying to clip the fishnet with the border. Using code is takes about 5 min. using command line it takes even longer. This is my command: ogr2ogr fishnetClipped.shp fishnet.shp -