Custom Query (432 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (376 - 378 of 432)

Ticket Resolution Summary Owner Reporter
#21 fixed Support: 05/May/2007, John McArthur, ? amro amro
Description
   Our SUN SOLARIS workstations have finally given up the ghost, and died on us.  I've since arranged with our IT section for a Linux based platform running 'uhbunto'. 

        I downloded an 'arcgcorr' file from your site http://arsf.nerc.ac.uk/data/azimuth.asp   Yet I get the following error message.

        jnm1@d201241: ~/Desktop/test1 jnm1@d201241:~/Desktop/test1$ ./azgcorr

-----------------------------------------------------------------------
azgcorr  -- ver: 4.5.9-lin Jan 12 2006   (C) Azimuth Systems UK 1996, 2006


 ******************************************************

 TO:  Jun   using system  d201241  with serial number bfb4faa0

 ******************************************************
 ***  Warning: the licensed period of this program  ***
 ***  ended on:       -900/00/2007     please contact ***
 ***  NERC-ARSF for an update and more details.     ***
 ***      (C) Azimuth Systems UK 1996, 2005         ***
 ******************************************************

        Is there another version I can tryout on my Linux box?   
 Hi Peter,
                Sorry to bother you, but I'd sent an e-mail to Ivana, and I've received an e-mail saying undeliverable.

        Could you possibly forward my request below to whomsover is responsible for the 'azgcorr' convertion software.

        Thanking you,
                John McArthur. 
#35 fixed Support: 06/July/2007, Peter North, ? mggr mggr
Description

Requested, via Gary, updated azgcorr (was using .4591 & .4611).

#166 fixed Support: 13/Jun/08, John Stevenson, IPY07/02, Lidar interpolation issue benj benj
Description

Query relating to Thingvallavatn (#98) lidar data - overlapping flight lines in opposite directions causing interpolation artefacts (see attached image).

We believe these are caused by the lidar being aimed down a steep slope flying one way and up it flying the other coupled to a slight boresight offset, causing a difference in exactly where it hits the slope in each case being calculated as the same location (hence why it only happens on steep slopes, and only on slopes that are either roughly parallel to or perpendicular to the plane, depending on which boresight angle is off).

Suggested solution is to average the lines using r.mapcalc in Grass prior to interpolation of null areas. If the slope is of a fairly constant gradient and the problem is caused by the above, this should hopefully produce reasonable results. Also asked Gabriel Amable at ULM for any suggestions. Given example data in ~arsf/support/20080813-JohnStevenson

Original email as below:

Hi,

I am working on the 203_Thingvallavatn dataset.  I am processing the LiDAR to generate a 1 m DEM.  I have combined the xyz points from each of the .all files into one big file for processing.  When the data are plotted (via nearneigbor and grdview in GMT, or via v.in.ascii and v.surf.rst in GRASS, or r.in.xyz and r.resamp.rst in GRASS), I find that some areas contain ESE-trending stripes.  These have a spacing of 3-5 m and an amplitude of a few 10s of centimetres.  The lines are perpendicular to the flightlines and I imagine that they are due to disagreement between data of different flights.

How do you recommend that I treat the data to remove these?  The stripes are only present on steeper slopes with a NNW to ENE aspect, so I am currently applying a filter to these areas (with the smooth=map parameter in r.resamp.rst).  Do you have any other suggestions?

I have attached some sample data points and a plot of the problem.

Thanks,

John
Note: See TracQuery for help on using queries.