Pig UDFs

[mrflip]

I've been working on using the Esri/geometry-api-java to be a spatial framework for Pig -- have just hit the milestone of being able to do a spatial join by splitting on tiles at the mapper then joining two bags of geometries using a quadtree on the reducer.

The work currently lies within my fork of datafu for no other reason than it has a good unit test harness and I'm familiar with it. Since then I've also learned about pigeon.

This repo is probably the obvious home for the code, though. Is that interesting? Do you have feedback on the approach I'm taking?

[climbage]

This is quite interesting. I've been toying around with the idea of developing Pig equivalents to our Hive UDFs for a while now. I will discuss with our team and see if we can bring this in.

Quick question - is there a reason for some of the functions to take in OGCGeometry and return Geometry? I'll spend more time looking through the functions when I get a another chance.

[randallwhitman]

Grouping the functions by similarities such as method signature makes a lot of sense. We nominally grouped the ST_Geometry for Hive functions into ST_GeometryAccessor, ST_GeometryProcessing, and ST_GeometryRelational; but did not make real use of the base classes until recently. So far havent looked any deeper into your approach.

The developer of Pigeon has also proposed deeper integration with Pig.

[mrflip]

Can you give me a sense of when I should use OGCGeometry and when I should use Geometry?

[climbage]

I would lean towards using OGCGeometry in externally facing APIs. There are some differences in the OGC standard and our implementation that are addressed by the OGCGeometry.