Intersects geometry in search appears limited to 8K bytes in version >= 0.3.5 about pgstac

[davidraleigh]

What is the vertex count on that geometry?

At Planet I think we forced customers to submit about 400 vertex geometries to prevent to complex of computational geometry demand on intersection tests. Or maybe it was a bandwidth thing? Either way, is there a reason it has to have all the vertices? Maybe some of that work can be pushed onto the client?

[zstatmanweil]

Good question! It is a very complex polygon so ~10K vertices. I think the benefit of allowing for somewhat detailed polygons for larger areas is then you can be very specific on what you capture with the intersects search if your items happen to have relatively small geometries. 10K vertices is more than needed, but the earlier versions of pgstac didn't have this limitation so I thought maybe it wasn't on purpose.

[davidraleigh]

@zstatmanweil the maintainers probably did it on purpose. probably thinking of high availability for services and not letting computational geometry bog things down.

But I agree with you, that the vertex limit should be someplace else in the service definition, so STAC maintainers who care less about availability and more about detail can have that option.

Say hello to Chips and Caitlin for me!

[zstatmanweil]

@davidraleigh , haha will do! Its such a small geospatial world :)

Well I am happy to close it if the maintainers say it is as desired.

[bitner]

It looks like if we change the primary key on the search_wheres table to use a hash that we can get rid of this issue. While this is definitely a bug, I would expect that performance with use geometries that large isn't going to be that great in any case!