Hi, I'll try to address all the points that have come up so far below. It's not clear to me whether JTS can be used with Apache SIS for point 3 and perhaps Martin can help?
If Apache SIS does integrate with JTS then a switch away from GeoTools should be possible. However, I can't find any examples or documentation explaining this for Apache SIS. Thanks, Greg "Are your modules "pure" functions (i.e. agnostic to backend) or do they take advantage of Jena's spatial index module?" - The Property and Filter functions are agnostic to the backend. There is no use of jena-spatial as it was intended to be used with minimal upfront setup (no index building) and configuration (one line of code). Pre-calculation of the pairwise results across all 24 spatial relations (some are equivalent) also seemed very heavy when many/most may not be required by a user, so upfront index building/loading was avoided. There is in-memory caching of recently parsed geometry literals or likely re-used information (e.g. Coordinate Reference System (CRS) descriptions, CRS transformations). This reduces the parsing and allows use of the optimised JTS Prepared Geometry for spatial relations. "JTS now that is available under EDL form is OK." - The latest version 1.15 (org.locationtech.jts-core) is licenced under EDL/EPL but the current GeoTools is using 1.14 (com.vividsolutions.jts-core) under LGPL. The next version of GeoTools is due to make the switch across (https://osgeo-org.atlassian.net/browse/GEOT-5954) so until that is released both projects are LGPL. When the new version of GeoTools is released I'll upgrade. Apache SIS replacing GeoTools - The functionality provided by GeoTools seems to be covered by Apache SIS. However, the relevant sections of the Developer Guide (http://sis.apache.org/book/en/developer-guide.html#GetCRS) are marked as TODO. The main requirements fulfilled by GeoTools are: 1) Look up CRS from authority by URI. 2) Look up math transformation between source and target CRS. 3) Apply the math transformation to a source Geometry to produce a target Geometry (i.e. JTS Geometry). 4) Provide unit of measures (GeoTools uses javax.measure.unit) support derived from the CRS to allow conversions of distances (SI and non-SI units). -----Original Message----- From: Andy Seaborne <a...@apache.org> Sent: 27 August 2018 12:08 To: users@jena.apache.org Subject: Re: GeoSPARQL modules Was: Spatial distance in Fuseki Yes - this sounds very interesting. I can help with moving this forward, as either contribution or extending project. There is something to be said for starting separately (release is not coupled to Jena release cycles) then contribute if you want to go that route. It would be useful whether it has index support or not. JTS now that is available under EDL form is OK. IIRC when jena-spatial was done, it was LGPL so it had to be an optional extra. The LGPL for GeoTools is something to work on but it can be done. Is there anything in the Eclipse location domain that can provide some of what GeoTools is used for? If so, geotools can be an optional extra which is the normal way to deal with the situation. Andy Someone recently collected all the Apache projects logos and created the "powered by" versions: https://www.apache.org/logos/comdev-test/poweredby/jena.png On 24/08/18 19:38, ajs6f wrote: > Greg-- > > That sounds like a great contribution, although it might indeed make a lot of > sense as a sidecar module, or even built up as a package with Fuseki and > jena-spatial. Are your modules "pure" functions (i.e. agnostic to backend) or > do they take advantage of Jena's spatial index module? > > JTS is Eclipse-licensed [1], which (IIUC) should be cool, but GeoTools seems > to use LGPL [2], which I believe may present some problems for Jena (which > is, of course, licensed as Apache 2.0). > > ajs6f > > [1] https://github.com/locationtech/jts/blob/master/LICENSES.md > [2] > http://docs.geotools.org/latest/userguide/faq.html#q-what-licence-does > -geotools-use > >> On Aug 24, 2018, at 2:14 PM, Greg Albiston <greg_albis...@hotmail.com> wrote: >> >> Hello, >> >> Since the topic has come up. I've put together an implementation of all the >> GeoSPARQL modules which I was getting around to discussing contributing. >> >> It has dependencies on JTS, for spatial relations and distances etc., and >> GeoTools, for coordinate reference system conversions. I think the remainder >> are Apache dependencies. >> >> The only item to implement was additional unit tests. >> >> Would this be suitable for incorporating into Jena or better as an extending >> project? >> >> Also, the GeoSPARQL function namespace mentioned by the OP seems incorrect. >> The published namespace is: >> >> geof: http://www.opengis.net/def/function/geosparql/ >> >> Thanks, >> >> Greg >> >> >> From: Andy Seaborne >> Sent: Friday 24 August, 18:29 >> Subject: Re: Spatial distance in Fuseki >> To: users@jena.apache.org >> >> >> (PS JENA-664 is the open JIRA for GeoSPARQL) A complete example with >> imports etc: >> https://gist.github.com/afs/a8dfe6680324110bdb675190f9c73035 and also >> below. This is for doing everything in one java program. It is the >> simplest way and runs in an IDE for debugging. > My main problems in >> understandig are: > - where to put the java code and how to name it >> It will have a URI name. From the example below: // Register the >> function FunctionRegistry ref = FunctionRegistry.get(); >> ref.put("http://my/num";, MyFunction.class); using the global function >> registry (you can have one uique to the dataset if you want as well >> but the joy of globally unique URIs is that putting it the >> JVM-registry just works. > - how to include it with Fuseki The >> example below is the simplest way using embedded Fuseki. It's a plain >> Java program and avoids the need to repack jar files which for >> development makes things easier and can be debugged in an IDE. If you >> want to create a packaged standalone jar file, this is a a template: >> "basic" is a standalone jar using embedded Fuseki and with a command >> line interface. >> https://github.com/apache/jena/tree/master/jena-fuseki2/jena-fuseki-b >> asic It makes: >> http://jena.apache.org/documentation/fuseki2/fuseki-embedded.html#fus >> eki-basic so using that, adding your own code and making the command >> line start register the function should work. > - how to call it in >> the SPARQL query Functions are invoked like: (?Z) which is URI + >> arguments. The URI can a prefixed name as well; prefixes and expanded >> during parsing and it is the URI that matters. BIND ((?Z) AS ?X ) >> FILTER((?Z) = "number") Andy ------------------------ >> https://gist.github.com/afs/a8dfe6680324110bdb675190f9c73035 and with >> slight reformatting: public class FuFunctionEx { /** Our function */ >> public static class MyFunction extends FunctionBase1 { @Override >> public NodeValue exec(NodeValue v) { if ( v.isNumber() ) return >> NodeValue.makeString("number"); return NodeValue.makeString("not a >> number"); } } public static void main(String...a) { >> FusekiLogging.setLogging(); // Register the function FunctionRegistry >> ref = FunctionRegistry.get(); ref.put("http://my/num";, >> MyFunction.class); int PORT = FusekiLib.choosePort(); // Some empty >> dataset DatasetGraph dsg = DatasetGraphFactory.createTxnMem(); >> FusekiServer server = FusekiServer.create() .setPort(PORT) >> .add("/ds", dsg) .build(); server.start(); // Test query. String >> queryString = StrUtils.strjoinNL( "SELECT * { " , " VALUES ?Z { 123 >> 'abc'}" , " BIND ((?Z) AS ?X )" ,"}" ); try { String url = >> "http://localhost:"+PORT+"/ds";; // Connect to the server and execute >> the query. try ( RDFConnection conn = >> RDFConnectionFactory.connect(url) ) { // Using Java8 features. >> conn.queryResultSet(queryString, ResultSetFormatter::out); // Without >> Java8 features try ( QueryExecution qExec = conn.query(queryString) ) >> { ResultSet rs = qExec.execSelect(); ResultSetFormatter.out(rs); } } >> } catch (Exception ex) { ex.printStackTrace(); } finally { >> server.stop(); } } } Andy >> >
