Thompsonbry.systap added a comment. We would be interested in both the elastic search and GeoSPARQL integrations.
Full GeoSPARQL support is complex. It involves not only the spatial index, but extensions to the query planning and there is a large test suite that we would need to pass. A simple way to achieve a spatial index is to use MGRS [1] coding of the coordinates. This turns the coordinates into an outer grid system and an inner z-ordering system. The resulting MGRS codes can be fed into the full text index in blazegraph. You can then do prefix scans on the coordinates against that full text index and it will give you a spatial restriction. You can then add FILTERs that perform additional kinds of spatial filtering. Peter might be able to comment on what it would take to provide full GeoSPARQL. There is also the opensahara project which has provided GeoSPARQL support. However, to achieve good GeoSPARQL performance where would have to be significant effort to port the integration to run against our internal indices and handle the rewrites in ASTOptimizers. (opensahara uses PostGRES as I recall for the spatial support, so the basic spatial join is via an external SERVICE.) I can forward the relevant threads from our developers mailing list if you like and also reach out to the opensahara group if there is interest in pursuing this approach. [1] https://en.wikipedia.org/wiki/Military_grid_reference_system TASK DETAIL https://phabricator.wikimedia.org/T90130 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign <username>. EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Thompsonbry.systap Cc: Thompsonbry.systap, Jdouglas, daniel, Beebs.systap, Haasepeter, Aklapper, Manybubbles, jkroll, Smalyshev, Wikidata-bugs, aude, GWicke, JanZerebecki _______________________________________________ Wikidata-bugs mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
