GeoTools

Create a datastore that uses OGR to access vector data

Details

  • Type: New Feature New Feature
  • Status: Resolved Resolved
  • Priority: Minor Minor
  • Resolution: Fixed
  • Affects Version/s: 2.1.M0
  • Fix Version/s: 2.7.5
  • Component/s: unsupported
  • Labels:
    None

Description

Using JNI is should be possible to wrap the OGR API to get a wider set of supported formats without the need to write a native java version for each.

See http://ogr.maptools.org

Ideas:

  • use the C wrappers to perform calls from JNI
  • probably the NIO native buffers should be used to get decent
    performance out of NIO
  • ideally the API should reduce the number of round trips between the native and Java side of the fence, since this is where JNI is costly

Issue Links

This issue relates to:
GEOT-500 Create GDAL binding Minor Closed

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Frank Warmerdam added a comment -
I would add that it is would be safest to interface via the OGR C API
rather than the C++ API. The C API is less fragile and allows a less
tight linkage between build of the JNI wrappers and the underlying
OGR library itself.

I am willing to provide some modest level of support from the OGR
side of things to a developer interesting in building this interface.
Ideally it could be done as an OGR specific set of Java classes
independent of GeoTools, and then I could include it with regular
OGR distributions and GeoTools would just need to implement a layer
type on the API.
Show
Frank Warmerdam added a comment - I would add that it is would be safest to interface via the OGR C API rather than the C++ API. The C API is less fragile and allows a less tight linkage between build of the JNI wrappers and the underlying OGR library itself. I am willing to provide some modest level of support from the OGR side of things to a developer interesting in building this interface. Ideally it could be done as an OGR specific set of Java classes independent of GeoTools, and then I could include it with regular OGR distributions and GeoTools would just need to implement a layer type on the API.
Hide
Permalink
Andrea Aime added a comment -
Uhm, it seems there's a lot of functions and structs to wrap...
probably using SWIG would help (http://www.swig.org/) but I fear that it would generate a too fine grained wrapper... probably better to code in C something that sits atop the public OGR C api and reduces the number of round trips (just an idea).
Show
Andrea Aime added a comment - Uhm, it seems there's a lot of functions and structs to wrap... probably using SWIG would help (http://www.swig.org/) but I fear that it would generate a too fine grained wrapper... probably better to code in C something that sits atop the public OGR C api and reduces the number of round trips (just an idea).
Hide
Permalink
Frank Warmerdam added a comment -
I see your point. At least I think we need something that could
return all the data for a feature in one JNI call.
Show
Frank Warmerdam added a comment - I see your point. At least I think we need something that could return all the data for a feature in one JNI call.
Hide
Permalink
Andrea Aime added a comment -
We now have a new datastore based on BridJ bindings that avoids the pesky requirement of manually building JNI bindings on each and every platform
Show
Andrea Aime added a comment - We now have a new datastore based on BridJ bindings that avoids the pesky requirement of manually building JNI bindings on each and every platform

People

Vote (2)
Watch (2)

Dates

  • Created:
    Updated:
    Resolved:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.