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
James Hughes
@jnh5y
The Eclipse documentation is also updated: https://projects.eclipse.org/projects/locationtech.jts
and I've reset the JTSVersion.java and version history
I think at this point, we just need to announce this here (done!), on the dev email list, and on Twitter
Oh! I also have GT/GWC/GS PRs up
@dr-jts congrats on the release! Do you want to email the dev list?
@jodygarnett shout when you tweet something and I'll get CCR_inc to retweet it
Jody Garnett
@jodygarnett
james I do not think you need to reset version history, instead we add an entry for 1.19.0 (coming up)
Thanks for the GT/GWC/GS PRs i will review tomorrow
James Hughes
@jnh5y
I meant that I added an entry for 1.18.3 (which we can change later to 1.19.0!)
Jody Garnett
@jodygarnett
+1
Martin Davis
@dr-jts
ok, I'll send out a note to the list
seems to me this was a bit more than a dot-dot release. Too late now of course, but I think we should be clearer on what is dot and what is dot-dot
Thoughts?
Jody Garnett
@jodygarnett
tentative:
  • major: rewrite, please send funding first. api change breaking compatibility
  • minor: new features, bug fixes. api change maintaining compatibility
  • dot: improvements, bug fixes. api change "minor" such as javadoc clarifications or additve api change
Martin Davis
@dr-jts
thanks, Jody.
I question major: API change breaking compatibility. We do that fairly regularly! And I don't really want to get into JTS 2.x until rewrite time.
Here's my thought:
  • major: rewrite, please send funding first.
  • 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.