[Gdal-dev] GDAL As A Local Map?
tjmitchell at riverside.bc.ca
Fri Aug 13 11:05:19 EDT 2004
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
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.
"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
> of its surroundings (laser range finders, stereovision systems) which it
> will then transform into UTM coordinates. We may also add a layer where
> robot uses other sensors to classify different elevations as certain
> of terrain (road, rocks, plants, water, etc.) To make path-planning
> we will probably combine this data into a "cost map" where the value of
> 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
> thousands or even millions of elevation points per second) which can
> read, converted to a cost (which is an algorithm we already have) and
> read again to do the path-planning. It's not so much for human viewing
> 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
> the capability to somehow scroll the map as the robot moves without
> time-expensive data copying.
> Does this information help any? If not, let me know and I can go into
> 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
> > coordinates)? Or is it going to need to create imagery?
> > Are you aiming to have a desktop mapping program that can show its
> > 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
More information about the Gdal-dev