Re: [gdal-dev] weeding out x,y,z points
Have you looked at the spatial applications available in R. It sounds like you have a lidar data set yes? R has a bunch of packages that could help, gstat, spatstat, maptools, sp, etc have a look at http://wiki.r-project.org/rwiki/doku.php?id=tips:spatial-data One option I can think of, but cant remember how to do it is the following. Sometimes when interpolating lidar points (or any for that matter) it is useful to remove some points from your data for validation later on. typically one would remove 5 or 10% of the data and use this to validate the final surface. So you would then sit with the modelling data containing 90% of the original data and your validation data containing 10% of the original data. The removal is usually done randomly and would therefore allow you to retain the structure of your original data. As I said earlier I cant exactly remember how this is done, but the link should give you a good start. HTH Wesley Wesley Roberts MSc. Researcher: Earth Observation (Ecosystems) Natural Resources and the Environment CSIR Tel: +27 (21) 888-2490 Fax: +27 (21) 888-2693 To know the road ahead, ask those coming back. - Chinese proverb nicholas.g.lawre...@mainroads.qld.gov.au 02/26/09 6:57 AM 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 Okay, I downloaded the Manpages. My initial reading is that blockmean and blockmedian work by averaging the values. 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. Is this still do-able? Is there a specific option I should be looking at? Regards, nick *** WARNING: This e-mail (including any attachments) may contain legally privileged, confidential or private information and may be protected by copyright. You may only use it if you are the person(s) it was intended to be sent to and if you use it in an authorised way. No one is allowed to use, review, alter, transmit, disclose, distribute, print or copy this e-mail without appropriate authority. If this e-mail was not intended for you and was sent to you by mistake, please telephone or e-mail me immediately, destroy any hardcopies of this e-mail and delete it and any copies of it from your computer system. Any right which the sender may have under copyright law, and any legal privilege and confidentiality attached to this e-mail is not waived or destroyed by that mistake. It is your responsibility to ensure that this e-mail does not contain and is not affected by computer viruses, defects or interference by third parties or replication problems (including incompatibility with your computer system). Opinions contained in this e-mail do not necessarily reflect the opinions of the Queensland Department of Main Roads, Queensland Transport or Maritime Safety Queensland, or endorsed organisations utilising the same infrastructure. *** ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ 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
Hi, 2009/2/26 Ari Jolma ari.jo...@tkk.fi nicholas.g.lawre...@mainroads.qld.gov.au wrote: nicholas.g.lawre...@mainroads.qld.gov.au Can GDAL or OGR weed out 3D points based on proximity to each other? I would use plain Perl (or Python or high level language X) to read in the points sequentially and discard new ones that are too close to existing ones. It may take a while require a bit of memory it is probably doable that way (millions of points but not 100s of millions in the end set). The program shouldn't need to be more than 20 lines I guess. scipy (python's numeric/scientific workhorse) now has a Kdtrees capabilities, which are an efficient way of working out distances between points: http://docs.scipy.org/doc/scipy/reference/spatial.html Best regards, Jose ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Link GDAL with MinGW
MinGW gcc generates .dll.a files, which are the link libraries, but it can also use the plain dll to link against. However, when you mention gdal16.dll, it sounds like you're trying to link against a GDAL dll that was generated with VC. The C++ API is very difficult to use from such dll when you're developing with MinGW if not impossible. I, for one, have never succeeded. The Swig bindings use some C++ API, which have so far prevented me from using an official binary gdal dll for the Perl bindings for example. Ari LF kirjoitti: Hi to everyone, I'm trying to make a plugin for GDAL. So I need to use some GDALDataset methods (AddBand, GetDriver, setGCPs, ...). When I compile my code with MinGW it's all OK, but when MinGW starts linking it doesn't found these methods and give me undefined reference to all them. In makefile I added to LNK_FLAGS variable both gdal16.dll and its path. I tried to use gdal_i.lib of 1.5 version too, but nothing appened. If it's useful I copy CPP_FLAGS following: CPPFLAGS:=-Wall -DCSK_PLUGIN -fPIC $(GDAL_INCLUDE) $(HDF5_INCLUDE) $(CPPFLAGS) CPPFLAGS:= -DH5_HAVE_HIGH_LEVEL_API $(CPPFLAGS) CPPFLAGS:= -DWIN32 -DDLL_EXPORT -DPIC $(CPPFLAGS) ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- Prof. Ari Jolma Environmental Management Information Technology Teknillinen Korkeakoulu / Helsinki University of Technology tel: +358 9 4511 address: POBox 5300, 02015 TKK, Finland Email: ari.jolma at tkk.fi URL: http://geoinformatics.tkk.fi ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Re: Link GDAL with MinGW
Ari Jolma ari.jolma at tkk.fi writes: MinGW gcc generates .dll.a files, which are the link libraries, but it can also use the plain dll to link against. However, when you mention gdal16.dll, it sounds like you're trying to link against a GDAL dll that was generated with VC. The C++ API is very difficult to use from such dll when you're developing with MinGW if not impossible. I'm not sure of this. In the same project I linked *correctly* hdf5 library, which is a dll file and I think compiled with VC. I've problem only with gdal. Perhaps it needs some flags when compile. Ari LF kirjoitti: Hi to everyone, I'm trying to make a plugin for GDAL. So I need to use some GDALDataset methods (AddBand, GetDriver, setGCPs, ...). When I compile my code with MinGW it's all OK, but when MinGW starts linking it doesn't found these methods and give me undefined reference to all them. In makefile I added to LNK_FLAGS variable both gdal16.dll and its path. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Re: Link GDAL with MinGW
LF kirjoitti: Ari Jolma ari.jolma at tkk.fi writes: MinGW gcc generates .dll.a files, which are the link libraries, but it can also use the plain dll to link against. However, when you mention gdal16.dll, it sounds like you're trying to link against a GDAL dll that was generated with VC. The C++ API is very difficult to use from such dll when you're developing with MinGW if not impossible. I'm not sure of this. In the same project I linked *correctly* hdf5 library, which is a dll file and I think compiled with VC. I've problem only with gdal. Perhaps it needs some flags when compile. But you do use VC compiled GDAL DLL? HDF5 seems to be available in many formats (for cygwin, vs2005, etc). I'm just looking at a hdf5dll.dll and it does not export anything in C++, while gdal16.dll does. I believe gcc is not able to decrypt the way VC exports C++ methods, which you are using. Why don't you use the GDAL DLL that you get from compiling it with MinGW? Ari ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Link GDAL with MinGW
Ari Jolma wrote: oops, I believe it is not correct to say Swig bindings use some C++ API, but it is nevertheless sometimes hard/not possible to mix VC and MinGW when developing for Windows Folks, I am interested in making use of the GDAL and OGR C API practical and even convenient when GDAL is built with MSVC and applications are built with MinGW. If there is a particular problem with this, I would encourage filing a ticket. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Re: Link GDAL with MinGW
Frank Warmerdam warmerdam at pobox.com writes: Ari Jolma wrote: oops, I believe it is not correct to say Swig bindings use some C++ API, but it is nevertheless sometimes hard/not possible to mix VC and MinGW when developing for Windows Folks, I am interested in making use of the GDAL and OGR C API practical and even convenient when GDAL is built with MSVC and applications are built with MinGW. If there is a particular problem with this, I would encourage filing a ticket. Best regards, First of all, thanks to your fast answers. Then, I report following my makefile. GDAL_ROOT=C:\gdalwin32-1.6_bin\ LD_SHARED=g++ -shared OBJ=hdf5dataset.o hdf5imagedataset.o GDAL_INCLUDE=-I C:\gdal_1_6_0_DEV\include HDF5_INCLUDE=-I C:\5-168-win-vnet_corrected_for_MinGW\include CPPFLAGS:=-Wall -fPIC $(GDAL_INCLUDE) $(CPPFLAGS) $(HDF5_INCLUDE) CPPFLAGS:= -DWIN32 -DDLL_EXPORT -DPIC $(CPPFLAGS) # Comment out for release mode CPPFLAGS:=-g3 -ggdb3 -DDEBUG $(CPPFLAGS) LNK_FLAGS:=$(LNK_FLAGS) -L C:\gdalwin32-1.6_bin\bin #both msvcr inserted 71 and 90 LNK_FLAGS:=$(LNK_FLAGS) -lgdal16 -lmsvcr71 -lmsvcr91 LNK_FLAGS:=$(LNK_FLAGS) -L C:\5-168-win-vnet_corrected_for_MinGW\dll LNK_FLAGS:=$(LNK_FLAGS) -lhdf5_cppdll -lhdf5dll -lhdf5_hldll .PHONY: default plugin clean PLUGIN = gdal_HDF5.so default: plugin clean: rm -f *.o *~ $(PLUGIN) hdf5dataset.o: hdf5dataset.h hdf5imagedataset.o: hdf5dataset.h plugin: $(PLUGIN) $(PLUGIN): $(OBJ) $(LD_SHARED) $(OBJ) $(LNK_FLAGS) -o $ When I compile my code with MinGW it's all OK, but when MinGW starts linking it doesn't found all methods of GDALDataset giving me undefined reference to them. It seems not to link gdal dll. You can try it in gdalsrc/frmts/hdf5 because it needs three source files in this folder. PS. To avoid compiling errors I re-compiled hdf5 as described here: http://lists.osgeo.org/pipermail/gdal-dev/2007-April/012825.html and modified /hdf5/include/H5pubconf.h defining H5_SIZEOF_SSIZE_T: #define H5_SIZEOF_SSIZE_T 4 /* for 32 bit machines */ (as described here http://trac.nexusformat.org/code/browser/branches/4.1/README.MinGW?rev=998) PS2. I tried to convert gdal dll into a .a file for MinGW as described here: http://www.mingw.org/wiki/MSVC_and_MinGW_DLLs but it doesn-t link correctly. Best regards Luca ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Re: Link GDAL with MinGW
LF wrote: First of all, thanks to your fast answers. Then, I report following my makefile. GDAL_ROOT=C:\gdalwin32-1.6_bin\ LD_SHARED=g++ -shared OBJ=hdf5dataset.o hdf5imagedataset.o Luca, I get the impression you are trying to build the HDF5 plugin with MinGW for use with a GDAL built with MSVC. Plugins use the C++ API and are generally not going to be compatible between compilers. At this time I believe you just have to use a similar compiler to build plugins as was used to build the core GDAL library. The offer to improve MinGW/MSVC mixing only applies to the GDAL/OGR C API (not the C++ API) and is mainly aimed at making it possible to build applications against the GDAL/OGR C API using MinGW when GDAL is built with MSVC. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ 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
[gdal-dev] Failure to compile 1.6.0 with errors 'libgdal.so: undefined reference to `PMPI::Intracomm::current_op'
Hi, I'm a brand new visitor to your list here. I'm working on Debian Squeeze and have had a functioning 1.6.0 install (compiled, not from a .deb) version up until this morning, when I went to re-compile so as to include additional support, specifically ogdi. After a half day of trying and failing, I felt it time to come here. The error looks like this: /bin/sh /home/walker/admin/gdal-1.6.0/libtool --mode=link g++ gdalinfo.o \ /home/walker/admin/gdal-1.6.0/libgdal.la -o gdalinfo libtool: link: g++ gdalinfo.o -o .libs/gdalinfo /home/walker/admin/gdal-1.6.0/.libs/libgdal.so -L/usr/lib -L/usr/local/lib -L/usr/lib/lib -L/usr/include/ogdi -L/usr/include/ogdi/lib -L/usr/lib/grass/lib -L/usr/local/Geo_DSDK-7.0.0.2167/lib/Release -L/usr/local/Geo_DSDK-7.0.0.2167/3rd-party/lib/Release /usr/lib/libgeos_c.so /usr/lib/libgeos.so /usr/lib/libodbc.so /usr/lib/libodbcinst.so /usr/lib/libltdl.so /usr/lib/libexpat.so /usr/local/lib/libNCSEcw.so /usr/local/lib/libNCSCnet.so /usr/local/lib/libNCSUtil.so /usr/lib/libjasper.so /usr/lib/libhdf5.so -lm -lmfhdf -ldf -logdi31 /usr/lib/libjpeg.so -lpng -lnetcdf -lgrass_vect -lgrass_dig2 -lgrass_dgl -lgrass_rtree -lgrass_linkm -lgrass_dbmiclient -lgrass_dbmibase -lgrass_I -lgrass_gproj -lgrass_vask -lgrass_gmath -lgrass_gis -lgrass_datetime -lpq -lz -lrt -ldl /usr/lib/libcurl-gnutls.so -lltidsdk -lpthread -llt_kakadu /home/walker/admin/gdal-1.6.0/.libs/libgdal.so: undefined reference to `PMPI::Intracomm::current_op' /home/walker/admin/gdal-1.6.0/.libs/libgdal.so: undefined reference to `PMPI::Comm::mpi_comm_map' /home/walker/admin/gdal-1.6.0/.libs/libgdal.so: undefined reference to `MPI::Is_initialized()' /home/walker/admin/gdal-1.6.0/.libs/libgdal.so: undefined reference to `PMPI::Comm::mpi_err_map' /home/walker/admin/gdal-1.6.0/.libs/libgdal.so: undefined reference to `MPI::Op::Free()' /home/walker/admin/gdal-1.6.0/.libs/libgdal.so: undefined reference to `op_intercept' /home/walker/admin/gdal-1.6.0/.libs/libgdal.so: undefined reference to `MPI::Op::Init(void (*)(void const*, void*, int, MPI::Datatype const), bool)' collect2: ld returned 1 exit status make[1]: *** [gdalinfo] Error 1 make[1]: Leaving directory `/home/walker/admin/gdal-1.6.0/apps' make: *** [apps-target] Error 2 My configure command looks like this: ./configure \ --with-libz \ --with-pg=/usr/bin/pg_config \ --with-grass=/usr/lib/grass \ --with-libgrass \ --with-cfitsio \ --with-pcraste \ --with-png \ --with-libtiff \ --with-geotiff \ --with-jpeg \ --with-gif \ --with-ogdi=/usr/include/ogdi \ --with-jasper=/usr/lib \ --with-ecw=/usr/local \ --with-mrsid=/usr/local/Geo_DSDK-7.0.0.2167 \ --with-jp2mrsid \ --with-xerces \ --with-xerces-inc \ --with-xerces-lib \ --with-expat \ --with-expat-inc \ --with-expat-lib \ --with-odbc \ --with-curl=/usr/bin/curl-config \ --with-geos \ --with-perl \ --with-python I'll supply any more information as needed, such as installed packages, etc. Thanks in advance, -- Steve Walker Middle Fork Geographic Information Services 360.671.2505 wal...@mfgis.com http://mfgis.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] ASCII Rasters and 'null' values in python-gdal
Oz,
NODATA_VALUES is supposed to be a pixel value (integer or real)
whereas null is a string. Try to convert all the null strings into
an unused pixel value like - in raster1.asc
Regards,
--
Chaitanya kumar CH.
On Fri, Feb 27, 2009 at 2:34 AM, Oz Nahum nahu...@gmail.com wrote:
Hi,
I have to ascii raster that I created using a text editor:
the first is called raster1.asc and looks like this:
ncols 6
nrows 4
xllcorner 3366820.019
yllcorner 5814589.037
cellsize 10
NODATA_value -
1 1 1 1 1 1
1 1 1 1 1 1
1 1 1 1 1 1
1 1 1 1 - -
The second is called raster2.asc and looks like this:
ncols 6
nrows 4
xllcorner 3366820.019
yllcorner 5814589.037
cellsize 10
NODATA_value null
1 1 1 1 1 1
1 1 1 1 1 1
1 1 1 1 1 1
1 1 1 1 null null
When I import them into python I find out the lower right corner of the
first raster is not giving the correct value: instead of 'null' qgis
displays the value '31081'.
The other raster is imported correctly and it showing 'null's for the two
last data cells.
dataset = gdal.Open('raster2.asc', GA_ReadOnly)
b = gdal_array.DatasetReadAsArray(dataset)
b
array([[1, 1, 1, 1, 1, 1],
[1, 1, 1, 1, 1, 1],
[1, 1, 1, 1, 1, 1],
[1, 1, 1, 1, 0, 0]], dtype=int16)
dataset = gdal.Open('raster1.asc', GA_ReadOnly)
a = gdal_array.DatasetReadAsArray(dataset)
a
array([[ 1, 1, 1, 1, 1, 1],
[ 1, 1, 1, 1, 1, 1],
[ 1, 1, 1, 1, 1, 1],
[ 1, 1, 1, 1, -, 31081]], dtype=int16)
So before I go and open a bug, I just wanted to know - what is wrong ? Maybe
it's my system setup ? Maybe i don't write correct ascii rasters ? Also,
another thing I would like to bypass is the fact that 'null' values are
formed as zeros in gdal-numpy - this could lead to error when doing some
raster manipulations. Is there a way to by pass this (besides being
aware...)?
I use Debian Lenny the latest relevant packages from.
Thanks,
Oz N,
Grad Studend,
Universität Tübingen
--
Imagine there's no countries
It isn't hard to do
Nothing to kill or die for
And no religion too
Imagine all the people
Living life in peace
You all must read 'The God Delusion'
http://en.wikipedia.org/wiki/The_God_Delusion
---
when one person suffers from a delusion it is called insanity. When many
people suffer from a delusion it is called religion.
Robert Pirsig, Zen and the Art of Motorcycle Maintenance
___
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
