Re: [DISCUSS] Geo-Spatial support

[Stephen Mallette]

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  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 
> wrote:
>
> > One of the common requests from customers and users of TinkerPop is to
> add
> > support for geographic based searches (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]

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 
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 
> 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 
> > wrote:
> >
> > > One of the common requests from customers and users of TinkerPop is to
> > add
> > > support for geographic based searches (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
> > >
> >
>

[jira] [Commented] (TINKERPOP-2585) Traversal failed for different strategies order

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-2585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17392513#comment-17392513
 ] 

ASF GitHub Bot commented on TINKERPOP-2585:
---

spmallette opened a new pull request #1460:
URL: https://github.com/apache/tinkerpop/pull/1460


   https://issues.apache.org/jira/browse/TINKERPOP-2585
   
   Addressed two separate but perhaps related bugs given the strategy order 
changes for 3.5.0. The comments on each commit will provide more details.
   
   All tests pass with `docker/build.sh -t -n -i`
   
   VOTE +1


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscr...@tinkerpop.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Traversal failed for different strategies order
> ---
>
> Key: TINKERPOP-2585
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2585
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.5.0
>Reporter: Pavel
>Priority: Major
>
> Test randomly reproduced, empirically failed when PathRetractionStrategy 
> apply before InlineFilterStrategy
> https://gist.github.com/mad/3027855063bed41bae0a2aa7d2051352
> In real code strategies may change order during static vars initialized 
> {code}
> 0
> strategies[ConnectiveStrategy, EarlyLimitStrategy, IdentityRemovalStrategy, 
> MatchPredicateStrategy, RepeatUnrollStrategy, IncidentToAdjacentStrategy, 
> FilterRankingStrategy, InlineFilterStrategy, ByModulatorOptimizationStrategy, 
> CountStrategy, AdjacentToIncidentStrategy, PathRetractionStrategy, 
> LazyBarrierStrategy, TinkerGraphCountStrategy, TinkerGraphStepStrategy, 
> ProfileStrategy, StandardVerificationStrategy]
> 1
> strategies[ConnectiveStrategy, IdentityRemovalStrategy, 
> MatchPredicateStrategy, EarlyLimitStrategy, RepeatUnrollStrategy, 
> ByModulatorOptimizationStrategy, CountStrategy, IncidentToAdjacentStrategy, 
> FilterRankingStrategy, InlineFilterStrategy, PathRetractionStrategy, 
> AdjacentToIncidentStrategy, LazyBarrierStrategy, TinkerGraphCountStrategy, 
> TinkerGraphStepStrategy, ProfileStrategy, StandardVerificationStrategy]
> 2
> strategies[ConnectiveStrategy, IdentityRemovalStrategy, 
> MatchPredicateStrategy, EarlyLimitStrategy, IncidentToAdjacentStrategy, 
> FilterRankingStrategy, InlineFilterStrategy, RepeatUnrollStrategy, 
> PathRetractionStrategy, CountStrategy, AdjacentToIncidentStrategy, 
> LazyBarrierStrategy, ByModulatorOptimizationStrategy, 
> TinkerGraphCountStrategy, TinkerGraphStepStrategy, ProfileStrategy, 
> StandardVerificationStrategy]
> 3
> strategies[ConnectiveStrategy, EarlyLimitStrategy, IdentityRemovalStrategy, 
> MatchPredicateStrategy, IncidentToAdjacentStrategy, FilterRankingStrategy, 
> InlineFilterStrategy, AdjacentToIncidentStrategy, 
> ByModulatorOptimizationStrategy, RepeatUnrollStrategy, 
> PathRetractionStrategy, CountStrategy, LazyBarrierStrategy, 
> TinkerGraphCountStrategy, TinkerGraphStepStrategy, ProfileStrategy, 
> StandardVerificationStrategy]
> 4
> strategies[ConnectiveStrategy, EarlyLimitStrategy, IdentityRemovalStrategy, 
> MatchPredicateStrategy, RepeatUnrollStrategy, FilterRankingStrategy, 
> InlineFilterStrategy, IncidentToAdjacentStrategy, AdjacentToIncidentStrategy, 
> CountStrategy, PathRetractionStrategy, LazyBarrierStrategy, 
> ByModulatorOptimizationStrategy, TinkerGraphCountStrategy, 
> TinkerGraphStepStrategy, ProfileStrategy, StandardVerificationStrategy]
> 5
> strategies[ConnectiveStrategy, IdentityRemovalStrategy, 
> MatchPredicateStrategy, EarlyLimitStrategy, RepeatUnrollStrategy, 
> ByModulatorOptimizationStrategy, FilterRankingStrategy, 
> IncidentToAdjacentStrategy, InlineFilterStrategy, CountStrategy, 
> PathRetractionStrategy, AdjacentToIncidentStrategy, LazyBarrierStrategy, 
> TinkerGraphCountStrategy, TinkerGraphStepStrategy, ProfileStrategy, 
> StandardVerificationStrategy]
> 6
> strategies[ConnectiveStrategy, EarlyLimitStrategy, RepeatUnrollStrategy, 
> IdentityRemovalStrategy, MatchPredicateStrategy, FilterRankingStrategy, 
> InlineFilterStrategy, IncidentToAdjacentStrategy, AdjacentToIncidentStrategy, 
> ByModulatorOptimizationStrategy, PathRetractionStrategy, CountStrategy, 
> LazyBarrierStrategy, TinkerGraphCountStrategy, TinkerGraphStepStrategy, 
> ProfileStrategy, StandardVerificationStrategy]
> 7
> strategies[ConnectiveStrategy, EarlyLimitStrategy, IdentityRemovalStrategy, 
> MatchPredicateStrategy, FilterRankingStrategy, InlineFilterStrategy, 
> IncidentToAdjacentStrategy, AdjacentToIncidentStrategy, CountStrategy, 
> RepeatUnrollStrategy, PathRetractionStrategy, LazyBarrierStrategy, 
> ByModulatorOptimi

[jira] [Closed] (TINKERPOP-2593) Remove Groovy as a dependency from gremlin-driver

[Stephen Mallette (Jira)]

 [ 
https://issues.apache.org/jira/browse/TINKERPOP-2593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stephen Mallette closed TINKERPOP-2593.
---
Fix Version/s: 3.6.0
   Resolution: Done

> Remove Groovy as a dependency from gremlin-driver
> -
>
> Key: TINKERPOP-2593
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2593
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: driver
>Affects Versions: 3.5.0
>Reporter: Stephen Mallette
>Assignee: Stephen Mallette
>Priority: Minor
>  Labels: breaking
> Fix For: 3.6.0
>
>
> Remove the various groovy dependencies from gremlin-driver along with the 
> related {{JsonBuilder}} serialization support. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (TINKERPOP-2593) Remove Groovy as a dependency from gremlin-driver

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-2593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17392585#comment-17392585
 ] 

ASF GitHub Bot commented on TINKERPOP-2593:
---

spmallette merged pull request #1451:
URL: https://github.com/apache/tinkerpop/pull/1451


   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscr...@tinkerpop.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Remove Groovy as a dependency from gremlin-driver
> -
>
> Key: TINKERPOP-2593
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2593
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: driver
>Affects Versions: 3.5.0
>Reporter: Stephen Mallette
>Assignee: Stephen Mallette
>Priority: Minor
>  Labels: breaking
>
> Remove the various groovy dependencies from gremlin-driver along with the 
> related {{JsonBuilder}} serialization support. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Closed] (TINKERPOP-2504) Intermittently failing server/driver integration tests

[Stephen Mallette (Jira)]

 [ 
https://issues.apache.org/jira/browse/TINKERPOP-2504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stephen Mallette closed TINKERPOP-2504.
---
Fix Version/s: 3.5.2
   3.4.13
   3.6.0
 Assignee: Stephen Mallette
   Resolution: Fixed

havent seen this failure in travis or docker since the changes mentioned in the 
previous comment. think this is finally settled.

> Intermittently failing server/driver integration tests
> --
>
> Key: TINKERPOP-2504
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2504
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: driver, server
>Affects Versions: 3.4.9
>Reporter: Stephen Mallette
>Assignee: Stephen Mallette
>Priority: Minor
> Fix For: 3.6.0, 3.4.13, 3.5.2
>
>
> I've noticed this test failing intermittently on Travis and more consistently 
> on the {{master}} branch with Docker. It fails with a 
> {{ConcurrentModificationException}} (haven't been able to easily get the 
> entire stack trace thanks to the docker issue and i've not caught it 
> happening in the last few days on Travis). Adding this line of code seems to 
> have made the test pass more consistently:
> https://github.com/apache/tinkerpop/commit/4b099b3c84a350aae953cdf517aa11c7017eb2ae
> which would indicate something perhaps fishy with how hosts are being marked 
> dead and iterated. Would be nice to get rid of that little hack.
> Another common failure that is fairly consistent is with 
> {{GremlinServerAuditLogIntegrateTest.shouldAuditLogWithKrb5Authenticator}}
> {code}
> [ERROR] 
> shouldAuditLogWithKrb5Authenticator(org.apache.tinkerpop.gremlin.server.GremlinServerAuditLogIntegrateTest)
>   Time elapsed: 3.16 s  <<< ERROR!
> java.util.concurrent.ExecutionException: 
> org.apache.tinkerpop.gremlin.driver.exception.ResponseException: 
> Authenticator is not ready to handle requests
>   at 
> org.apache.tinkerpop.gremlin.server.GremlinServerAuditLogIntegrateTest.shouldAuditLogWithKrb5Authenticator(GremlinServerAuditLogIntegrateTest.java:222)
> Caused by: org.apache.tinkerpop.gremlin.driver.exception.ResponseException: 
> Authenticator is not ready to handle requests
> {code} 
> cc/ [~divijvaidya] [~HadoopMarc]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: [DISCUSS] Geo-Spatial support

[pieter gmail]

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 
> 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 
> > 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
> > > 
> > > wrote:
> > > 
> > > > One of the common requests from customers and users of TinkerPop
> > > > is to
> > > add
> > > > support for geographic based searches (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
> > > > 
> > > 
> >