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 <spmalle...@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 <j...@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
> > > <d...@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
> > > >
> > >
> >
