Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
GeometryCursor:: estimateMemorySize
See original GitHub issueSimilar to #156, we would like to investigate whether it’s possible to add a similar API to GeometryCursor to enable us to estimate the memory size for long running operations involving GeometryCursors. For example, it would be nice to get a point in time estimate of how much memory OperatorUnionCursor is using, for similar reasons as stated in #156.
It would have the same signature as what is found in OGCGeometry:
GeometryCursor unioningCursor = OperatorUnion.local().execute(input, null, null);
// ...
System.out.println(unioningCursor.estimateMemorySize());
Are there any objections to adding such an API?
Issue Analytics
- State:
- Created 5 years ago
- Comments:6 (3 by maintainers)
Top Results From Across the Web
Top Related Medium Post
Top Related StackOverflow Question
Troubleshoot Live Code
Top Related Reddit Thread
Top Related Hackernoon Post
Top Related Tweet
Top Related Dev.to Post
Top Related Hashnode Post
@tdcmeehan Could you explain the pattern how you are planning to use this?
Maybe you should do external batching. For anything large you may want to batch geometries spatially.
The pattern is essentially the same as ST_Aggr_Union. I’ll do the batching outside of the library. Thanks!