Move to GeometryTypes for point definitions?

[asinghvi17]

It would make it a lot easier to integrate this with plotting packages.

[juliohm]

GeometryTypes.jl is now deprecated, and GeometryBasics.jl is also in maintenance mode as far as I can tell. It would be nice to migrate these predicates to Meshes.jl instead which is being actively developed and has a lot of nice functionality already.

Would you be willing to help with the migration? After that we could migrate VoronoiDelaunay.jl and avoid this fragmentation of packages for geometric processing. The codebase in Meshes.jl is very comprehensive already, and can serve as a hub while things settle down.

[juliohm]

cc: @dkarrasch

[robertdj]

I think it sounds like a good idea with less packages with "basic geometry stuff".
A couple of thoughts:

• Does GeometricalPredicates serve a purpose per se or is it only used in VoronoiDelaunay? If not, maybe it's better to let VoronoiDelaunay depend directly on another geometry package?
• As I recall, VoronoiDelaunay relies on a "BigInt" representation of points through the requirement that all coordinates are between 1 and 2. Does Meshes/GeomtryBasics support this?
• Is GeometryBasics in really maintenance mode? It was updated a few days ago.

[juliohm]

• Does GeometricalPredicates serve a purpose per se or is it only used in VoronoiDelaunay? If not, maybe it's better to let VoronoiDelaunay depend directly on another geometry package?

The plan is to write various tesselation methods in Meshes.jl directly, including the method implemented in VoronoiDelaunay.jl. Ultimately we would like to switch between different methods easily as in tesselate(points, methodA) or tesselate(points, methodB). We have too many wrappers hanging around for Voronoi/Delaunay tesselations and each of them follows a completely different API. See MiniQHull.jl, StarTIN.jl, TetGen.jl, ... It is a nightmare.

• As I recall, VoronoiDelaunay relies on a "BigInt" representation of points through the requirement that all coordinates are between 1 and 2. Does Meshes/GeomtryBasics support this?

I think this is an internal detail about the algorithm. We can certainly support that if necessary. It shouldn't be something that the end user needs to know. The end user wants to tesselate(points, methodA).

• Is GeometryBasics in really maintenance mode? It was updated a few days ago.

I am following the repository and the changes that are happening there are mostly minor bug fixes to solve downstream issues in the Makie.jl visualization project.

[sjkelly]

Some data:

Meshes.jl - 13 Dependents
GeometryTypes.jl - 193 Dependents
GeometryBasics.jl - 232 Dependents

I think the transition for GeometryBasics from GeometryTypes in earnest started around 18 months ago. Oddly enough the OG Meshes from around 2014 was the basis for GeometryTypes, and much of GeometryBasics was a copy pasta from GeometryTypes. So there has been alot of inherited cruft from pre-1.0 days through the lineage. IIRC @juliohm tried cleaning up GeometryBasics, and now we have come full circle back to Meshes.jl :).

I quite like the design of Meshes.jl and think it is a good basis for the future. It looks to solve many issues I have had in the past also! However the transition from GTypes to GBasics never really finished so we are left with alot of the algorithmic packages on GTypes with visualization of GBasics which is not exactly ideal. It is possible to support both as I did with Meshing.jl, but that is not really easy for more complex packages. I guess what I'm saying is we need a plan and consensus for what the "Base" Geometry package should be (with a caveat to follow). Hopefully before more dependency inertia adds up.

Moreover when it comes to geometry algorithms we can write many of them completely generic on AbstractArrays. I tried this type-agnostics approach with some simple algorithms in PolygonOps.jl and it was well received. Meshing.jl also evolved to use this approach internally and makes it possible to support multiple base geometry libs. It also makes function signatures and operations more familiar for those coming from Python and MatLab and/or porting their code from these languages.

So maybe a better approach here is to make algorithms as generic as possible, with wrapper layers for the users chosen "Base" geometry package. (they could be part of the package for convenience, or separate).
I encourage this because the JuliaGeometry org is 1 out of 3 on successful base geometry library transitions. And the original Meshes to GeometryTypes transition worked because we could count package dependencies on two hands :). Adoption of type-generic algorithms seems much better than those tied to a large ecosystem with its own types and idioms.

[juliohm]

However the transition from GTypes to GBasics never really finished so we are left with alot of the algorithmic packages on GTypes with visualization of GBasics which is not exactly ideal. It is possible to support both as I did with Mesh_ing_.jl, but that is not really easy for more complex packages. I guess what I'm saying is we need a plan and consensus for what the "Base" Geometry package should be (with a caveat to follow). Hopefully before more dependency inertia adds up.

I don't see much value in finishing a transition to GeometryBasics.jl specially knowing all the issues with the codebase. In my opinion we should concentrate our very limited resources on a single hub to avoid fragmentation and Meshes.jl is far ahead compared to the alternatives in terms of design and features. In other words, it seems reasonable to assume that Meshes.jl will naturally become a central hub for geometric processing in Julia. I am working actively there because of my research needs, and everyday a new feature is added for example.

Moreover when it comes to geometry algorithms we can write many of them completely generic on AbstractArrays

I fully agree that we can strike a very interoperable interface with Julia's AbstractArray in most cases. However, I feel that these implementations should live on a single repository for guaranteed integration with the rest of the stack. At least for now while things settle down. Communicating through Julia Arrays can be very pleasant but sometimes we can avoid materializing mesh structures into memory using clever lazy objects. See for example our SimpleMesh in Meshes.jl We only materialize the triangles and quadrangles and hexahedrons etc on the fly when strictly needed.

My suggestion would be slightly different to favor more discussion in a single place. I suggest to migrate all the predicates from GeometricPredicates.jl to Meshes.jl if they are not available in the latter yet. After that, we can also migrate various tessellation methods to the same codebase so that everyone can keep an eye, maintain the code, and fix bugs.

After all these fragments are merged into a single comprehensive library, we can have auxiliary packages for IO and visualization. For example, we could migrate MeshIO.jl to use Meshes.jl as the base and I am in the process of creating a MeshViz.jl to contain plot recipes for Makie.jl. Hopefully, in the near future end users will only need to do:

using Meshes, MeshIO, MeshViz

to work with meshes and geometric processing in Julia.

[sjkelly]

@juliohm Something I forgot entirely from that response was namespacing, which become an issue for generic operations. For example in PolygonOps we need to use inpoly since it is generic and would otherwise conflict with the in function. Whereas with a PolyTope type you can use in for this function name.

However, I feel that these implementations should live on a single repository for guaranteed integration with the rest of the stack. At least for now while things settle down. Communicating through Julia Arrays can be very pleasant but sometimes we can avoid materializing mesh structures into memory using clever lazy objects.

This is completely missing consideration of longer term project stability. I still think the approach in Meshing, PolygonOps, and Contours of being generic has proven the most sustainable in the long term. Contours and Meshing are among the top used packages in this organization, go back to Julia 0.3, and have had many different maintainers through the years. Both are very low maintenance burden partly by virtue of a low dependency footprint and genericness.

Potentially an optimal middle ground would be to see how Meshes.jl could include a dependency like Contour while retaining performance. If the algorithms are not generic enough to unlock the performance of the Meshes.jl data structures, that should be fixed in Contour.jl rather than absorbing and modifying the code. Believe in the parametric multiple dispatch :)

[juliohm]

As far as I can tell, we already have all the functionality of PolygonOps.jl implemented in Meshes.jl, and we also deal with polygonal areas that contain holes, which from what I remember, is not covered in PolygonOps.jl. We also have basic simplification algorithms in Meshes.jl like Douglas-Peucker simplication of polygonal chains, which is only planned in PolygonOps.jl as a future addition. What I am trying to say is that not many people will be willing to add features to a package that is super small. On the other hand people may feel motivated to add a different method to a big project. This is what happened in hubs that I worked in the past like LightGraphs.jl, Images.jl, GeoStats.jl, MLJ.jl,... We need a hub to progress quickly. In my experience fragmentation hurts community building.

The only reason I see for adding a dependency is if it is something really hard to implement. For example, we have plans to integrate geometric algebra at some point and that will certainly deserve a separate library with compiler optimizations. Other than that, I don't see advantage in fragmenting the functionality in many small packages. If we can work on this hub, we can figure out later some possible sub-packages that are emerging. Premature fragmentation is an issue that is affecting a few Julia organizations like JuliaGeometry and JuliaML. I addressed some of these issues in JuliaML in the past, but my research is heavy nowadays in geometric processing, hence the Meshes.jl effort. Hope more people will join.