Re: [DISCUSS] Geo-Spatial support

[Stephen Mallette <sp...@gmail.com>]

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 <jo...@fortytwo.net> 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 <da...@bechberger.com>
> 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
> >
>

Re: [DISCUSS] Geo-Spatial support

[pieter gmail <pi...@gmail.com>]

Hi,

I'd suggest having a look at Postgis (https://postgis.net/) for some
inspiration. Its mature and rather sophisticated with a small army of
functions. They have two types, 'geometry' for standard projection
functions and 'geography' for 3D spherical maths functions.

Postgis also has a JDBC driver with a bunch of types which might help
thinking about standards.

LinearRing
MultiPoint
LineString
MultiLineString
Polygon
GeographyPolygon
MultiPolygon
GeometryCollection
Point
GeographyPoint

We use is extensively. I added some types and basic functions to Sqlg
but I gave up as it felt like a "adds no value layer". It was far
easier to let our engineers work at the Postgis level as it is well
documented and with lots of support out there in the wild.

Perhaps in our case the 'g.cyhper("some cypher")' way would suit us
better, 

i.e. 

'graph.postgis("SELECT superhero.name
    FROM city, superhero
    WHERE ST_Contains(city.geom, superhero.geom)
    AND city.name = 'Gotham';"
)'

I'd also suggest some support for Geojson

Postgis can convert any query's result into geojson which one then
directly pass to the map tool. In our case it completely removed the
need for the javascript folk to sweat away at endless performance
issues and gis complications.  

Cheers
Pieter

On Tue, 2021-08-03 at 11:50 -0800, David Bechberger wrote:
> 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 <sp...@gmail.com>
> 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 <jo...@fortytwo.net>
> > 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
> > > <da...@bechberger.com>
> > > 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
> > > > 
> > > 
> > 

Re: [DISCUSS] Geo-Spatial support

[David Bechberger <da...@bechberger.com>]

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 <sp...@gmail.com>
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 <jo...@fortytwo.net>
> 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 <da...@bechberger.com>
> > 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
> > >
> >
>