On Wednesday 07 December 2005 04:19, Hamish wrote:
> > As of my current Knowledge the GDAL library can also access Vektor
> > Data via the GRASS Module.
>
> well, yes it can, but this probably isn't what you need. GDAL bundles
> OGR, which like GDAL is a multi-format spatial data toolkit, but for
> vector data not raster data. (ie OGR gives you access to TIGER, Vmap0,
> Shapefiles,..)
So for the first part it might be sufficient to use GDA+OGR.
And Yes I was hoping to be able to use the TIGER maps with the Help of these
libraries ;-)
> The main (non ascii) GRASS import/export data modules are really just
> front-ends to GDAL and OGR. (r.in.gdal, v.in.ogr, v.out.ogr; r.out.gdal
> is infact just a small shell script which calls gdal_translate to
> convert from GRASS raster format to *). GRASS also includes other data
> format filters (3D, SRTM*, custom, ...) that GDAL/OGR doesn't.
So I'll have to see which format will be sufficient for gpsdrive and then
decide if I'll use OGR or Grass.
> [*] SRTM 90m worldwide topographic data: http://www2.jpl.nasa.gov/srtm/
> Download 1 degree chunks (111km^2) from 60N to 60S, more detail than
> blue marble...
This sounds nice too.
I heard from another download of Satelite fotos which is 88 GB in total. As
soon as I have enough diskspace I'll try these too.
> So if gpsdrive gets GDAL/OGR support, you don't need to worry about
> GRASS. GRASS 6.1's d.out.gpsdrive is still nice for making custom
> backdrop images of course.
>
> best to reuse an existing GDAL format I think, then there is no
> additional work to do. Existing maps could be accessed by a script which
> calculated the four corner coords from the center & scale factors..??
in the Version found here
http://ostertag.name/gpsdrive/tar/gpsdrive-2.10pre3-lib-map-version.tar.gz
you have worldgen, which takes a map_koord.txt file and generates *.wld files.
I think that is what we need to get the new format established. As soon as
GDAL is working with gpsdrive I'll add it directly into the gpsfetchmal.pl
script.
...
> So GpsDrive data <-> GIS data is already pretty easy in both directions.
>
> also a gpsbabel xcsv filter would be really easy to write if you want to
> go directly to a shapefile for example.
I am not really concerned about converting the different formats. It's nice if
I can build on existing scripts there, but it'll be really easy to use perl
for this too.
> PostGIS DBs etc, should be able to be linked to with v.external directly
> and "just work". (live filtering by OGR library)
> Also GRASS's v.in.db DB->vector module currently reads dbf,odbc,pg,ogr,
> just tell it the x,y,z,etc column names to use.
This is more the part i was interested in. Getting the data from Harddisk to
memory; so that I can display them more easily.
> so the road ahead could be much simpler than we think if we play our
> cards right...
Sound good.
So what do you think is it the right way to start with a simple gdal
implementation like the one above and then expand it peace by peace?
-
Joerg
--
This message was part of the gpsdrive mailinglist
unsubscribing can be done by sending a mail containing a body of:
-quote--
unsubscribe gpsdrive
-unquote--
to majordomo-ahljRfkWE0EwtzFM8z8+AfP6llvjuJOh@xxxxxxxxxxxxxxxx
|
