Best Practices for Formatting Arbitrarily Complicated POLYGON in Geometry Intersection

[webb-ben]

I am currently working on a project where I need to perform geometry intersections and am dealing with arbitrarily complicated POLYGON geometries. My main concern is about the length and complexity of these geometries and the limitations of using GET requests to handle them.

Given that the SensorThings API primarily supports GET requests, I am worried that the URL length might become too long, causing issues in processing these requests. Here are a few questions I have:

1. What are the best practices for formatting and handling complex POLYGON geometries in GET requests to ensure they are processed correctly?
2. Is there an alternative approach to handle complex geometries if they exceed the supported length in GET requests?

I appreciate any advice or guidance you can provide on this matter.

[hylkevds]

Good question. How complex is complex?
Google Chrome has the shortest maximum URL length, of 2083 characters. Tomcat by default allows ~8000
But regardless of that, at some point, some query is going to go over that.

One solution is to use Batch Processing, since that allows one to specify queries with POST. But you have to make sure you set up fine-grained authorisation rules, since otherwise allowing read-only users to POST would allow those users to create and delete entities. I never did get to adding the simple authorisation rules to the Batch Processing plugin, since we so far only used Batch processing for users that could edit any way.

We also have some relevant issues on the SensorThings GitHub:
opengeospatial/sensorthings#31
opengeospatial/sensorthings#110