We convert millions of points at a time between spatial references. I cannot find a way to do this except by creating millions of Map Points. Is this going to be a performance problem?
Solved! Go to Solution.
We've actually profiled this a while ago, and most of the overhead is in the projection, not the interop or object creation. There's a lot going on to get very accurate transformations and handle intersections with the horizon of each projection and a bunch of other stuff I can't even begin to understand :-). Generally that's the reason you'll see it perform slower compared to many simpler projection engines, simply because it is far more accurate and perform far more operations.
By all means, if the engine you're already using does a sufficient job for your specific use-case, just stick with that one.
I guess this is not a common request. I browsed the API again and still can't find anyway to do this. There is a PointCollection object but because it doesn't inherit Geometry, I can't Project it. I tested with 3 million points vs the open source library we've been using and ArcGIS took 4-5 times longer, which is unusable.
Have you thought about parallelizing your projections?
Also try and reuse/cache whatever you can, like get a reference to a spatial reference, and reuse it.
There's also been some big improvements, especially around how spatial references are handled, which in some cases speed up somethings up to 400x
Thanks for the reply. If you're referring to Parallel.For, yes, it does make a big difference, but it's a far cry from the library I use now. Of course, for all I know, the ESRI code could be using better algorithms and maybe that's why it takes longer. I do cache the SpatialReference. I dug a little more and creating the MapPoint objects doesn't seem to be the issue, it's the actual call to GeometryEngine.Project that is the problem.
I did just now try creating an array of MapPoints and sending those to a Multipoint so I only need one call to Project. This is much better, but not good enough. It's also pretty inefficient due to all the objects that need to be created. All of today's testing was with 100.7, .NET Framework 4.8, and x64.
We've actually profiled this a while ago, and most of the overhead is in the projection, not the interop or object creation. There's a lot going on to get very accurate transformations and handle intersections with the horizon of each projection and a bunch of other stuff I can't even begin to understand :-). Generally that's the reason you'll see it perform slower compared to many simpler projection engines, simply because it is far more accurate and perform far more operations.
By all means, if the engine you're already using does a sufficient job for your specific use-case, just stick with that one.
Current one does work but is not really updated so sometimes I need to add new projections myself. I have enough work to do as it is I'll keep checking ArcGIS on occasion. It's possible our use-case will change some day. Thanks for the replies.