Opened 13 years ago

Closed 13 years ago

#4016 closed enhancement (fixed)

Implement OGRLineString::getPoints() method for the Java bindings

Reported by: Marvin Owned by: Even Rouault
Priority: high Milestone: 1.9.0
Component: SWIG (all bindings) Version: unspecified
Severity: normal Keywords: getPoints() Java bindings

Description (last modified by Marvin)


I have noticed that reading all the points of a polygon or line feature into an array of doubles is very costly with the Java bindings, since the only way of obtaining point coordinates directly is by using the org.gdal.ogr.Geometry.GetPoint() method. This means that to obtain all points of the geometry, one has to invoke GetPoint() for each and every point, and at every invocation of GetPoint(), Java has to make a single access to the native GDAL/OGR library, only to get a single point. The penalty for this is very high if you are dealing with very detailed polygon or line features with many points.

It would therefore be great if someone could implement the OGRLineString::getPoints() method for the Java bindings, so one can get all of a geometry's points in one single command and in one single access of the data source in an array of doubles.

Currently, one can only use the workaround of parsing the Wkb representation obtained by Geometry.ExportToWkb().

Thanks Marvin

Change History (11)

comment:1 by Marvin, 13 years ago

Description: modified (diff)

comment:2 by Marvin, 13 years ago

Description: modified (diff)

comment:3 by Marvin, 13 years ago

Description: modified (diff)

comment:4 by Even Rouault, 13 years ago

Component: JavaBindingsSWIG (all bindings)
Milestone: 1.9.0
Resolution: fixed
Status: newclosed

r22044 /trunk/ (12 files in 9 dirs): Add OGR_G_GetPoints(); Map it to SWIG in Geometry.GetPoints() (only available for Python and Java for now) (#4016)

Online Javadoc updated :

comment:5 by Marvin, 13 years ago

Thanks for your quick handling of the ticket.

I'll need to get back to this later once ticket #4075 is successfully resolved. At that point you may no longer need to limit the applicability of this function to wktLineString and wktPoint.

comment:6 by Marvin, 13 years ago

Hmm...where are the new Java 1.9.0 bindings libraries now that implement getPoints()? I can't find them on any of your official sources mentioned at

The "minimalist" package only goes till 1.7, but no Java bindings anyway:

FWTools does not use any Java bindings (installed and checked):

Geoinformatika (MinGW) is of March 16th only and no bindings either (installed and checked):

Tamas Szekeres keeps compiling the 1.8 version only:

MapServer doesn't seem to use bindings (no Java bindings in the ZIP):

OSGeo4W is still working with the 1.8 bindings, too (see the installer dialog list for package selection):

Checking your official GDAL Java bindings page:

The Image I/O-Ext - which is supposed to be the No 1 resource for the Java GDAL bindings binaries (since it is the only binary link referenced on your official GDAL Java bindings page) - never provided a single gdal.jar, but only lots of confusing imageio jars. Anyway, included them all in my Eclipse project with the newest version, but still no getPoints() (hence obviously no update to 1.9):

The last option - compiling from source - is described in your manual:

It asks you to download the latest GDAL sources from here:

which are of January 2011 only. This definitely means no getPoints() in Java either, since this has just recently been added less than two months ago.

I'm very glad you managed to fix this so quickly but what good does it make if not even the sources of that new implementation are published anywhere? Not to talk of the binaries?

I think the best thing would be to provide a direct link to a ZIP file on your official Java GDAL bindings page: That ZIP should contain the latest gdal.jar possible, and all required dlls. Plain and simple. It is very confusing if not even the official Java bindings page provides what most people look for and would expect there, but instead only references an endless web directory tree on the Image I/O-Ext page with only loads of imageio jars for download at its end.

Thanks Marvin

comment:7 by Marvin, 13 years ago

Resolution: fixed
Status: closedreopened

comment:8 by Even Rouault, 13 years ago

Could you please avoid mixing things ? How to compile/get a developement version doesn't belong to a track ticket. When you want to use a bleeding edge version, you're supposed to make some efforts... Anyway you can use the -devel package from Tamas site (to be opposed to the -stable ones). They track the SVN HEAD version (1.9.0dev). Or just svn checkout and compile by yourself. By the way, Image-IO Ext is not a recommended or "No 1 resource" or endorsed in any way. It is just a "useful link".

/me a bit grumpy by your tone...

comment:9 by Marvin, 13 years ago

Great! Thanks very much, that devel package from Tamas did it! I can finally see getPoints() popping up in my Eclipse code assist.

I am sorry for sounding a little rude, I was just a little frustrated with all my failed attempts to get it work.

I believe you guys are really doing great work and saving millions of people a lot of nerves and time, and largely contribute to the fact that developing GIS-related applications is so convenient and enjoyable today. Projects like GDAL show the world that it doesn't take a millionaire with highly expensive equipment but simply a genius to strongly influence all spatial activities on this planet and beyond.

I myself as an application developer wouldn't have the patience to occupy myself with developing just the library, focusing on all kinds of possible uses by other people, but not having my own personal and concrete end-user product at heart. But I'm all to happy that GDAL exists and just needs to be used.

As for the Image-IO Ext, I was just initially confused with that resource and thought it was the official "release package" of the Java GDAL bindings binaries, since it was the only binary link presented right on the "home page" of the Java bindings. Until Tamas some time ago told me that the real package is elsewhere.

One last thing: The Javadoc says that getPoints() only works for 25D versions of wkbPoint and wkbLineString. There is no equivalent comment on OGRLineString::getPoints() and no implementation of OGRPoint::getPoints(). So:

1.) May I assume that the "[25D]" (in brackets) should mean "wkbPoint OR wkbPoint25D", same story for wkbLineString?

2.) If the geometry is a point, I expect that it returns a double[1][2 or 3], am I right?

I'm sorry, I hope I'm not becoming a pain in the neck ;-) But I think this ticket is coming to a final close.

Thanks very much for your help Marvin

comment:10 by Even Rouault, 13 years ago

Yes, you guessed right. wkbPoint[25D] means wkbPoint OR wkbPoint25D. And if the geometry is a point the array will be a double[1][2 or 3].

I've added a link to Tamas builds in Remember this is a wiki: you can help improving it.

comment:11 by Even Rouault, 13 years ago

Resolution: fixed
Status: reopenedclosed

Closing. The subject of this ticket "Implement OGRLineString::getPoints() method for the Java bindings" has been dealt with.

Note: See TracTickets for help on using tickets.