Cleaning up geometry objects about node-gdal HOT 5 CLOSED

👍 Let's aim higher than the C API. Those Python bindings are especially grim when dealing with Polygons.

from node-gdal.

I'm really glad someone has time to work on this :)

If the goal is to add JS sugar to the API, one approach would be to put the sugar in a different layer of the bindings. As in, implement the bare metal in C++ and write the actual public API in JavaScript. I think it's best, in general, if only the absolute minimum is done in native code so it reduces the complexity of the native code and the JS sugar doesn't have to be written in C++. Or it could be done with a mixture of both exposed native objects and some JS code to do things like property accessors and small transforms.

Anyways, just my 2 cents, great work!

from node-gdal.

Hey Zac! First of all, thanks a ton for all the work you put into the OGR bindings. It saved a bunch of time not having to make the GDAL bindings from nothing. We will make sure to credit you in the main readme. Since I copied the node-ogr files into node-gdal repo, it unfortunately scrubbed you out as a contributor.

I like the idea of doing the tasteful sugar in JS whenever reasonable. Example:

module.exports.ogr.Feature.prototype.getFields = function() {
    var i, n, values, field_name;

    n = this.getFieldCount();
    values = {};
    for (i = 0; i < n; i++) {
        field_name = this.getFieldDefn(i).getName();
        values[field_name] = this.getField(i);
    }
    return values;
};

There will be cases where putting the sugar in C++ would be good if doing it JS would hurt performance too much. (The example above might be one)

I think the bindings should still feel like GDAL. We should add just enough sugar to make it intuitive for a JS programmer, but not add so much that it creates a nightmare when converting a GDAL/OGR script from python or C++ to JS.

from node-gdal.

Great thinking @brandonreavis. Great to see you here @zhm!

from node-gdal.

Alright the better constructors are now functional after these commits (dfd074e, 391348b)

Using distinct geometry subclasses (ie. Point, Polygon, ...) helps with a few things

• No need call getGeometryType() in every method binding.
• instanceof operator can be used to check geometry types instead of calling getGeometryType and comparing it with the wkbGeomType enum

I also moved the bound OGRGeometryFactory methods to be static Geometry methods in JS.

> pt = ogr.Geometry.createFromWkt("Point(10 20)")
{ z: 0, y: 20, x: 10 }
> pt instanceof ogr.LineString
false
> pt instanceof ogr.Point
true
> pt instanceof ogr.Geometry
true
> pt.x *= 10
100
> pt2 = new ogr.Point(pt.x*10, pt.y*10)
{ z: 0, y: 200, x: 1000 }

Still need to think about how to clean up the rest of the geometry types.

from node-gdal.