[Gdal-dev] GDAL As A Local Map?

[Tyler Mitchell]

Jeremy, interesting application. 
I think you could do some great stuff with GDAL-related libraries, you 
just to pick the right data format.  I mainly familiar with 1 or 3 bands 
(what I can "normal") imagery, but I know there are certains formats 
support by GDAL that do more than that.

How much of the data that is collected will be thrown out vs. be kept for 
long periods of time?  If you do need to keep just appending to a raster, 
there are at least two options in my mind.

The easiest (though may not most performance-effective) may be to use an 
ASCII-based format that GDAL can support.  That way your sensor data can 
be streamed out pretty quickly without a lot of format concerns - and you 
wouldn't need GDAL per se to do the work. 

Alternatively you could spit out new data into a new file every so often, 
then do a merge/mosaic of it back with the old set - hence updating and 
expanding it. 

Those are the ways I'd do it and thereby avoiding the need to programming 
with GDAL but still using related utilities (at least  until I realize 
that performance is pathetic).

I assume that using the GDAL libraries you can programmatically add row 
and columns of data to existing rasters, perhaps someone else can comment 
on that approach.

Tyler

"Jeremy Gillula" <jeremy at caltech.edu> wrote on 08/12/2004 01:37:15 PM:

> The robot will use several types of sensors to generate the elevation 
data
> of its surroundings (laser range finders, stereovision systems) which it
> will then transform into UTM coordinates.  We may also add a layer where 
the
> robot uses other sensors to classify different elevations as certain 
types
> of terrain (road, rocks, plants, water, etc.)  To make path-planning 
easier
> we will probably combine this data into a "cost map" where the value of 
each
> pixel represents the "cost" of traversing that point, rather than the
> elevation.  Imagery of the robot's current map would be nice to have
> eventually, but isn't really necessary.  The real aim is to have a data
> structure that the robot can fill in with data in real time (on the 
order of
> thousands or even millions of elevation points per second) which can 
then be
> read, converted to a cost (which is an algorithm we already have) and 
then
> read again to do the path-planning.  It's not so much for human viewing 
as
> for robot-using.
> Writing such a data structure ourselves wouldn't be impossible (or that
> hard, either) - we just thought we'd see if an open source alternative
> existed first, and we liked how GDAL has the ability to support multiple
> bands of information - we're just not sure if it's fast enough or if it 
has
> the capability to somehow scroll the map as the robot moves without 
doing
> time-expensive data copying.
> 
> Does this information help any?  If not, let me know and I can go into 
more
> detail.  Thank you for your help!
> 
>  - Jeremy
> 
> ----- Original Message ----- 
> From: "Tyler Mitchell" <tjmitchell at riverside.bc.ca>
> To: "Jeremy Gillula" <jeremy at caltech.edu>
> Sent: Wednesday, August 11, 2004 4:56 PM
> Subject: Re: [Gdal-dev] GDAL As A Local Map?
> 
> 
> > Can you tell us more about the types of data the robot collects (just 
UTM
> > coordinates)?  Or is it going to need to create imagery?
> > Are you aiming to have a desktop mapping program that can show its 
current
> > location/data?
> >
> > Tell us more,
> > Tyler
> >
> > gdal-dev-bounces at xserve.flids.com wrote on 08/11/2004 02:21:43 PM:
> >
> > > I'm looking for an open-source system I can use for storing and
> > > processing map data for an autonomous robot, and I was wondering if
> > > anyone on this mailing list could tell me if GDAL is the right
> > > solution for me.  There are three big requirements that I need:
> > > 1.  Writing/reading to the map should be very fast, since the robot
> > > will be filling the map with data in real time, and will be using
> > > the map to navigate in real time
> > > 2.  The map should support storing data in UTM coordinates (which
> > > I'm pretty sure GDAL will do) but should also feature a local-
> > > representation, so that instead of having a big map of everywhere
> > > the robot might travel (which would be on the order of 200 miles), I
> > > would use a smaller higher-resolution map (maybe 100 or 200m on a
> > > side) which I can translate (in a sort of scrolling window) as the
> > > robot moves.
> > > 3.  The map has multiple layers so I can store elevation data from
> > > different sensors.
> > > If anyone has any comments on whether or not they think I can adapt
> > > GDAL to this purpose, I would very much appreciate it.
> > >
> > > Thanks!_______________________________________________
> > > Gdal-dev mailing list
> > > Gdal-dev at xserve.flids.com
> > > http://xserve.flids.com/mailman/listinfo/gdal-dev
> >
> >
> >
> 
>