Cool! Sounds like a great way to go...
Larry Becker wrote:
> >Perhaps this could be done by simply making OS external
> >process calls, rather than in-process bindings to the library?
>
> That is actually the path I'm investigating now. The import utility
> would just script ogr2ogr to put the r
>Perhaps this could be done by simply making OS external
>process calls, rather than in-process bindings to the library?
That is actually the path I'm investigating now. The import utility would
just script ogr2ogr to put the results as shapefiles in a temp folder.
Larry
On Fri, Feb 20, 2009 at
Yep, I'd agree. And for something so core to the application, I think
it's really important to preserve the 100% Java aspect, with all the
benefits of platform-independence that it brings.
Plus all that JNI hacking - brr!
Format transformation is less core to the architecture, so it doesn'
Jewish Defence League Protest at CUPE Ontario Conference - FEB 22 2009
For more information please call 416-736-7000 or online at jdlcanada.ca
Become A MemberDonate To The JDL Issue Date: Feb 21 2009
Main
Parsha of The Week
Notices and Upcoming Events NEW!
This weeks Torah Pars
Hi Larry,
My impression of using GDAL/OGR in a java application is that you need
to build the c
code for a specific platform using some sophisticated tool for the
platform (ie Visual Studio 8 or something like that).
Maybe it's possible using Netbeans or other env for other environments,
but y
Hi Stefan,
Yes, it would be an interface to an external native-code library. As you
know, we do this already with ECW and MrSID. I think it is OK as long as
the code is cross-platform (which I believe GDAL/OGR is).
Larry
On Thu, Feb 19, 2009 at 10:31 PM, Stefan Steiniger wrote:
> Hei,
>
> w
