It would probably be best to use some accepted standard for Geo instead of reinventing one for TP. This is the first thing that comes up on google: http://www.geoapi.org On יום ד׳, 27 בינו׳ 2016 at 18:49 Stephen Mallette <spmalle...@gmail.com> wrote:
> As of 3.1.1-incubating we will be able to serialize pretty much all of the > java.time.* classes. Graphs won't have to provide any special serializers > for those if they return those types. > > I'm less sure about how geo would work. TinkerPop creates interfaces for > Point, Polygon, whatever, with appropriate serializers then if a graph > wants to support geo, the provider could implement those interfaces in > whatever way they chose to return as results. Providers could then also > build their own predicates based on those types. is that what you're > thinking matthias? > > > > On Tue, Jan 26, 2016 at 6:52 PM, Matthias Broecheler <m...@matthiasb.com> > wrote: > > > Again, my comment is explicitly NOT about the predicates. Those are > indeed > > easy to add and implementors can differ in what they choose to provide > and > > how they implement those. > > > > I am only talking about providing a data type definition so that the > server > > and client can agree on how such data moves between the two. That's where > > things are currently getting crazy. > > > > On Tue, Jan 26, 2016 at 11:51 AM Marko Rodriguez <okramma...@gmail.com> > > wrote: > > > > > Hi, > > > > > > I think Pieter echoes my sentiment about supporting Geo and Time in > > > TinkerPop. A similar predicate people wanted in the past was RegEx. The > > > problem, ElasticSearch RegEx is different from SQL is different from > ??… > > > I'm not hip to the Geo- and Time-scene, but I suspect that Geo is a > > crazy > > > rat's nest of standards, competing Java APIs, and the like. I don''t > > think > > > TinkerPop should choose. Its really easy for graph system providers to > > > provide P-predicates for predicates they wish to support (and what is > > > specific to their database). > > > > > > > > > > > > https://github.com/apache/incubator-tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/P.java > > > > > > > > > https://github.com/apache/incubator-tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/P.java#L122-L182 > > > > > > import static > > > com.a.super.rich.company.that.hoards.cash.money.GeoP.* > > > … > > > g.V().has("location", > > > inside(circle(12.234,34.235))).out("worksFor").values("name") > > > g.V().has("location", > > > > > > outside(rectangle(12.234,34.235,23,11.57))).out("collaboratesWith").values("name") > > > > > > > > > …again, I'm not the most knowledgeable here, but when I read Pieter's > > > response, I was like -- "yea." > > > > > > Marko. > > > > > > http://markorodriguez.com > > > > > > On Jan 26, 2016, at 11:03 AM, pieter-gmail <pieter.mar...@gmail.com> > > > wrote: > > > > > > > Hi, > > > > > > > > Regarding Geo I have no strong opinions. However I thought I'll > > indicate > > > > what I have implemented in Sqlg. > > > > > > > > Postgres via Postgis has rather sophisticated gis support. In fact it > > is > > > > so sophisticated that I realized without spending considerable time > > > > learning it I don't really know what all is involved. I did however > add > > > > partial support for the types that the postgis jdbc driver supports. > > > > Point, Polygon, GeographyPoint and GeographyPolygon. Geometry being > on > > a > > > > flat earth and geography for a spherical earth. The driver has more > > > > constructs that I do not yet support. > > > > > > > > Further I did not consider adding any gremlin gis support as the gis > > > > concepts quickly become so complex that I deemed it better to leave > > this > > > > at the native sql level. Not sure what gremlin's gis ambitions are > but > > > > chances are that a single lowest common denominator Point field will > > not > > > > suffice. > > > > > > > > Cheers > > > > Pieter > > > > > > > > > > > > On 26/01/2016 03:26, Matthias Broecheler wrote: > > > >> Hello everybody, > > > >> > > > >> one of the great features of TinkerPop is that it is extensible. It > is > > > >> pretty easy for an implementation of TinkerPop Gremlin to add > support > > > for a > > > >> regular expression predicate, for instance. > > > >> > > > >> In addition, it is also possible to add custom data types based on > the > > > >> pluggable serialization system. However, unlike a custom predicate, > > > support > > > >> for custom data types requires changes both on the server side (i.e. > > > within > > > >> a particular implementation) as well as on the client side so that > > > clients > > > >> can read and make sense of such types when they are returned. > > > >> > > > >> This makes it fairly impractical for implementations to support > custom > > > data > > > >> types. While it is easy to make the necessary changes on the server > > > side, a > > > >> particular implementation would have to extend each and every driver > > of > > > the > > > >> TinkerPop ecosystem in order to have its data type supported across > > the > > > >> board. The last part is what makes it impractical. > > > >> On top of that, since TinkerPop doesn't prescribe what the data type > > > must > > > >> look like, implementations can differ in their approach making it > > > >> impossible for drivers to support them even if they invested the > > > additional > > > >> effort. > > > >> > > > >> Hence, I would like to make the case for including a "Geo" and a > > "Time" > > > >> data type. Both are very common in the database world, very well > > > understood > > > >> (i.e. in how they should be represented and what they mean) and > likely > > > to > > > >> be supported by a non-trivial number of implementations. > > > >> If TinkerPop defines what these datatypes should look like, all > > drivers > > > can > > > >> support them. > > > >> > > > >> Note, that I am only advocating to declare the data types - not the > > > >> predicates or operations on the types. The latter part could be > > > >> controversial and should be left to implementations of TinkerPop. > > > TinkerPop > > > >> should only dictate the structure of the datatype and how it is > > > serialized > > > >> (both for gryo as well as graphson) to make communication possible. > > > >> > > > >> For time, I suggest we follow the lead of Java's Instant which seems > > > well > > > >> thought out: > > > >> https://docs.oracle.com/javase/8/docs/api/java/time/Instant.html > > > >> For geo, I suggest we initially focus on 2D spherical coordinate > > > (latitude, > > > >> longitude) and the simple geometries of WKT which is widely > supported > > in > > > >> the database world: > > > >> https://en.wikipedia.org/wiki/Well-known_text > > > >> > > > >> WDYT? > > > >> Cheers, > > > >> Matthias > > > >> > > > > > > > > > > > > >
