Sorry Josh, I just realized I never responded to this and thanks for the feedback.
The scope for the proposed options are based on what tools like DSE Graph and Janusgraph support. I definitely agree that we should make sure that what we choose is extensible as well as in line with standards. I am not too familiar with GeoSPARQL but I have done a lot with WKT format which does allow for definitions of items like polygons with holes, muli-polygons, and multipoints that we may want to include at some point. As far as the initial proposed predicates I was sort of looking at what was supported by other common indexing backends like Elasticsearch to provide a glimpse of the most common types of patterns people are searching on. Dave On Tue, Aug 3, 2021 at 4:37 AM Stephen Mallette <[email protected]> wrote: > Just noticed I hadn't commented on this thread - I'm in favor of this > addition. Other graphs have already built this sort of functionality and it > is already satisfying existing use cases so we already have a model for how > this sort of functionality will work. I'd agree with Josh that there may > yet be some details on the implementation to consider but I don't have much > to add to the general proposal Dave has provided. Looks good to me. > > On Fri, Jul 23, 2021 at 11:47 AM Joshua Shinavier <[email protected]> > wrote: > > > Hi Dave, > > > > I think something like this is a very good idea, and these look like > useful > > primitives. IMO when it comes to geospatial queries, the devil is in the > > details. For example, at some point we'll have someone asking for > > double-precision lat/lon points (GPS is not that accurate, but some > > applications use computed/simulated points, or combine GPS data with > local > > position). Polygons are sometimes defined as having "holes", etc. It may > be > > worthwhile to take some direction from OGC standards like GeoSPARQL. > > > > Just an initial $0.02. Ideally, the extension would be simple for > > developers to use and understand (as this is), while also being somewhat > > future-proof and playing well with standards. > > > > Josh > > > > > > > > On Thu, Jul 22, 2021 at 2:44 PM David Bechberger <[email protected]> > > wrote: > > > > > One of the common requests from customers and users of TinkerPop is to > > add > > > support for geographic based searches (TINKERPOP-2558 > > > <https://issues.apache.org/jira/browse/TINKERPOP-2558>). In fact many > > > TinkerPop enabled database vendors such as DataStax Graph and > JanusGraph > > > have added custom predicates and libraries to handle this request. As a > > > query language framework it would make sense for TinkerPop to adopt a > > > common geo-predicate framework to provide standardization across > > providers > > > and to support this as part of the TinkerPop ecosystem. > > > > > > In consultation with some others on the project we have put together a > > > proposed scheme for supporting this in TinkerPop which I have > documented > > in > > > a gist here: > > > https://gist.github.com/bechbd/70f4ce5a537d331929ea01634b1fbaa2 > > > > > > Interested in hearing others thoughts? > > > > > > Dave > > > > > >
