Hello All,

Although Kris no longer works for our group, we're still interested in 
the problem.  Is it possible the patch as proposed could be modified to 
work w/ the new 2.4/2.5 release?  If so, is the approach acceptable?

Thanks!

--john


Andrea Aime wrote:
> Mateusz Loskot ha scritto:
>
>   
>> I see. I hoped there has been something done after I saw this ticket
>>
>> http://jira.codehaus.org/browse/GEOT-393
>>     
>
> Unfortunately not... that issue is 3 years old, so I guess
> all hope to get back whatever work people did on informix is lost.
>
>   
>>>> I'm looking for a solution to build a solution based on GeoServer and 
>>>> GeoTools to access feature data stored in Informix database.
>>>>
>>>> I'd be thankful if anyone could enlighten me about Informix support
>>>> status in GeoTools and what's recommended solution in this matter.
>>>>         
>>> Well, I guess you can follow two different paths:
>>>       
>>  >
>>     
>>> * build a pure java module. This, properly coded, should give you
>>>   better speed and less cross platform headaches, but the datastore
>>>   API is in a state of flux at the moment so you may have to
>>>   adjust the results of your work later
>>>       
>> Sounds as the most reasonable approach.
>> When the API freezing is expected?
>>     
>
> API on 2.4.x is frozen, but various changes are occurring on
> trunk, where we're trying to setup the stage for complex
> feature support. Not sure when the api will freeze there.
>
>   
>>> * complete my abandoned OGR datastore (located in   
>>> module/unsupported/ogr) and leverage the OGR support
>>>   for Informix datablade in OGR to connect to the database.
>>>       
>> Yup, I've been considering it.
>> One of the pros is that OGR supports Informix spatial features.
>> However, cooking Java bindings for OGR is not very encouraging
>>     
>
> Yeah, it has been a pain for me to try and maintain the gdal/ogr
> bindings. Yet, given your much stronger c/c++ background, you may
> have better luck.
>
>   
>>> Just a bit of warning. Using OGR in GeoServer is a whole
>>> different story than using it in MapServer. In GeoServer the OGR
>>> library will be loaded once and then used for days or months.
>>> A single memory leak and you're doomed. A single segfault and
>>> the whole virtual machine goes bye bye. You'll have to make
>>> sure the code is picture perfect or you'll end up with a pretty
>>> unstable GeoServer install.
>>>       
>> Understood. I'm wondering, is it common in the world of FOSS GIS
>> solutions based on Java to use GDAL/OGR? If not, should I assume
>> because of the problem you're emphasizing above?
>>     
>
> No, not common at all. It's not only the problems I'm emphasizing
> above, otherwise we'd see more java desktop based apps using gdal and
> ogr. It's also the multiplaform build, multi-compiler issues, that
> shy away the average java developer, who chose a certain technology
> exactly to avoid that kind of issues (and memory management ones,
> and the nightmare of linux packaging for a billion distributions,
> and so on).
>
> That said, we have a group of people adding support for gdal
> using a patched gdal 1.4.2 in order to leverage formats as ecw
> and mrsid exactly for GeoServer, and they are happy with the
> result. Probably my opinion is biased by the hard time I had trying
> to build the OGR datastore, keep up with the OGR java bindings
> on windows without the microsoft compilers, and by the number
> of JVM I destroyed due to minor issues either in the bindings
> or in the java code. Way too painful to justify spending my
> spare time on it, spare time coding must be fun :)
>
> Cheers
> Andrea
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Geotools-gt2-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
>   

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Geotools-gt2-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users

Reply via email to