Deprecate getDriverByName() about node-gdal HOT 9 CLOSED

👍 - would love to see a comparison of how shapely/fiona handle this.

from node-gdal.

@springmeyer Shapely doesn't know of drivers (or projections), it's 2D geometry algorithms only.

Fiona and Rasterio by design don't have any driver objects in their interfaces. Drivers are referred to by their string names only when needed. To open a shapefile for writing with Fiona:

import fiona
with fiona.open('file.shp', 'w', driver='ESRI Shapefile') as destination:
    ...

I've never seen Python OGR code that used driver objects for anything other than opening a file, e.g. http://pcjericks.github.io/py-gdalogr-cookbook/vector_layers.html#iterate-over-features. And since the generic ogr.Open() is equivalent to driver.Open(), I've found the existence of driver objects to be pointless and distracting.

Of course, I think it's okay for node-gdal to make other design decisions.

from node-gdal.

Shapely doesn't know of drivers (or projections), it's 2D geometry algorithms only.

Whoops, sorry meant to say "Rasterio/Fiona".

fiona.open('file.shp', 'w', driver='ESRI Shapefile')

Nice, this feels very similar to the new GDAL 2.0 OpenEx function as part of http://trac.osgeo.org/gdal/wiki/rfc46_gdal_ogr_unification.

from node-gdal.

re-reading this. My sense is:

1. Supporting gdal.open and ogr.open without first creating a driver is great. node-gdal already allows this and its looking good. Accessing ogr like require('../lib/gdal.js').ogr also seems fine for now.
2. After that the only meaningful purpose of drivers is for actions like createCopy and copyFiles, and rename. I think exposing these off of the main gdal object would be fine instead of requiring a driver instance.

So, I propose removing src/gdal_driver.cpp and src/gdal_driver.hpp and the corresponding tests. Then this ticket can be closed and getDriverByName will not be in the public api anymore.

Also as context, I've learned from @sgillies that the reason for supporting the with rasterio.drivers(): syntax in rasterio is to be able to have a block of code that supports custom error handlers and custom gdal config options. Something like this could be added later but I don't think its needed at this point. Also how it plays with threads is an open question we are researching.

from node-gdal.

@springmeyer right, to have a lightweight and limited runtime. In Javascript, this is better done using an anonymous function, right?

> var gdal = require('./lib/gdal.js')
undefined
> var filename = "/Users/sean/code/rasterio/rasterio/tests/data/RGB.byte.tif"
undefined
> (function() {
... // set GDAL options and error handler
... var width = gdal.open(filename).getRasterXSize()
... // unset GDAL options and error handler
... return width
... })()
791

from node-gdal.

@sgillies I'm not sure this is applicable, given that GDAL in Node won't always be sync like it is in Python. Even if it is sync, people can mix it with async application code.

If we need different contexts, we'll need to implement something along the lines of:

var gdal = require('gdal').context();

And then you can pass gdal around your application (DI style). But I'm not sure what that is good for – and it'd messy the internals. Sorry if I'm misunderstanding!

from node-gdal.

For now, what about going with a global EventEmitter. Users would be able to listen/unlisten and do what they want with error messages.

gdal.on('error', function(message) { });
gdal.on('warning', function(message) { });

from node-gdal.

It strikes me that error context creation would happen within an given async function. So the error handler would be added in the c++ internals of gdal.soSomethingAysnc(cb) and then released so that cb(err) would return the GDAL error. But we need to test this.

from node-gdal.

Added driver collections with this commit : f59d8de

gdal.drivers.count()
gdal.drivers.get(name | id)
gdal.drivers.getNames()
gdal.drivers.forEach(callback)

Also made gdal.open() more like GDALOpenEx and fiona.open

gdal.open(filename, mode, drivers, ...);
//examples
gdal.open(filename, 'r', ['ESRI Shapefile', 'GeoJSON']);
gdal.open(filename, 'w', 'ESRI Shapefile');

from node-gdal.