ogr2ogr: allow/store dst_datasource_name for output

[disarticulate]

So ogr2ogr is generally:
ogr2ogr [options] dst_datasource_name src_datasource_name [layers]

and the current api is:

dataset // src_datasource_name
options // options
const filePath = await Gdal.ogr2ogr(dataset, options)

For certain conversions or operations, a dst_datasource_name can be updated with option switches like -append/-overwrite/-update.

Current behavior appears to directly create the output name as the input name, which prevents a one to many relationship, particularly when using the -sql switch which operates and generates a layer.

I'd recommend the following api if it can be mapped easily to the current:

Gdal.ogr2ogr(dataset, options, [output_name])

I think the substantial API dillema is whether that output_name include the /output/* directory prefix but since the return file is the defacto working object, I think just allowing arbitrary output names then returning the location to the dataset fullfills the current contract without breaking how workflow occurs.

[bugra9]

Hi @disarticulate,

I added the "outputName" param to ogr2ogr, gdal_translate, gdalwarp and gdal_rasterize.
https://gdal3.js.org/docs/module-a_ogr2ogr.html
https://gdal3.js.org/docs/module-a_gdal_translate.html
https://gdal3.js.org/docs/module-a_gdal_rasterize.html
https://gdal3.js.org/docs/module-a_gdalwarp.html

Will it work?

[disarticulate]

This does appear to work.

A follow up question: when the dataset is closed, it still exists. How do we flush the fly? It looks like we need acceess to a FS.unlink in emscriptem. In general, it'd be nice to have access to the FS for pre- and post- processing activities.

Do you want me to open a separate issue?

[bugra9]

I have exported FS for the issue (#67). It can be used as specified there.

I'm also thinking of removing the virtual filesystem in node.js for the next version of gdal3.js (3.0.0). If you're using it on node.js, you might not need it.

V3.0.0 PR: #82