[gdal-dev] OGR XYZ -> GDAL VRT?

[Brent Fraser]

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 at dsname,Wells_view</SrcDataSource>
                <SrcSQL>SELECT * FROM  Wells_view WHERE
                 SurfaceLongitude > -117.684 AND SurfaceLongitude 
< -117.682 AND
                 SurfaceLatitude > 52.499 AND SurfaceLatitude < 
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 at 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 at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>