Sounds like an interesting project. I would be open to this replacing the current set of functions based on ESRI, if the quality and performance were superior.
As a database guy, and in particular an optimizer guy, I am very interested in recognizing certain patterns and rewriting them to use indexes (or similar). I hope that your implementation allows those kind of optimizations, just as the ESRI-based functions do. Also I would love to get to full coverage of the SQL simple feature support, including a good test suite. Can you please log a JIRA case to track the work that you are doing? Even if your work is outside of Calcite’s repo. I looked at https://github.com/jonrmayer/geofunctions <https://github.com/jonrmayer/geofunctions> briefly. Did you decide on a license? If you are using Apache License, add LICENSE and NOTICE files, and add a license section to your pom.xml. Julian > On Dec 28, 2018, at 3:10 AM, Jonathan mayer <[email protected]> > wrote: > > Hi All, > Over the last few days, I have started to develop new calcite spatial > functions based upon locationtech libraries - jts-core and proj4j - basically > replacing the esri-geometry-api. > > JTS is the Gold Standard and there are far more examples/templates out there > from an algo implementation perspective. > It is still early days yet - lots to do - but I have placed a project on > GitHub - jonrmayer/geofunctions - which contains all the code to date. > > | > | > | > | | | > > | > > | > | > | | > jonrmayer/geofunctions > > Contribute to jonrmayer/geofunctions development by creating an account on > GitHub. > | > > | > > | > > > > It is intended to be a like-for-like replacement of the existing > calcite-core/runtime/GeoFunctions.java file. > With some minor edits to calcite-master pom /calcite-core pom - it is > feasible to drop this in as a replacement - adding the calcite imports etc to > the top of the file. > Tests however will be a problem - eg. spatial.iq will no longer be relevant. > ESRI outputs geometries to JSON whereas JTS outputs WKT - this will need to > be rewritten. > My current plan is to focus on implementing as many functions as possible > with basic tests and then to improve on the (very) basic Maven testing before > letting anyone know that I am reasonably happy. > I should imagine that spatial.iq will have to wait a fair while - I will need > it to test Geometry Collections for eg ST_DWithin/ST_Collect etc and hope > that the maven test are enough from a confidence perspective. > A bit of background:- I have 10+ years in the GIS/spatial arena but only 1.5 > years with Java ( very junior ) I know PostGIS/H2GIS/Oracle/SQlServer/OGR/NTS > etc. - biased towards the former. I know what I am looking for re: results. > My recent focus has been developing Spatial Data Flows within Apache Nifi - > hence the interest in Calcite. > I would like to contribute to the project but I don't believe that I could > ever become a "Contributor" - I would mess it up. > > I can build Calcite within my very narrow (Nifi) world view but do struggle > with a full build. I need the help of a master if there is an appetite to > integrate this. > I think I have managed to extend the current spatial function coverage - I > have added a "Status Report" to the project - jonrmayer/geofunctions. I > copied this from Calcite Documentation and it is a bit of a shorthand. I have > removed/replaced/added various funtions but it provides a good overview. > > | > | > | > | | | > > | > > | > | > | | > jonrmayer/geofunctions > > Contribute to jonrmayer/geofunctions development by creating an account on > GitHub. > | > > | > > | > > > > Regards, > Jonathan Mayer > > > > > > > > > > > >
