Tyler,

A while back I had a need to access (by Mapserver) points stored in a non-spatial SQL Server database. I was able to use OGR's VRT to access the data, and while the example below shows a datasource connection of ODBC, you may be able to use an Oracle OCI connection instead:

    <OGRVRTDataSource>
        <OGRVRTLayer name='wells'>
<SrcDataSource>ODBC:auser/apass@dsname,Wells_view</SrcDataSource>
               <SrcSQL>SELECT * FROM  Wells_view WHERE
SurfaceLongitude &gt; -117.684 AND SurfaceLongitude &lt; -117.682 AND SurfaceLatitude &gt; 52.499 AND SurfaceLatitude &lt; 52.5</SrcSQL>
            <GeometryType>wkbPoint</GeometryType>
            <LayerSRS>NAD83</LayerSRS>
<GeometryField encoding='PointFromColumns' y='SurfaceLatitude' x='SurfaceLongitude'/>
        </OGRVRTLayer>
    </OGRVRTDataSource>

Actually, I'm a little confused by the GeometryType and GeometryField tags in the above example; you may need to experiment.

I've also constructed views in the database, basically reformatting the lat/lon columns into WKT format to do:

    <OGRVRTDataSource>
        <OGRVRTLayer name='vWM_UserGraphics'>
<SrcDataSource>ODBC:auser/apass@dsname,vWM_UserGraphics</SrcDataSource>
<SrcSQL>SELECT WKT,PropertyID,GeomType,GeomID,LayerName,ClassName,Label FROM vWM_UserGraphics
                    WHERE  PropertyID=%PropertyID%
                    AND    GeomType = 0
            </SrcSQL>
            <FID>geomID</FID>
            <GeometryType>wkbLineString</GeometryType>
            <LayerSRS>NAD83</LayerSRS>
            <GeometryField encoding='WKT' field='WKT'/>
        </OGRVRTLayer>
    </OGRVRTDataSource>

Note the "%PropertyID%" string is a Mapserver runtime substitution done before OGR gets the VRT definition so not very useful in your case (but it might give you a few ideas).

Hopefully I've understood at least some of what you are trying to accomplish. At first I thought you wanted a GDAL VRT that defines a raster, referencing an OGR VRT as the source data and defining a method of producing a grid. Yikes!

Best Regards,
Brent Fraser

On 12/20/2012 12:50 AM, Tyler Mitchell wrote:
On 2012-12-19, at 10:54 PM, Even Rouault wrote:
Le jeudi 20 décembre 2012 02:08:01, vous avez écrit :
Hi all, does anyone know a way to put up a GDAL VRT fed by an OGR
datasource that has data in XYZ format (regular gridded) .

It doesn't have to ultimately be a VRT, just some similar on-the-fly raster
format method, so I can share raster data directly from the OGR
datasource.  I've been digging around and saw wkt raster/postgis raster
but it's really a little different than this approach as it doesn't use
arrays.

I can share more but thought I'd keep it simple first ;-)
Tyler,

There's a GDAL XYZ driver, but it has very strict requirements :
http://gdal.org/frmt_xyz.html

Otherwise you can use the OGR CSV driver (make sure the file extension is
.csv), wrap it in a OGR VRT, and then ingest that in gdal_grid to produce a
raster. But that's not really on-the-fly.
Hi Even,
Thanks for the tips

I'm so close .. thanks to the XYZ driver which I've been using a lot lately, 
since
I can input/output CSV and both GDAL and OGR can read it, but yeah, GDAL can't
read it directly from the db source.

My challenge is now to make it pull the CSV from the db in real-time via a VRT.

(Actually I'm sure I can do it with a SQL statement in a VRT, my db is just not
cooperating at the moment, since it's a non-spatial version of the Ingres db
and the OGR driver is looking for geometry_columns table and bails out.)

But, yeah it's still not on-the-fly from a GDAL raster perspective.  I assume 
some
of the other drivers (DODS?) do have a similar mechanism to deal with grids in
databases?

Isn't there some fancy bash scripting that can be done to masquerade an OGR
VRT/script as a virtual file - e.g. it looks like a data file but it's really a 
realtime script
inside it.  Which leads me to wonder if there are ways to pipe CSV data into 
gdalinfo/translate?

Hm... thanks again, I'll keep pick away on it when I have time.  A generic 
gdal-ogr
CSV bridge driver would be cool!

Some for rambling, it's getting late ;)

Tyler

_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev



_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Reply via email to