You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@drill.apache.org by richard van der koppen <r....@gmail.com> on 2026/10/04 18:45:49 UTC

Developing a Custom UDF for Dutch Coordinate Transformation (RD to WGS84) - Looking for a code reviewer

Hi Drill Developers/experts,

I hope you are all doing well.

I have been working on a geospatial architecture use case for a while now,
researching the best way to handle large-scale Dutch coordinate
transformations directly inside Apache Drill. Next week, I am planning to
test my first working prototype / MVP for a custom Java Scalar UDF
(rd_to_wgs84).
The goal of this UDF is to perform high-performance, on-the-fly
transformations from the Dutch Rijksdriehoekscoördinaten (RD New /
Amersfoort, EPSG:28992) to global WGS84 coordinates (Latitude/Longitude,
EPSG:4326).

To maximize performance and avoid external GIS library overhead during
runtime code generation, the MVP will implement the official
Bessel-to-WGS84 polynomial regression formulas directly into the eval()
method using primitive doubles, Netty DrillBuf writes, and a VarCharHolder
output.

Since Drill UDFs operate on a very specific subset of Java and rely heavily
on internal scalar replacement, I want to make sure my implementation
strictly adheres to Drill's compilation mechanics and memory management
rules.

Once the MVP and the Maven project are up and running next week, would
anyone with experience in Drill's query engine internals and code
generation be open to reviewing the Java code? I am planning to publish the
final project as an open-source repository on GitHub to help the geospatial
data engineering community.

Any guidance or interest in doing a quick code review would be highly
appreciated! Feel free to send me a private message at this email address,
and we can discuss things privately between ourselves.

Best regards,

M.D

Re: Developing a Custom UDF for Dutch Coordinate Transformation (RD to WGS84) - Looking for a code reviewer

Posted by Charles Givre <cg...@apache.org>.
Hi there, 
Sorry for the delayed response but this went to my spam.  Are you planning on open sourcing this UDF? I’d be happy to do a code review and give you some suggestions.   Could you explain more about the use case however as I am totally unfamiliar with this. 
Thanks!
— Charles

> On Oct 4, 2026, at 14:45, richard van der koppen <r....@gmail.com> wrote:
> 
> Hi Drill Developers/experts,
> 
> I hope you are all doing well.
> 
> I have been working on a geospatial architecture use case for a while now,
> researching the best way to handle large-scale Dutch coordinate
> transformations directly inside Apache Drill. Next week, I am planning to
> test my first working prototype / MVP for a custom Java Scalar UDF
> (rd_to_wgs84).
> The goal of this UDF is to perform high-performance, on-the-fly
> transformations from the Dutch Rijksdriehoekscoördinaten (RD New /
> Amersfoort, EPSG:28992) to global WGS84 coordinates (Latitude/Longitude,
> EPSG:4326).
> 
> To maximize performance and avoid external GIS library overhead during
> runtime code generation, the MVP will implement the official
> Bessel-to-WGS84 polynomial regression formulas directly into the eval()
> method using primitive doubles, Netty DrillBuf writes, and a VarCharHolder
> output.
> 
> Since Drill UDFs operate on a very specific subset of Java and rely heavily
> on internal scalar replacement, I want to make sure my implementation
> strictly adheres to Drill's compilation mechanics and memory management
> rules.
> 
> Once the MVP and the Maven project are up and running next week, would
> anyone with experience in Drill's query engine internals and code
> generation be open to reviewing the Java code? I am planning to publish the
> final project as an open-source repository on GitHub to help the geospatial
> data engineering community.
> 
> Any guidance or interest in doing a quick code review would be highly
> appreciated! Feel free to send me a private message at this email address,
> and we can discuss things privately between ourselves.
> 
> Best regards,
> 
> M.D