Consider targeting GDAL 2.0 about node-gdal HOT 5 CLOSED

Nice. Any ideas on when 2.0 will be released?

I've been thinking about the node-gdal / node-ogr issue quite a bit the last few days after going down the gyp rabbit hole (and discovering how gcore depends partly on both raster and vector features). I hadn't seen that link though. If the GDAL crew is considering merging the two, I don't see why not to do the same with binding. It saves the hassle of duplicating the GDAL source in two different repos (or splitting it out so that node-ogr and node-gdal can share it).

The gyp build currently works for Linux (precise), OSX, and Windows. It seems to run well and tie in nicely with the binding build, but if we want to gut it at some point in favor of GDAL's makefile setup, I'm all for that.

from node-gdal.

Nice. Any ideas on when 2.0 will be released?

No, but /cc @rouault who will have a sense. I started taking a closer look at the changes yesterday as I got Mapnik building against master gdal: mapnik/mapnik#2259. They are fairly minor, so it seems pretty doable actually to target both GDAL 2.0 and previous. My first read of the RFC gave me the incorrect sense that the changes were major in the sense that you'd have difficulty targeting both versions.

I've been thinking about the node-gdal / node-ogr issue quite a bit the last few days

Yes, I'm +1 still on merging node-gdal and node-ogr for the following reasons:

1. Less work: maintain one thing
2. Like you say: for gyp/binaries packaged with node-pre-gyp, less size to download
3. This would dodge the scary situation where node-gdal and node-ogr both call GDAL's global register functions and things crash or experience thread deadlocking. I don't have any hard evidence of this yet, but I've seen how these two global statics in mapnik have caused bad behavior when two node-mapnik installations end up the the node_modules tree: basically font registration breaks.
4. Possibility for cleaner, more opinionated API's in the future that might do cool stuff with both vectors and rasters.

So, my takehome is:

1. node-gdal should suck in node-ogr
2. GDAL master should be sucked into the gyp build
3. This will allow the GDALOpenEx API to start being targeted.

from node-gdal.

The gyp build currently works for Linux (precise), OSX, and Windows. It seems to run well and tie in nicely with the binding build.

Cool very valuable thing to have working - did'nt even consider this could be pulled off :) One question: the --with-threads option is pretty critical to build GDAL with. Any idea if that gets respected in your gyp build? Answered my own question: it is respected:

but if we want to gut it at some point in favor of GDAL's makefile setup, I'm all for that.

I've hacked a bunch at GDAL's makefile setup to limit the # of drivers it builds to save space. Most recently with this I'm down to an 8.3 MB libgdal.a. This along with header files gets posted to the Mapnik SDK tarballs at http://mapnik.s3.amazonaws.com/index.html?path=dist/dev/ each commit to mapnik-packaging. One possibility would be to have the mapnik-packaging scripts post just the GDAL stuff and then have the node-gdal build pull down a binary libgdal.a for each platform. I've been working with @BergWerkGIS to offer binary tarballs of minimal gdal for windows as well, scripted on appveyor.

from node-gdal.

GDAL and OGR are moderately intertwingled already. For example, the MBTiles (raster) driver requires OGR's spatiallite (vector) features. I made Fiona and Rasterio (the Python analogs of node-ogr and node-gdal) different packages because I'm of the pay only for what you eat camp, but sometimes the separation seems a little pointless. I'm +1 on combining.

My $.02 on interface compatibility: let's make the interface we want for ourselves now and hide the differences between GDAL 1.x and GDAL 2.0. If we're going to vendorize GDAL anyway and not use the system one, we're completely free to do this. The GDAL and OGR APIs are for C programmers, and not APIs we necessarily want to surface for Javascript.

from node-gdal.

Reviewed this ticket and closing as I think we're all good here. Agree 100% with @sgillies summary comments above. So, in summary:

• merging node-ogr into node-gdal makes sense and is already in progress (b4997cf). Details of implementation being tracked at #10 and #14.
• Targeting 2.0 is a minor issue of #ifdefs when we get there. So, I don't think we need to actually use or support GDAL 2.0/master yet.

from node-gdal.