Le jeu. 19 févr. 2026 à 14:57, Johann Sorel via dev <[email protected]> a écrit : > > > That's one way to see it. > Of course if no one else is interested or do not have time to get > involved then I'm better of continuing the work in Apache SIS. > Sure it's faster to do things on our own, without talking to anyone, > that's how we end up with a lot of different libs doing more or less the > same stuff.
I agree: Collaboration on reusable code is a better way. > Our philosophy in Apache SIS is to follow the standards and formats if > they exist. > For Geometry that is ISO 19107, OGC Feature, the various Khronos specs > and some others like SVG, CSS... > A good geometry API should be able to map the existing. Matt Juntunen would be the one to discuss whether those things would be achievable within the current design, and scope, of Commons Geometry. > There is a good amount of overlapping, commons geometry is a rich library. I had a very brief look, and some of the basic functionality indeed overlaps (as would be expected). However, unless I'm mistaken, there is a divergence in fundamental design: Commons Geometry is based on immutable objects while SIS provides "setter" methods; see e.g. https://github.com/apache/sis/blob/geoapi-4.0/incubator/src/org.apache.sis.geometry/main/org/apache/sis/geometries/math/Vector3D.java vs https://commons.apache.org/proper/commons-geometry/commons-geometry-euclidean/apidocs/org/apache/commons/geometry/euclidean/threed/Vector3D.html > > For now I will continue the work in Apache SIS. > I'll see how it goes and perhaps start coming back to you if it can be > of mutual benefit. Performance features mentioned in your previous message are definitely very interesting; the question is whether all users can switch to the required Java version. Alternatively, perhaps we could define an interface to some functionality, with implementations provided in different modules (possibly with different Java version requirements). Gilles > Le 19/02/2026 à 14:27, Elliotte Rusty Harold a écrit : > > On Thu, Feb 19, 2026 at 8:32 AM Johann Sorel via dev > > <[email protected]> wrote: > > part : > >> https://github.com/apache/sis/tree/geoapi-4.0/incubator/src/org.apache.sis.geometry/main/org/apache/sis/geometries > >> > >> Apache-commons-geometry contains a single kind of geometry : > >> Constructive Solid Geometry. which is really nice. > >> But what we are making is more like JavaTopologySuite, Esri-geometry, > >> SVG but with 3D (and more) support for PLY, GLTF, GPU... > > I'm not familiar with the math you're using, but it sounds like it's > > quite different from what's in commons geometry now and has limited > > overlap. If that's true, then I strongly recommend you make your own > > more targeted library and artifact rather than trying to shoehorn it > > into another library because the name sounds similar. Smaller, more > > focused libraries speed up development and enable you to build exactly > > what you need without trying to get consensus with another team. > > Frankenlibraries that include everything and the kitchen sink are > > already a problem for Apache Commons. I think you'll be much happier > > with your own library that you control and can tailor to your > > project's needs. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
