Re: [GRASS-dev] Segmentation fault using v.in.lidar
Doug, Markus, Thanks for the interesting discussion, > In the short term, use the las2las command from liblas.org to merge your > .las files into a single las file and then process the one file. > Yes at the moment, my workflow is: ls ID_*.las > las_list.txt lasmerge -i las_list.txt -o out.las v.in.lidar in=out.las out=lidar -trb Works very well. I was just wondering how difficult it would be to use wildcards directly in the input=... option. Obviously it requires some significant amount of work. > You will have to watch out for the 4 billion point limit that is currently in > the LAS file format, but for most folks that's not an issue. > Indeed, not an issue for me (unfortunately!), > In all GRASS versions, the limit with topology is at 2^31 - > 1 (about 2 billion) features. I usually never build the topology of my LiDAR point clouds. Should I do it? Cheers, Pierre > Pierre Roudier > Sent by: grass-dev-boun...@lists.osgeo.org > > 07/13/2011 03:05 AM > > To > Markus Metz > cc > grass-dev > Subject > Re: [GRASS-dev] Segmentation fault using v.in.lidar > > > > > Thanks for the quick answer Markus, > > That would be a nice feature to add though. A lot of the LAS files are > coming "tiled", and it'd be nice to be able to do something like: > > v.in.lidar in=*.las out=test_input_lidar -trb > > or > > v.in.lidar in=zone_32_*.las out=test_input_lidar -trb > > to import a special subset of LAS files. > > I've very few coding abilities, so this is just meant as another line > on the wishlist ;) > > Thanks heaps for your work on *.in.lidar, it is working well otherwise, > > Pierre > > 2011/7/13 Markus Metz : > > On Wed, Jul 13, 2011 at 2:08 AM, Pierre Roudier > > wrote: > >> Hi, > >> > >> I've been trying to use v.in.lidar. It yields good results on one LAS > >> file, but I get a segfault when trying it on several files: > >> > >>> v.in.lidar in=BD32_1610.las,BD32_1611.las out=test_input_lidar -trb > >> Segmentation fault > >>> v.in.lidar in=BD32_161*.las out=test_input_lidar -trb > >> Segmentation fault > >> > >> Am I missing something, or is it a bug? > > > > v.in.lidar takes only one input file at a time. > > > > Markus M > > > > > > -- > Scientist > Landcare Research, New Zealand > ___ > grass-dev mailing list > grass-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-dev > -- Scientist Landcare Research, New Zealand ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] strange mapcalc result
Well, maybe a fluke. I'll check again and report anything weird. Michael __ C. Michael Barton Director, Center for Social Dynamics & Complexity Professor of Anthropology, School of Human Evolution & Social Change Arizona State University Tempe, AZ 85287-2402 USA voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC) fax: 480-965-7671(SHESC), 480-727-0709 (CSDC) www:http://csdc.asu.edu, http://shesc.asu.edu http://www.public.asu.edu/~cmbarton On Jul 13, 2011, at 1:05 AM, Glynn Clements wrote: > > Michael Barton wrote: > >> In the even that this might be the case, I also tried creating a new map >> >> r.mapcalc >> expression='SRTM_ffB03_p199r033_2=if(SRTM_ffB03_p199r033==-32768,null(),SRTM_ffB03_p199r033)' >> >> ...and got the same result with the new map. > > No idea. r.mapcalc hasn't had any changes in months. > > -- > Glynn Clements ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] utlities for reading GeoScan/GeoPlot files?
Does anyone know of an open source utility to read magnetometer/gradiometer dumped in GeoScan binary format as *.GRD and *.DAT files? In other words something to use geophysical survey instrument data without needed proprietary instrument vendor software? Thanks Michael __ C. Michael Barton Director, Center for Social Dynamics & Complexity Professor of Anthropology, School of Human Evolution & Social Change Arizona State University Tempe, AZ 85287-2402 USA voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC) fax: 480-965-7671(SHESC), 480-727-0709 (CSDC) www:http://csdc.asu.edu, http://shesc.asu.edu http://www.public.asu.edu/~cmbarton ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Segmentation fault using v.in.lidar
On Wed, Jul 13, 2011 at 2:59 PM, wrote: > > > In the short term, use the las2las command from liblas.org to merge > your .las files into a single las file and then process the one file. You > will have to watch out for the 4 billion point limit that is currently in the > LAS file format, but for most folks that's not an issue. > In GRASS 6, the limit is somewhere lower than 2 billion features because GRASS vector files can't be larger than 2GB. In GRASS 7, it should depend only on whether GRASS was compiled with Large File Support. In all GRASS versions, the limit with topology is at 2^31 - 1 (about 2 billion) features. Markus M > > Pierre Roudier > Sent by: grass-dev-boun...@lists.osgeo.org > > 07/13/2011 03:05 AM > > To > Markus Metz > cc > grass-dev > Subject > Re: [GRASS-dev] Segmentation fault using v.in.lidar > > > > > Thanks for the quick answer Markus, > > That would be a nice feature to add though. A lot of the LAS files are > coming "tiled", and it'd be nice to be able to do something like: > > v.in.lidar in=*.las out=test_input_lidar -trb > > or > > v.in.lidar in=zone_32_*.las out=test_input_lidar -trb > > to import a special subset of LAS files. > > I've very few coding abilities, so this is just meant as another line > on the wishlist ;) > > Thanks heaps for your work on *.in.lidar, it is working well otherwise, > > Pierre > > 2011/7/13 Markus Metz : > > On Wed, Jul 13, 2011 at 2:08 AM, Pierre Roudier > > wrote: > >> Hi, > >> > >> I've been trying to use v.in.lidar. It yields good results on one LAS > >> file, but I get a segfault when trying it on several files: > >> > >>> v.in.lidar in=BD32_1610.las,BD32_1611.las out=test_input_lidar -trb > >> Segmentation fault > >>> v.in.lidar in=BD32_161*.las out=test_input_lidar -trb > >> Segmentation fault > >> > >> Am I missing something, or is it a bug? > > > > v.in.lidar takes only one input file at a time. > > > > Markus M > > > > > > -- > Scientist > Landcare Research, New Zealand > ___ > grass-dev mailing list > grass-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-dev > ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Segmentation fault using v.in.lidar
Pierre, I think the main issue with doing *.las would be that although LAS data is coming in tiled but is also available as overlapping swaths. I imagine to impliment the option for multiple las files you would need to build an internal index of the "footprint" of each input las file that tells r.in.lidar and v.in.lidar which file(s) to draw the input las data from to create the output. In the case of r.in.lidar, you would need to specify which files to simultaneously open to gather the point values to calculate the statistics that are the value of the output cell. You would need something like the way gdaltindex builds a polygon shape file from a list of input georeferenced images. ( Now if I only had some skill with C to throw together some code :-( ) In the short term, use the las2las command from liblas.org to merge your .las files into a single las file and then process the one file. You will have to watch out for the 4 billion point limit that is currently in the LAS file format, but for most folks that's not an issue. Doug Doug Newcomb USFWS Raleigh, NC 919-856-4520 ext. 14 doug_newc...@fws.gov - The opinions I express are my own and are not representative of the official policy of the U.S.Fish and Wildlife Service or Dept. of the Interior. Life is too short for undocumented, proprietary data formats. Pierre Roudier Sent by: grass-dev-boun...@lists.osgeo.org 07/13/2011 03:05 AM To Markus Metz cc grass-dev Subject Re: [GRASS-dev] Segmentation fault using v.in.lidar Thanks for the quick answer Markus, That would be a nice feature to add though. A lot of the LAS files are coming "tiled", and it'd be nice to be able to do something like: v.in.lidar in=*.las out=test_input_lidar -trb or v.in.lidar in=zone_32_*.las out=test_input_lidar -trb to import a special subset of LAS files. I've very few coding abilities, so this is just meant as another line on the wishlist ;) Thanks heaps for your work on *.in.lidar, it is working well otherwise, Pierre 2011/7/13 Markus Metz : > On Wed, Jul 13, 2011 at 2:08 AM, Pierre Roudier > wrote: >> Hi, >> >> I've been trying to use v.in.lidar. It yields good results on one LAS >> file, but I get a segfault when trying it on several files: >> >>> v.in.lidar in=BD32_1610.las,BD32_1611.las out=test_input_lidar -trb >> Segmentation fault >>> v.in.lidar in=BD32_161*.las out=test_input_lidar -trb >> Segmentation fault >> >> Am I missing something, or is it a bug? > > v.in.lidar takes only one input file at a time. > > Markus M > -- Scientist Landcare Research, New Zealand ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Python Scripting Library: mogrify command
Thanks Glynn for clarification,
I will go with the make_command()...
Maxi
On 07/13/2011 11:26 AM, Glynn Clements wrote:
Massimiliano Cannata wrote:
I was wandering: does exist a python::core function capable to mogrigy
the inputs of a run_command()?
The mogrify function for psycopg2 is defined as follows:
"/Return a query string after arguments binding. The string returned is
exactly the one that would be sent to the database running the execute()
method or similar./"
>>> cur.mogrify("INSERT INTO test (num, data) VALUES (%s, %s)", (42,
'bar'))
"INSERT INTO test (num, data) VALUES (42, E'bar')"
...so for GRASS it could be:
>>> grass.mogrify_command("r.univar",flags="g",map="test")
"r.univar -g map=test"
make_command() returns an argument list, e.g.:
> import grass.script as grass
> grass.make_command("r.univar",flags="g",map="test")
['r.univar', '-g', 'map=test']
This is what all of the *_command() functions use to generate the
argument list.
Converting an argument list to a string is non-portable (/bin/sh has
significantly different syntax to cmd.exe) and quite tricky unless
you're willing to blindly quote everything to be on the safe side,
e.g. (for /bin/sh):
args = [arg.replace("'", "'\\''") for arg in args]
cmdstr = "'" + "' '".join(args) + "'"
It's much harder for Windows; see:
http://msdn.microsoft.com/en-us/library/17w5ykft.aspx
or escape_arg() in lib/gis/spawn.c, or list2cmdline() in Python's
subprocess.py.
Note that none of the *_command() functions construct a command
string; they pass the argument list to subprocess.Popen() which
eventually either passes it to execve() (on Unix) or uses
list2cmdline() (on Windows).
--
Dr. Eng. Massimiliano Cannata
Responsabile Area Geomatica
Istituto Scienze della Terra
Scuola Universitaria Professionale della Svizzera Italiana
Via Trevano, c.p. 72
CH-6952 Canobbio-Lugano
Tel: +41 (0)58 666 62 14
Fax +41 (0)58 666 62 09
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Re: display text in wxNviz
Maris Nartiss wrote: > I'm sorry to disappoint You. I have no idea about X or OpenGL > programming. All I know is that XLoadQueryFont() returns NULL on valid > font names. On my Gentoo system xfontsel also doesn't work. (Are other > programs using different method to find system fonts for X?) XLoadQueryFont() and xfontsel only work for X11 fonts. They don't work for client-side fonts (which is what most modern toolkits and applications use). Most modern GUI toolkits rely upon high-level libraries such as Pango, FontConfig and/or FreeType for text. Use of X11 fonts is now sufficiently uncommon that some Linux distributions don't install any X bitmap fonts by default. -- Glynn Clements ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Python Scripting Library: mogrify command
Massimiliano Cannata wrote:
> I was wandering: does exist a python::core function capable to mogrigy
> the inputs of a run_command()?
>
> The mogrify function for psycopg2 is defined as follows:
> "/Return a query string after arguments binding. The string returned is
> exactly the one that would be sent to the database running the execute()
> method or similar./"
> >>> cur.mogrify("INSERT INTO test (num, data) VALUES (%s, %s)", (42,
> 'bar'))
> "INSERT INTO test (num, data) VALUES (42, E'bar')"
>
> ...so for GRASS it could be:
> >>> grass.mogrify_command("r.univar",flags="g",map="test")
> "r.univar -g map=test"
make_command() returns an argument list, e.g.:
> import grass.script as grass
> grass.make_command("r.univar",flags="g",map="test")
['r.univar', '-g', 'map=test']
This is what all of the *_command() functions use to generate the
argument list.
Converting an argument list to a string is non-portable (/bin/sh has
significantly different syntax to cmd.exe) and quite tricky unless
you're willing to blindly quote everything to be on the safe side,
e.g. (for /bin/sh):
args = [arg.replace("'", "'\\''") for arg in args]
cmdstr = "'" + "' '".join(args) + "'"
It's much harder for Windows; see:
http://msdn.microsoft.com/en-us/library/17w5ykft.aspx
or escape_arg() in lib/gis/spawn.c, or list2cmdline() in Python's
subprocess.py.
Note that none of the *_command() functions construct a command
string; they pass the argument list to subprocess.Popen() which
eventually either passes it to execve() (on Unix) or uses
list2cmdline() (on Windows).
--
Glynn Clements
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] usage of subprocess.call
António Rocha wrote: > Greetings > > In a Python script I'm using this to run an external BIN: > p=subprocess.call(command) where command is my command to run the bin. p > will be equal tot he return values of the bin. > (so far so good) > But I'm getting an error now while running bin: > File "C:/EIS/scripts/mycopy", line 577, in > >main() > File "C:/EIS/scripts/mycopy", line 278, in main >p=subprocess.call(command) > File "C:\EIS\Python25\lib\subprocess.py", line 444, in > call >return Popen(*popenargs, **kwargs).wait() > File "C:\EIS\Python25\lib\subprocess.py", line 594, in > __init__ >errread, errwrite) > File "C:\EIS\Python25\lib\subprocess.py", line 816, in > _execute_child >startupinfo) > WindowsError: [Error 193] > > My problem is not the error but, is there a way to "get" the error and > stop the process in a more smoother way instead of stopping so drastically? According to MSDN: http://msdn.microsoft.com/en-us/library/ms681382%28v=vs.85%29.aspx ERROR_BAD_EXE_FORMAT%1 is not a valid Win32 application. 193 (0xC1) Note that if you want to run something other than a binary executable, you have to use pass shell=True to subprocess.call. As for catching the exception, use e.g.: try: p = subprocess.call(...) ... except OSError, e: # deal with exception WindowsError is a subclass of OSError; catching OSError will be more portable. If you need to catch "all" errors, use StandardError, which is the base class of "real" errors (it doesn't include non-error exceptions such as Warning, StopIteration, SystemExit, etc). -- Glynn Clements ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #1401: r.series for time series
#1401: r.series for time series
-+--
Reporter: mmetz| Owner: grass-dev@…
Type: enhancement | Status: new
Priority: normal | Milestone: 7.0.0
Component: Raster | Version: svn-trunk
Keywords: raster, time series |Platform: All
Cpu: All |
-+--
Comment(by glynn):
Replying to [comment:7 mmetz]:
> I calculate the weighed average for a given point in time from a given
time interval, same like r.resamp.filter calculates the weighed average
for a given point in space from a given space interval,
In the case of r.resamp.filter, each output cell is typically calculated
based upon a small subset of the input cells, not the entire input.
> The way I currently use the patched r.series, an option radius would
only make sense in combination with a multiple option centre.
It would make sense even for a single output, as it controls how rapidly
the weight falls off with distance from the centre.
> > In general, the cut-off frequency shouldn't depend upon the filtering
method; the reason the various filters in r.resamp.filter have associated
radii is so that the cut-off frequency doesn't vary with the filter method
(i.e. the user-supplied radius value is normalised).
>
> AFAICT, the patch does the same, the user-supplied radius is normalised.
AFAICT, the code maps the input range to the width of the window function,
so wider windows will be "sharper" (have a higher cut-off frequency), e.g.
lanczos3 will be sharper than lanczos2.
> It's not clear to me how the term frequency can be applied to a
gauss/normal distribution,
r.resamp.filter implements FIR (finite impulse response) filtering (you
get an error if you don't have at least one finite window function). If
you calculate the DFT of any of the window functions, you'll get its
frequency response. All of the functions are low-pass filters, as they're
symmetric.
See http://en.wikipedia.org/wiki/Window_function for examples of common
window functions and their frequency responses.
A piecewise-continuous function defined by sampled data can be considered
a mixture (sum) of the underlying signal and quantisation noise. The
intent of a low pass filter is to discard the quantisation noise while
retaining the signal.
The cut-off frequency is normally chosen according to the sampling
frequency, as the quantisation noise is dominated by the sampling
frequency and its harmonics. In general, the cut-off frequency is
inversely proportional to the width of the central "lobe" of the window
function.
If you run r.resamp.filter with a specific radius, you get a specific cut-
off frequency regardless of the method chosen. So while lanczos3 uses 3
times as large a window as lanczos1, the cut-off frequency remains the
same. This is what I mean when I say that the radius is "normalised".
OTOH, if you map the range of inputs to the range of the filter, "long-
tailed" filters with a wider domain (e.g. lanczos3) will have a narrower
central lobe and thus a higher cut-off frequency.
The way that Lanczos filters are defined, the number of samples is
supposed to be proportional to the order ("a" parameter), so lanczos3
should use 3 times as many samples (at the same sampling frequency, i.e.
cover 3 times as large a time interval) as lanczos1 in order to get a
similar frequency response (higher-order filters will fall off faster, but
the frequency at which the fall-off starts should be the same).
See http://en.wikipedia.org/wiki/File:Lanczos-kernel.svg for an
illustration. If both graphs were drawn on the same axes, they would have
roughly the same shape, but the a=3 window would have a longer tail. By
scaling the axes to the same width, the a=3 window has a narrower central
lobe.
--
Ticket URL:
GRASS GIS
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] strange mapcalc result
Michael Barton wrote: > In the even that this might be the case, I also tried creating a new map > > r.mapcalc > expression='SRTM_ffB03_p199r033_2=if(SRTM_ffB03_p199r033==-32768,null(),SRTM_ffB03_p199r033)' > > ...and got the same result with the new map. No idea. r.mapcalc hasn't had any changes in months. -- Glynn Clements ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Segmentation fault using v.in.lidar
Thanks for the quick answer Markus, That would be a nice feature to add though. A lot of the LAS files are coming "tiled", and it'd be nice to be able to do something like: v.in.lidar in=*.las out=test_input_lidar -trb or v.in.lidar in=zone_32_*.las out=test_input_lidar -trb to import a special subset of LAS files. I've very few coding abilities, so this is just meant as another line on the wishlist ;) Thanks heaps for your work on *.in.lidar, it is working well otherwise, Pierre 2011/7/13 Markus Metz : > On Wed, Jul 13, 2011 at 2:08 AM, Pierre Roudier > wrote: >> Hi, >> >> I've been trying to use v.in.lidar. It yields good results on one LAS >> file, but I get a segfault when trying it on several files: >> >>> v.in.lidar in=BD32_1610.las,BD32_1611.las out=test_input_lidar -trb >> Segmentation fault >>> v.in.lidar in=BD32_161*.las out=test_input_lidar -trb >> Segmentation fault >> >> Am I missing something, or is it a bug? > > v.in.lidar takes only one input file at a time. > > Markus M > -- Scientist Landcare Research, New Zealand ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
