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 >
