Open kmsquire opened 10 years ago
Hi,
I had hesitated to publish Geometry2D yet for a few reasons: -- I was new to Julia when I started -- it was a an exercise I set myself to help learn Julia, and to see how well it really worked -- so I was concerned my code might not be top notch. -- There are a couple more things to add -- I have a fairly well developed convex hull routine but it isn't included yet. I wanted to get it faster than Matlab's one, but Matlab actually have a pretty good convex hull routine, so its taken a bit of work. Unfortunately, my day job caught up with me before I got it into the package. Once that is in, a few other useful algorithms are pretty easy to add. -- back when I started, there was a problem with immutables. Should be fixed now, but I am not running the latest version see https://github.com/JuliaLang/julia/issues/3651 If fixed then Points (and some other primitives) should be immutables I think, though I don't know all the issues. -- I haven't really done any documentation. -- I haven't done enough testing (but can you ever do enough :)
I'm in the UK at the moment, but will be back in a week, and will make a concerted effort to get a little bit more infrastructure into this and publish it.
The big missing part of my code from my point of view was Delaunay Triangulation/Voronoi diagrams, though there are many other pieces that could be added. Triangulation is useful, but at least as hard as convex hull code to write well, and I haven't done that one before so I would be starting from scratch.
RE extending to nD, and different underlying coordinate systems. I thought for a while about simply writing bindings for CGAL https://www.cgal.org/, which might be the way to go for a more professional package, but I didn't think I would learn as much about Julia that way. But maybe it would make sense to start a more general computational geometry package there?
RE coordinate systems, in an object oriented system, polar/spherical vs Cartesian would be irrelevant. We would have constructors, and output routines for whichever you need, but the underlying coordinate system would be fixed. I don't know the best approach to this in Julia? Perhaps it still isn't that hard?
On the other hand, RE homogenous coordinates, my goal with parameterisation was eventually to have the Rational data types be a type of homogenous representation, but I hadn't fully thought this through as I don't really need it. So most of the routines are really written for floating point, even though the rational parametrisation is there. A lot of work is needed to make the code properly robust for X{Rational}.
I haven't thought about Geographic coordinates at all. Mapping is a really cool. But it would take a lot more effort to really build this -- my nascent efforts at playing with maps in the past have shown me that there is a lot to it. There used to be some good open source places to start though I don't have them at my fingertips.
In any case, my goal was to provide a simple to use, native Julia, implementation that was fast enough to be used seriously. I didn't plan to try to work on 3D or nD, but I would like to get the 2D code to the point where it is a useful contribution for Julia users. Any thoughts on that, or people who want to try it out (and see what breaks) would be welcome.
Cheers, Matt
On 8/07/2014 1:59 pm, Kevin Squire wrote:
This package seems quite developed and potentially useful. Would you consider publishing it in METADATA.jl?
If you haven't seen it yet, I would also invite you to comment on the discussion happening at https://groups.google.com/forum/m/#!topic/julia-dev/vZpZ8NBX_z8 https://groups.google.com/forum/m/#%21topic/julia-dev/vZpZ8NBX_z8.
Cheers!
— Reply to this email directly or view it on GitHub https://github.com/mroughan/Geometry2D.jl/issues/1.
IIRC, CGAL uses C++ templates so Julia cannot call it yet. I believe Keno Fischer is working on making this a possibility. That said, I think it is an interesting exercise to write the algorithms in Julia. There are some commonly used algorithms in computational geometry which have had few implementations. Personally, I think it is highly valuable to make implementations in Julia since it opens up interesting avenues for extensibility and modification which might not be possible in tightly integrated libraries.
Also, @kmsquire I've done some work on polygon clipping and I would be happy to have it become part of a computational geometry package. I was hoping to get it into METADATA.jl soon, but I will hold off if we can integrate it into a larger project. @mroughan there is some overlap between our two packages, but the data structure for PolygonClipping.jl is pretty complex.
Link to the PolygonClipping package: https://github.com/sjkelly/PolygonClipping.jl
On 8/07/2014 11:27 pm, Steve Kelly wrote:
IIRC, CGAL uses C++ templates so Julia cannot call it yet. I believe Keno Fischer is working on making this a possibility. That said, I think it is an interesting exercise to write the algorithms in Julia. There are some commonly used algorithms in computational geometry which have had few implementations. Personally, I think it is highly valuable to make implementations in Julia since it opens up interesting avenues for extensibility and modification which might not be possible in tightly integrated libraries.
Also, @kmsquire https://github.com/kmsquire I've done some work on polygon clipping and I would be happy to have it become part of a computational geometry package. I was hoping to get it into METADATA.jl soon, but I will hold off if we can integrate it into a larger project. @mroughan https://github.com/mroughan there is some overlap between our two packages, but the data structure for PolygonClipping.jl is pretty complex.
Link to the PolygonClipping package: https://github.com/sjkelly/PolygonClipping.jl
Sounds cool. I was imagining doing polygon intersection by triangulation and convex intersection (for which convex hulls is a pretty good starting point).
My biggest issue for this sort of thing was I haven't really dealt with complex polygons, e.g., with holes. I guess that is what makes your data structures more complex?
I hadn't thought about the C++ issue. I had used the C bindings and assumed that C++ wasn't much harder, so forget that for the moment. And I agree that a native Julia version would be really useful, if only because then its a hell of a lot easier for people to understand how it works, and add to it.
As I said, I'm away at the moment, so I can't easily modify the code. If you can wait a couple of weeks, I can have a new version up on GitHub. I could also add you to the current repo if you'd like?
Cheers, Matt
@mroughan @kmsquire Sorry for the delayed reply. I think the best thing for interoperability is to define some convert
and promote
methods. This way we don't sacrifice high performance data structures but also can still afford to have transparent data structures facing the user. I am going to experiment with design of conversions and promotions between PolygonClipping.jl and MeshSlicer.jl.
If you could add me to this repo that would be great. Once I have a complete feature set in PolygonClipping I can start to merge the code here. Maybe we want to shoot for getting the package under the JuliaGraphics organization?
This package seems quite developed and potentially useful. Would you consider publishing it in METADATA.jl?
If you haven't seen it yet, I would also invite you to comment on the discussion happening at https://groups.google.com/forum/m/#!topic/julia-dev/vZpZ8NBX_z8.
Cheers!