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
Martin Davis
@dr-jts
  • minor: new features, bug fixes. api change
  • dot: minor improvements, bug fixes
what is the distinction between "API change maintaining compatibility" and "additive API change"?
Jody Garnett
@jodygarnett
I hear where you are coming from; my list was with a slightly relaxed take on compatibility. GeoTools has gradually allowed backports of api changes as long as they are "additive" and do not distrupt existing functionality.
So something like:
  • major: you will need to port your application to use JTS 2.0 interfaces as Geometry is now an interface
  • minor: we changed the api and your client code may have a compile error or new warning to fix
  • dot: we fixed stuff, if we we changed the api your client code will not notice
It looks like JTS 1.18.2 had one class change locations so it could of been a minor release :P
Martin Davis
@dr-jts
that sounds good to me.
The API change in JTS 1.18.2 is somewhat "soft"... a class changed packages, but the old class is still present but deprecated. Would this still be a minor?
Jody Garnett
@jodygarnett
(not saying I agree with the above, but I am trying to be more prgamatic and less purist. It is just how geotools is operating the last decade, so far less trouble then I expected)
Thinking ...
The old class is probably deprecated, so client code would get a new warning but still compile. I agree "soft" ...
So let me edit the above:
  • major: you will need to port your application to use JTS 2.0 interfaces as Geometry is now an interface
  • minor: we changed the api and your client code may have a compile error to fix
  • dot: we fixed stuff, if we we changed the api your client code will compile, but may have a new warning to address
Martin Davis
@dr-jts
getting there....
there is also semantic differences to take into account
(e.g. OverlayNG, which has some minor differences that people of course picked up on
Jody Garnett
@jodygarnett
of course they did
"minor: we changed the api and your client code may have a compile error to fix, or a javadoc to read carefully for changed behaviour"
There is a school of thought (ie purist) that changes of behaviour should always be an api break
James Hughes
@jnh5y
Martin Davis
@dr-jts
That's great. I'll add it to the QA section.
(the big one that @jodygarnett made to start cleaning up the code)
Not sure why those had to be removed? And changes like that should be noted in the Version History under API changes, I think.
Jody Garnett
@jodygarnett

It is not needed, see CoordinateList extends ArrayList<Coordinate> - so add( Coordinate c ) is already present in the API signature.

I would of kept it if there was a javadoc saying something useful.

Martin Davis
@dr-jts
ok, gotcha. So the report is slightly wrong...
Jody Garnett
@jodygarnett
It is more it has limitations
Martin Davis
@dr-jts
Just landed: Polygon triangulation. locationtech/jts#775
Of particular note is that this includes a fast Constrained Delaunay Triangulation for polygons, which gives much better quality.
Here's an example:
image.png
It's also going to serve as the basis for some other interesting algorithms, such as Skeleton and possibly a vertex-based subdivision.
James Hughes
@jnh5y
As a note, Apache Jena is using JTS for its GeoSPARQL support! (I'm helping co-chair a spatial track for Apache Con @ Home and the speaker just mentioned using JTS!)
Martin Davis
@dr-jts
w00t!
Thanks to the relicensing, I guess?
Jody Garnett
@jodygarnett
That is good, so glad to avoid forking.
@dr-jts sorry I got busy the other week during our chat on package names. Did you get a way forward you agreed with?
Martin Davis
@dr-jts
yes, I put the new code in the old triangulate package. Maybe not ideal, but it will do for now.
TidalPoo
@TidalPoo
hi all!
I have been trying for several days to find instructions on how to make a multipolygon from several polygons.
And then how to determine to which polygon the coordinates in multipolygons belong.
I would be grateful for any help.
Jody Garnett
@jodygarnett
What have you figured out so far? MultiPolygon is created from a collection of polygons …
You can use getGeometryN to retrieve a specific geometry to check
I am not sure exactly what you mean by “belong” ?
TidalPoo
@TidalPoo
Perhaps I wrote the question incorrectly. I have a task. I need to make several polygons with names on the plane. A point will move randomly along these polygons. I need to get the name of the polygon where the point is.
Jody Garnett
@jodygarnett
Okay, that tends to be considered a feature (ie geometry with an attribute - in this case a name).
JTS provides one user data object which you could use to store a name. Or you could use a library that supports features such as GeoTools (which has a feature data type and a uses JTS for the geometry attribute(s) of each feature).
How many polygons are you working with? Hundreds, thousands, millions?
TidalPoo
@TidalPoo
thanks for your reply. Yes, I am considering working with geometry. i don't want to use GeoTools. It should be a very light project. I will have several planes (levels), each with its own set of polygons, no more than 50.
TidalPoo
@TidalPoo
The point will be moved by keyboard control. I need to understand which polygon the point is in now. I worked with jmonkey, but it is too heavy a library to perform such a simple function.
Can you show some example code? Do I need to create geometry, assign a name, and add it to multigeometry?
TidalPoo
@TidalPoo
is this ok, or are there any better ideas?