G. Allegri wrote:
> exec `g.region rast="$RAST"`
This is bogus on two counts. First, g.region doesn't output a shell
command, so the use of exec and backticks makes no sense. Second,
shell scripts shouldn't change the current region; they should create
a temporary region with "g.region ... save=
Moritz Lennert wrote:
> > This is a limitation of the data format rather than the software. I'm
> > not aware of any "image" format which supports GRASS-style colour
> > tables (IIRC, GDAL can embed the GRASS colour table in a private
> > chunk, but I'm not aware of any software which can make us
Your task sounds like it would be best done by a small script or C
program. Just read the data in a line-at-a-time and check if the
current line is larger than the previously stored line. At the end of
the file, print out the largest line (to a file if you have multiple
results to store). Probably
Sat 05 Jan 2008 17:13, sebastian sauer wrote:
> Sat 05 Jan 2008 16:45, Vincent BAIN wrote:
> > If you follow Markus' how-to, you may be interested in technical info
> > concerning your camera :
> >
> > Kodak DCS Pro SLR/n/c
> > imager size : 36.0mm x 24.0mm
> > pixel size : 7.9µm x 7.9µm
>
> exac
you could use R with the Rgdal [1] package. You read the LIDAR file
and then simply a function like this:
import your data attirubting them to "your_Dataframe" with something like:
# your_Dataframe<-readGDAL(filename,drivername)
You could retrieve the drivernames with gdalDrivers()
# row_MAX<-y
Hi,
First of all Happy New Year to all on the list J
I am trying to build a 3D Street Network, thus where the streets have
elevation so I can do routing depending on slope level.
I am using the GRASS Book Dataset of North Carolina.
I tried to combine : streets_wake and elev_state_5
On Jan 5, 2008 5:17 PM, Nikos Alexandris
<[EMAIL PROTECTED]> wrote:
> A friend works with LIDAR data. He needs to write a program with which
> he extracts (from an vector ASCII x,y,z file) the row containing the
> maximum z (height) and write a new vector ASCII containing the result.
>
> (He writes
Hi Man,
not sure if you remember me - we spoke about bundle block adjustment
in 2002.
There is a recent discussion about this in the GRASS user list and
I remembered that I have received "atgrass.tgz" from you. Did you
continue to work on this?
Best regards
Markus Neteler
On Jan 5, 2008 5:31 PM
On Jan 5, 2008 4:46 PM, Maning Sambale <[EMAIL PROTECTED]> wrote:
>
> > OK, I have added my draft recipe here:
> > http://grass.gdf-hannover.de/wiki/Orthorectification_digital_camera
>
> It says:
> Usually such high-resolution DEMs (raster cell length below 1m) are not
> easily available. Therefore
A friend works with LIDAR data. He needs to write a program with which
he extracts (from an vector ASCII x,y,z file) the row containing the
maximum z (height) and write a new vector ASCII containing the result.
(He writes in C++)
Since he deals with lots of ASCII files he needs to batch this job.
Hi,
Sat 05 Jan 2008 16:45, Vincent BAIN wrote:
> If you follow Markus' how-to, you may be interested in technical info
> concerning your camera :
>
> Kodak DCS Pro SLR/n/c
> imager size : 36.0mm x 24.0mm
> pixel size : 7.9µm x 7.9µm
exactly. even if you (for unknown reasons) do not follow Markus
> OK, I have added my draft recipe here:
> http://grass.gdf-hannover.de/wiki/Orthorectification_digital_camera
It says:
Usually such high-resolution DEMs (raster cell length below 1m) are not
easily available. Therefore, interpolation of a given DEM to a higher
resolution is recommended
The dem
If you follow Markus' how-to, you may be interested in technical info
concerning your camera :
Kodak DCS Pro SLR/n/c
imager size : 36.0mm x 24.0mm
pixel size : 7.9µm x 7.9µm
see this page for other cameras :
http://www.digitaldingus.com/reference/general/sensorsizes.php
Good luck !
Vincent
Salamat!
Never expected such quick replies!
A few more details:
Camera: Kodak Pro DCS 14N digital SLR camera
using a 19-35mm Tamron zoom lens set at 19mm focal length, 13.5
megapixel resolution (4,500 x 3,000 pixels).
Images are in Kodak DCR format. Converting to tif before export to
GRASS mo
Merci !
I'll try it soon...
Le samedi 05 janvier 2008 à 14:21 +0100, Markus Neteler a écrit :
> On Jan 5, 2008 1:56 PM, Vincent BAIN <[EMAIL PROTECTED]> wrote:
> >
> > Le samedi 05 janvier 2008 à 13:44 +0100, Markus Neteler a écrit :
> >
> > > On Jan 5, 2008 1:35 PM, Markus Metz <[EMAIL PROTECTED
On Jan 5, 2008 1:56 PM, Vincent BAIN <[EMAIL PROTECTED]> wrote:
>
> Le samedi 05 janvier 2008 à 13:44 +0100, Markus Neteler a écrit :
>
> > On Jan 5, 2008 1:35 PM, Markus Metz <[EMAIL PROTECTED]> wrote:
> > ...
> > > Anyway, digital cameras are apparently not supported in i.ortho.photo.
> >
> > Why
Le samedi 05 janvier 2008 à 13:44 +0100, Markus Neteler a écrit :
> On Jan 5, 2008 1:35 PM, Markus Metz <[EMAIL PROTECTED]> wrote:
> ...
> > Anyway, digital cameras are apparently not supported in i.ortho.photo.
>
> Why this? I did so, using a handheld digital camera:
>
> M. Neteler, D. Grasso
On Jan 5, 2008 1:35 PM, Markus Metz <[EMAIL PROTECTED]> wrote:
...
> Anyway, digital cameras are apparently not supported in i.ortho.photo.
Why this? I did so, using a handheld digital camera:
M. Neteler, D. Grasso, I. Michelazzi, L. Miori, S. Merler, and
C. Furlanello, 2005. An integrated to
On Jan 5, 2008 8:24 AM, maning sambale <[EMAIL PROTECTED]> wrote:
...
> The photographs were taken along the flight line using a professional
> Kodak N14 digital SLR camera, which has a resolution of 14 megapixels.
You can figure out camera parameters with 'jhead':
http://www.sentex.net/~mwandel/j
Hi Maning,
if I understand you right, the purpose is to obtain a georeferenced
mosaic of the aerial photographs. There are several ways to get to there.
The easiest is to georeference each aerial photograph against your
Quickbird imagery. This is straightforward and well documented in the
GRASS he
On 05/01/08 02:23, David Finlayson wrote:
Here is a link to my web site with the latest version:
http://david.p.finlayson.googlepages.com/grasstogoogleearth
I have something that works for me, but I was forced to use image
magick to clip the nodata collar off of the exported png file. If I
can
Hello Maning,
Yes the actually important data concerns the camera properties. I fear
your images won't be easy to handle : I guess your camera is not
properly an aerial survey camera system, is it ? each image should show
fiducial marks on its edges, and you should have a calibration
certificate pr
22 matches
Mail list logo
