-
Notifications
You must be signed in to change notification settings - Fork 142
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
OSSIM 1.8.20-3 fails to build with GEOS 3.6.x (and needs to switch to the GEOS C API) #79
Comments
|
I took a look and switching all to C-API seems to be a non-trivial task (but still worth doing). Tweaking the use of C++ interface would require defining a "GeometryFactoryPointer" type to be either what it is currently ( the auto_ptr ) or the new |
|
I have been unsucessful in moving parts of ossimPolyArea2d to geos C api.
iwiI admit that. But haven't given up yet..
I will give another try in the next weeks. For now I had only problem with
getEvelope and getEvelopeInternal method
@sandro, can you help in finding the C api equivalent of that. Maybe I am
missing something obivious here or am just lazy to find the correct
documentation.
…On Sat, Dec 24, 2016 at 12:38 PM, Sandro Santilli ***@***.***> wrote:
I took a look and switching all to C-API seems to be a non-trivial task
(but still worth doing).
Tweaking the use of C++ interface would require defining a
"GeometryFactoryPointer" type to be either what it is currently ( the
auto_ptr ) or the new GeometryFactory::unique_ptr depending on GEOS
version.
Then Factory creation would need to be done via GeometryFactory::create()
with 3.6+
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#79 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ACSNO59Hgjj51bwlpKL5vbLJHGEVjkBzks5rLViugaJpZM4LVQYz>
.
--
Regards,
Rashad
|
|
You obtain a geometrical representaition of an envelope with this:
extern GEOSGeometry GEOS_DLL *GEOSEnvelope_r(GEOSContextHandle_t handle,
const GEOSGeometry* g);
It'll return a point for single-coordinate input, an empty geometry
for empty input and a polygon for all other inputs.
HINT: use the re-entrant API, and to help with that
#define GEOS_USE_ONLY_R_API 1
|
|
On Mon, Dec 26, 2016 at 6:38 PM, Sandro Santilli ***@***.***> wrote:
You obtain a geometrical representaition of an envelope with this:
extern GEOSGeometry GEOS_DLL *GEOSEnvelope_r(GEOSContextHandle_t handle,
const GEOSGeometry* g);
It'll return a point for single-coordinate input, an empty geometry
for empty input and a polygon for all other inputs.
HINT: use the re-entrant API, and to help with that
#define GEOS_USE_ONLY_R_API 1
okay. I was not using rentrant api. current code is using C methods without
"_r" Which I assume is not re-entrant.
I have to change all to use methods with "_r" suffix right?
—
… You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#79 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ACSNOywSQKKh2acMUraMQd7DSWNOQ9TXks5rMFAOgaJpZM4LVQYz>
.
--
Regards,
Rashad
|
|
On December 27, 2016 2:00:40 AM CET, Rashad ***@***.***> wrote:
On Mon, Dec 26, 2016 at 6:38 PM, Sandro Santilli
***@***.***>
wrote:
> You obtain a geometrical representaition of an envelope with this:
>
> extern GEOSGeometry GEOS_DLL *GEOSEnvelope_r(GEOSContextHandle_t
handle,
> const GEOSGeometry* g);
>
> It'll return a point for single-coordinate input, an empty geometry
> for empty input and a polygon for all other inputs.
>
> HINT: use the re-entrant API, and to help with that
>
> #define GEOS_USE_ONLY_R_API 1
>
okay. I was not using rentrant api. current code is using C methods
without
"_r" Which I assume is not re-entrant.
I have to change all to use methods with "_r" suffix right?
—
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub
>
<#79 (comment)>,
or mute
> the thread
>
<https://github.com/notifications/unsubscribe-auth/ACSNOywSQKKh2acMUraMQd7DSWNOQ9TXks5rMFAOgaJpZM4LVQYz>
> .
>
Yes
--strk;
Sent from hand-held device, sorry for brevity
|
|
I think this one should now be fixed |
|
Changed to derive from the factory for the factory items are now protected. |
|
Is there an ETA for a new OSSIM release which will include this change? The 1.8.20-3 release was 1,5 years ago. |
|
The latest OSSIM was fixed for the geos build errors |
|
The latest OSSIM release is still 1.8.20-3, that doesn't include this fix. Since that release is 1,5 years old I'm wondering about the plans for the next release, when we can expect that. The Roadmap in Trac are no longer maintained and the Milestones supported by GitHub aren't used. Based on the activity in Trac the OSSIM project seemed dead. The activity in this repository proves that it is not dead, but doesn't inform users nor distributors about planned releases. |
|
Hello, We have moved away from TRAC and we now maintain bugs, enhancements, ... etc via JIRA. This is a private tracking system but if issues are added here in github we usually can add some to the next "sprint" cycle during the code development process. So basically we do work in the "dev" branches under ossimlabs for four weeks and these have continuous tests that are ran on bugs we had in the past to make sure they are verified then at the end of the cycle we merge into master and run the same tests again. I will bring up in the next planning a public source upload so people can easily download a tarball. For now you must clone the master branch. |
|
Having a private issue tracker is worrying for an open source project. Why not use the GitHub milestones (in addition)? |
With the release of GEOS 3.6.1 this issues gains more relevance.
As reported in Trac #2382:
The text was updated successfully, but these errors were encountered: