headers
Adam Mercer | 2 Mar 2008 01:49
Picon
Gravatar

Having geos 3.0.0 and 2.2.3 installed side by side

Hi

I'm trying to install both geos 3.0.0 and 2.2.3 side by side but am
running into problems. I need to keep 2.2.3 as it is needed by the
matplotlib basemap toolkit - it doesn't work with 3.0.0.

Does anyone know of a way to have both versions of geos installed at
the same time, without having to heavily patch the source code?

Cheers

Adam
Permalink | Reply | 1 comment |
headers
Mateusz Loskot | 2 Mar 2008 02:45
Gravatar

Re: Having geos 3.0.0 and 2.2.3 installed side by side

Adam Mercer wrote:
> Hi
> 
> I'm trying to install both geos 3.0.0 and 2.2.3 side by side but am
> running into problems. I need to keep 2.2.3 as it is needed by the
> matplotlib basemap toolkit - it doesn't work with 3.0.0.
> 
> Does anyone know of a way to have both versions of geos installed at
> the same time, without having to heavily patch the source code?

Adam,

You can install them under different prefix locations
and appropriately configure environment variables (PATH, 
LD_LIBRARY_PATH,etc.) for different client software.

Greetings
--

-- 
Mateusz Loskot
http://mateusz.loskot.net
Permalink | Reply | 0 comments |
headers
Russell Strong | 3 Mar 2008 10:43
Picon

bad input data or robustness issue?

Hi all,

I'm trying to dissect up a bunch of nearly round overlapping polygons, 
ie.. trying to find areas of overlapping radar coverage given a set of 
radar locations and ranges.

However, trying this with a few polygons, testing each case I can think 
of works very well.  Add a few more and I get all sorts of errors including:
* side location conflict
* stuck in endless loop ( due to intersect and difference operations 
that produce the same  polygons as we started with )
* non-noded intersection
* no outgoing dirEdge found

I've included some test code that shows all of these,  ( uncomment 
various tests in main ).  If anyone has some time to run these and 
comment I'd appreciate it.  I've spent 5 solid days on it and I'm out of 
ideas.

it basically works like this:

I keep a link list of "areas" which contain a geometry.  I then compare 
each geometry against each other ( except for self ).  If it intersects, 
I add the intersection and the 2 differences to the list (if they exist) 
and remove the source areas.  I keep going until I've compared every 
area against every other area and found no non-empty intersections.

One other thing that I found was the Overlaps can return true but the 
intersection of the two polygons returns true for isEmpty?!?!?  (I was 
using overlaps instead of intersects in the split_areas comparison)
(Continue reading)

Permalink | Reply | 5 comments |
headers
Martin Davis | 3 Mar 2008 22:16
Favicon

Re: bad input data or robustness issue?

As you've noticed, the predicates are not necessarily consistent with 
the overlay operations.  This is because the predicates are exact, 
whereas the overlay operations are approximate (which is unavoidable, 
since they operated in a finite-precision model).

So, don't rely on this in your code. If you determine that two polygons 
overlap, you still have to check for an empty intersection and handle it 
appropriately.  This should only happen when the area of overlap is so 
small as to be negligible, in any case.

Also, try using a limited-precision model.  Round of the numbers in your 
input, and use an explicit PrecisionModel to control the precision of 
the computed output.  This should increase stability.

It might also help if you checked the area of intersections and 
differences and eliminated ones with very small areas (since these 
should be below the accuracy of your input data in any case).

HTH - Martin

Russell Strong wrote:
> Hi all,
>
> I'm trying to dissect up a bunch of nearly round overlapping polygons, 
> ie.. trying to find areas of overlapping radar coverage given a set of 
> radar locations and ranges.
>
> However, trying this with a few polygons, testing each case I can 
> think of works very well.  Add a few more and I get all sorts of 
> errors including:
(Continue reading)

Permalink | Reply | 4 comments |
headers
Russell Strong | 5 Mar 2008 10:08
Picon

Re: bad input data or robustness issue?

I've had a look through the c api and it would appear that access to 
precision models is not exposed, unless it's disguised in a way I have 
not recognized.  Am I correct?  Is there some code that someone knows 
about which could give me some *pointers.

Martin Davis wrote:
> As you've noticed, the predicates are not necessarily consistent with 
> the overlay operations.  This is because the predicates are exact, 
> whereas the overlay operations are approximate (which is unavoidable, 
> since they operated in a finite-precision model).
>
> So, don't rely on this in your code. If you determine that two 
> polygons overlap, you still have to check for an empty intersection 
> and handle it appropriately.  This should only happen when the area of 
> overlap is so small as to be negligible, in any case.
>
> Also, try using a limited-precision model.  Round of the numbers in 
> your input, and use an explicit PrecisionModel to control the 
> precision of the computed output.  This should increase stability.
>
> It might also help if you checked the area of intersections and 
> differences and eliminated ones with very small areas (since these 
> should be below the accuracy of your input data in any case).
>
> HTH - Martin
>
> Russell Strong wrote:
>> Hi all,
>>
>> I'm trying to dissect up a bunch of nearly round overlapping
(Continue reading)

Permalink | Reply | 3 comments |
headers
Martin Davis | 5 Mar 2008 17:46
Favicon

Re: bad input data or robustness issue?

Er, well, perhaps not.  Can you use the C++ API instead?  Or else this 
is a project for some GEOS developer...

Russell Strong wrote:
> I've had a look through the c api and it would appear that access to 
> precision models is not exposed, unless it's disguised in a way I have 
> not recognized.  Am I correct?  Is there some code that someone knows 
> about which could give me some *pointers.
>
> Martin Davis wrote:
>> As you've noticed, the predicates are not necessarily consistent with 
>> the overlay operations.  This is because the predicates are exact, 
>> whereas the overlay operations are approximate (which is unavoidable, 
>> since they operated in a finite-precision model).
>>
>> So, don't rely on this in your code. If you determine that two 
>> polygons overlap, you still have to check for an empty intersection 
>> and handle it appropriately.  This should only happen when the area 
>> of overlap is so small as to be negligible, in any case.
>>
>> Also, try using a limited-precision model.  Round of the numbers in 
>> your input, and use an explicit PrecisionModel to control the 
>> precision of the computed output.  This should increase stability.
>>
>> It might also help if you checked the area of intersections and 
>> differences and eliminated ones with very small areas (since these 
>> should be below the accuracy of your input data in any case).
>>
>> HTH - Martin
>>
(Continue reading)

Permalink | Reply | 2 comments |
headers
Stephen Woodbridge | 5 Mar 2008 17:51
Favicon
Gravatar

Re: bad input data or robustness issue?

Would this make a good Google SoC project? I seems like it would be a 
good thing to have in the c-api.

-Steve

Martin Davis wrote:
> Er, well, perhaps not.  Can you use the C++ API instead?  Or else this 
> is a project for some GEOS developer...
> 
> Russell Strong wrote:
>> I've had a look through the c api and it would appear that access to 
>> precision models is not exposed, unless it's disguised in a way I have 
>> not recognized.  Am I correct?  Is there some code that someone knows 
>> about which could give me some *pointers.
>>
>> Martin Davis wrote:
>>> As you've noticed, the predicates are not necessarily consistent with 
>>> the overlay operations.  This is because the predicates are exact, 
>>> whereas the overlay operations are approximate (which is unavoidable, 
>>> since they operated in a finite-precision model).
>>>
>>> So, don't rely on this in your code. If you determine that two 
>>> polygons overlap, you still have to check for an empty intersection 
>>> and handle it appropriately.  This should only happen when the area 
>>> of overlap is so small as to be negligible, in any case.
>>>
>>> Also, try using a limited-precision model.  Round of the numbers in 
>>> your input, and use an explicit PrecisionModel to control the 
>>> precision of the computed output.  This should increase stability.
>>>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Russell Strong | 6 Mar 2008 11:17
Picon

Re: bad input data or robustness issue?

I've done lots of C and python, never done any C++ programming before, 
looks like I'll be doing some learning.  Can't be too hard, right...

Martin Davis wrote:
> Er, well, perhaps not.  Can you use the C++ API instead?  Or else this 
> is a project for some GEOS developer...
>
> Russell Strong wrote:
>> I've had a look through the c api and it would appear that access to 
>> precision models is not exposed, unless it's disguised in a way I 
>> have not recognized.  Am I correct?  Is there some code that someone 
>> knows about which could give me some *pointers.
>>
>> Martin Davis wrote:
>>> As you've noticed, the predicates are not necessarily consistent 
>>> with the overlay operations.  This is because the predicates are 
>>> exact, whereas the overlay operations are approximate (which is 
>>> unavoidable, since they operated in a finite-precision model).
>>>
>>> So, don't rely on this in your code. If you determine that two 
>>> polygons overlap, you still have to check for an empty intersection 
>>> and handle it appropriately.  This should only happen when the area 
>>> of overlap is so small as to be negligible, in any case.
>>>
>>> Also, try using a limited-precision model.  Round of the numbers in 
>>> your input, and use an explicit PrecisionModel to control the 
>>> precision of the computed output.  This should increase stability.
>>>
>>> It might also help if you checked the area of intersections and 
>>> differences and eliminated ones with very small areas (since these
(Continue reading)

Permalink | Reply | 0 comments |
headers
Frank Warmerdam | 14 Mar 2008 18:48
Picon
Favicon
Gravatar

Incubation Progress

Folks,

I've just realized that I am in fact the OSGeo appointed incubation
mentor for the GEOS project.  I have been meaning to prompt for some progress
for a while, but this seems like a good time.

I see two main things that need to be done:

1) Setup project governance.  This will presumably amount to setting up a
Project Steering Committee responsible for approving commiters, approving
major technical changes - perhaps via an RFC process, and making other
major project decisions.  I would be willing to draft an "RFC 1" outlining
this, modelled on the one used by MapServer or GDAL if that would be helpful
(let me know).

One key issue is establishing the initial PSC.  As major stakeholders it
may be desirable to have Safe Software, Autodesk and Ingres represented.
I also assume that Paul will be on it (perhaps chairing?).  There are also
several other contributors that might be reasonable - mostly obviously Ben
Jubb who has done the recent work at Refractions.

2) Provenance Review.  This process is described at:

   http://www.osgeo.org/incubator/process/codereview.html

For GEOS I anticipate this mostly just being a bit tedious because of the
number of files to review, but likely not very hard since there have been
a limited number of contributors, and little use of outside code.  Is there
anyone willing to volunteer for this work?  I would be happy to provide
guideance and support.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Martin Chapman | 18 Mar 2008 21:08

GEOS comment

GEOS developers,

 

I just thought I would let you guys/girls know that I have been using geos from visual c++ on windows xp for a few months and I think your library totally fricking rocks.  It has been really easy to use, very stable and has a lot of great functionality.  Keep up the good work.

 

Best regards,

Martin

 

_______________________________________________
geos-devel mailing list
geos-devel <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel
Permalink | Reply | 3 comments |

Gmane