Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Aug 01 2018 17:48
    @jnh5y banned @matrixbot
at least the jts-app part of the build
Martin Davis
@dr-jts
ah, thx... my bad, guess I should use a PR for that big a change
James Hughes
@jnh5y
eh, I get emails from the Eclipse Hudson when the build fails
would you like to get those emails as well? (that's how I knew there was a problem)
Separate from that, there may be emails from Travis CI
Martin Davis
@dr-jts
yes, that would be great
actually I think I do get some emails from Hudson, but not for that I guess
build should be fixed now
James Hughes
@jnh5y
yeah, looks like you should have one from 1:57am Eastern this morning
James Hughes
@jnh5y
@dr-jts how's it going?! I've got a co-worker who is taking a grad algorithms class and needs an algorithm to implement as a class project
I'm wondering if Concave hull / alpha shapes would be a good project
James Hughes
@jnh5y
@dr-jts also, good job on the next iteration of the overlay operations!
Martin Davis
@dr-jts
Thanks, Jim.
Concave Hull could be a good project. There's several implemetations already, including one sitting in a JTS PR
Straight Skeleton and Frechet Distance would be interesting as well
Or a faster Delaunay triangulation algorithm... using a batch approach instead of incremental, and using a simpler triangulation structure
Or Constrained Delaunay
James Hughes
@jnh5y
nice ideas
I didn't know about the Frechet Distance; that's a handy one
Is Delaunay triangulation used other places? (I'm wondering if an improvement to it would benefit other places, etc)
Martin Davis
@dr-jts
It might be.. I think Straight Skeleton uses it. Of course Constrained Delaunay. And there's been a bunch of chitchat in GEOS land recently around pprepair, which uses Constrained Delaunay . (https://github.com/tudelft3d/pprepair)
It would be nice to have a simpler triangulation structure. That would support Polygon triangulation better. I did some work on this, but it hasn't really landed
Oh. also Concave Hull uses Delaunay
geoHeil
@geoHeil
When using JTS geometries and calculating intersections - what are tricks to speed this up? I know that in postGIS https://postgis.net/2014/03/14/tip_intersection_faster/ some contains / coveredby operation and a if-else could make things faster. Is this already applied under the covers automatically?
Martin Davis
@dr-jts
The only optimizations that are built-in to the JTS overlay operations are ones that check for bounding box overlap. So the trick in the PostGIS post could be useful - i.e. predicates to test for intersects & coveredBy and short-circuit based on that. If you're checking both then it's more efficient to use Geometry.relate and then check the IntersectionMatrix returned. Unfortunately the predicates are not as efficient as they could be, so this may or may not be much faster. (It would be interesting to hear what you find out.) Also, if you are running many geometries against a single one, then preparing the single one to do the predicate tests should be a lot faster.
The new overlay code (OverlayNG) implements an overlap envelope clipping optimization which can be very effective for intersection, especially in the cases where one geometry is much bigger than the other, or the overlap is small. I'd be happy to provide support if you want to try that out (although you should know that overall it's about 2x slower than the current overlay).
Maybe I should look at porting the overlap envelope clipping code to the original overlay...
Martin Davis
@dr-jts
I should also create a performance test to show how these approaches compare.
geoHeil
@geoHeil
Thanks a lot for the great overview.
Martin Davis
@dr-jts
@geoHeil NP!
James Hughes
@jnh5y
@geoHeil, if you have a chance to try out the new overlay implementation, you should give it a spin. @dr-jts has been working on it for awhile... Georg, you do enough topology that not seeing more topology exceptions would be worth your time:)
geoHeil
@geoHeil
Or instead go with hexagons ;) I still will new to think this through.
James Gill
@jagill
The PackedCoordinateSequence is looking awesome -- about 2x memory savings and massive GC pressure reduction. I have a question about thread safety: Are GeometryFactory objects and CoordinateSequenceFactory objects threadsafe?
Martin Davis
@dr-jts
GeometryFactory is immutable so is thread safe. CoordinateSequenceFactory is an interface, so it's up to the implementation. But normally they should be thread-safe.
Jody Garnett
@jodygarnett
Goal is to have those immutable, some early copies of the interface relied on state and I found implementations with fields for number of dimensions etc....
interface was changed so number of dimensions / measure was a parameter (so implementations did not have an excuse to be mutable)
Dylan Richardson
@dylrich
Not a Java guy but trying to work my way through JTS so apologies if this is a silly question: I can't quite follow JTS' Line Segments intersection code. When you call the computeIntersection function on the RobustLineIntersector class, when does its protected method computeIntersect actually get called? From reading https://github.com/locationtech/jts/blob/master/modules/core/src/main/java/org/locationtech/jts/algorithm/RobustLineIntersector.java#L34 it looks like it never gets called and you just report what kind of an intersection it was.
Björn Harrtell
@bjornharrtell
@dylrich it's used in the base class (LineIntersector)
Dylan Richardson
@dylrich
Ah, I see that now, thanks. Any chance you could give me some advice on how to run e.g. all of the RobustLineIntersector test cases and just those?
Björn Harrtell
@bjornharrtell
sorry don't have instructions readily available for that :)
Dylan Richardson
@dylrich
Looks like mvn -Dtest=RobustLineIntersectorTest test -pl modules/core got me what I wanted :) I'll keep fumbling through. Thanks for the help!
mryansnc
@mryansnc
image.png
I have 2 lines (A and B). I'd like to add the end point of line A to line B where they intersect. I'm not sure of the best approach. I tried union, however, it does not place the point of interest into line B in the correct sequence (at index 1, assuming the start point of B has index 0, and the end point of B has index 2). Diagram shown above ^^^
mryansnc
@mryansnc
Have also tried combine but same result as union.
Martin Davis
@dr-jts
If B has only two points the best approach is to simply make a new line with 3 points, with the middle one the end vertex of A
otherwise it gets tricky, since there is no guarantee that line A actually crosses line B. So the overlay operators aren't going to help. I'd look at the linearref classes. E.g. one thing you could do is to compute the index of the endpoint of A along line B. Then perhaps extract the two sublines of B from the start to the point, and the point to the end, and then LineMerge them.
Martin Davis
@dr-jts
Or you could extend line A by double the distance to Line B, and then compute B.difference(A) - might work.
Interesting problem, which I've seen before. It seems silly that such a simple thing is so hard to do. This might indicate a need for a function/method to perform this kind of thing. Perhaps a method on the IndexedLine classes which will add a vertex at a given index.
mryansnc
@mryansnc
@dr-jts thank you, I'll take a look.