Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jts-dev] Visual Center of Polygon
Hi Martin,

Thank you, these are more promising than what I was finding.

Can you elaborate on the difference between the 2 types of intersections you mentioned? I want to create polygons on a sphere (say, from a collection of lat/lon points) and then calculate the intersection of those polygons.

It looks like spatial4j handles the date line crossing, but not the poles: "Polygons don't support pole-wrap (sorry, no Antarctica polygon); just dateline-cross."

S2 claims to do both, but it's a C++ library and the last Java port was in 2011.

Both might be worth trying out.

Thank you,

Eric Angle

On Fri, Nov 2, 2018 at 7:35 PM Martin Davis <mtnclimb@xxxxxxxxx> wrote:
You can try looking at these libraries:


I'm not sure if either will do what you need.  (To clarify, do you want to compute intersection geometries on the sphere, or compute the intersects predicate on the sphere?  The latter is probably easier to find than the former).

On Fri, Nov 2, 2018 at 4:21 PM Eric Angle <eric.lohner.angle@xxxxxxxxx> wrote:
I'm ultimately interested in solving a problem like the one described here:


You can create the polygons in the 2D Cartesian space JTS assumes and then go about calculating quantities such as their intersection (which JTS does very well).

However, then you have to handle special cases like the +/- 180 meridian and the north/south poles, and you also have issues like the one one answer in the above link pointed out: "any newly created intersection points (where polygon edges cross) will be out-of-place and dependent on the projection used."

Is anyone aware of a better way to approach this problem? In particular, is there a Java library that is better suited to this problem?

Please don't take this as negative feedback on JTS by the way -- I've been very impressed with it so far.

Thank you,

Eric Angle

On Thu, Oct 25, 2018 at 6:54 PM Eric Angle <eric.lohner.angle@xxxxxxxxx> wrote:
I meant the magnitude of the slope is 0.8, not 1.0.

On Thu, Oct 25, 2018 at 6:54 PM Eric Angle <eric.lohner.angle@xxxxxxxxx> wrote:
You're absolutely right. The slope from (5,10) to (10,6) is 0.8 not 1.0.

On Thu, Oct 25, 2018 at 5:27 PM Martin Davis <mtnclimb@xxxxxxxxx> wrote:
Ah, and now I see your point.  Yes, it is expected that the computed location is about  (5.276908874511719 4.999961853027344) .  This is in fact the centre of (one of) the Largest Inner Circles.  That's because the "diamond" shapes are not symmetrical about the vertical - they are slightly "larger" where they join.  So the circle centre is displaced towards the centre.  

Another way to see this is to compute:

distance( boundary(DD), (5.276908874511719 4.999961853027344)) = 3.7313447923664707
distance( boundary(DD), (5 5)) = 3.5355339059327378

So the computed point is actually slightly further from the DD boundary, as expected.


On Thu, Oct 25, 2018 at 2:17 PM Eric Angle <eric.lohner.angle@xxxxxxxxx> wrote:
Bouncing back and forth is fine. Either point would be acceptable for my use case.

I see your point that the y coordinate is converging, but the x coordinate is still off by almost 0.3 even when the precision is 0.00001. Is this to be expected?

Thank you,

Eric

On Thu, Oct 25, 2018 at 5:09 PM Martin Davis <mtnclimb@xxxxxxxxx> wrote:
Well, that test case is a classic example of a shape that has two locations of Largest Inner Circle (AKA Pole of Inaccessiblity, as the geographers like to call it).  It so happens that the approximation algorithm in PolyLabeller bounces back and forth between them  But it does seem to converge on both of them.  I also get:

PolyLabeller.getPolylabel(p, 0.0001) = (5.276908874511719 4.999961853027344)  
PolyLabeller.getPolylabel(p, 0.00001) = (14.723076820373535 4.999995231628418)    

So the precision is increasing, but the point location is not stable.  Just the way it works, unfortunately. Is this important for your use case? It might be possible to add a weighting to prefer (say) the leftmost one. 

On Thu, Oct 25, 2018 at 1:59 PM Eric Angle <eric.lohner.angle@xxxxxxxxx> wrote:
Hi Martin,
 
I was looking at the testDoubleDiamond() case here
 

Polygon p = (Polygon) reader.read("POLYGON((0 5, 5 10, 10 6, 15 10, 20 5, 15 0, 10 4, 5 0, 0 5))");

and decided to try it out with the jts-ports PolyLabeller.getPolylabel(Geometry polygon, double precision).

Should I expect to get back either (5,5) or (15,5) plus or minus (roughly) precision?

I find

PolyLabeller.getPolylabel(p, 1)     = (5,5)
PolyLabeller.getPolylabel(p, 0.1)   = (14.727,4.961)
PolyLabeller.getPolylabel(p, 0.001) = (5.276,4.999)

In other words, the answer doesn't seem to improve with decreasing precision.

Any thoughts on what could be going on?

Thanks,

Eric

On Thu, Oct 25, 2018 at 12:39 AM Martin Davis <mtnclimb@xxxxxxxxx> wrote:
Yes.  And probably best implemented using the orientationIndex predicate.

On Wed, Oct 24, 2018, 8:42 PM Sandro Santilli <strk@xxxxxx> wrote:
On Wed, Oct 24, 2018 at 10:58:08AM -0600, Eric Angle wrote:

> Your suggestion of checking that all interior angles are less than 180
> makes sense to me.

Less than or equal to 180, I guess ?

--strk;
_______________________________________________
jts-dev mailing list
jts-dev@xxxxxxxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.locationtech.org/mailman/listinfo/jts-dev
_______________________________________________
jts-dev mailing list
jts-dev@xxxxxxxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.locationtech.org/mailman/listinfo/jts-dev
_______________________________________________
jts-dev mailing list
jts-dev@xxxxxxxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.locationtech.org/mailman/listinfo/jts-dev
_______________________________________________
jts-dev mailing list
jts-dev@xxxxxxxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.locationtech.org/mailman/listinfo/jts-dev
_______________________________________________
jts-dev mailing list
jts-dev@xxxxxxxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.locationtech.org/mailman/listinfo/jts-dev
_______________________________________________
jts-dev mailing list
jts-dev@xxxxxxxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.locationtech.org/mailman/listinfo/jts-dev
_______________________________________________
jts-dev mailing list
jts-dev@xxxxxxxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.locationtech.org/mailman/listinfo/jts-dev
_______________________________________________
jts-dev mailing list
jts-dev@xxxxxxxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.locationtech.org/mailman/listinfo/jts-dev

Back to the top