ThinkGeo.com    |     Documentation    |     Premium Support

Performance problem with GdalProjectionConverter

#1

Hi

Is there a way to optimize the performance of GdalProjectionConverter? When compared to ProjectionConverter, I notice a lag in the UI, especially when a WMS layer is present in the background. This performance issue becomes particularly noticeable when working with thousands of points in the InMemoryFeatureLayer.

Best wishse
Mahdi

#2

Hi Mahdi,

Thanks for the details. Here are a few questions and suggestions to narrow down the perf bottleneck:

  1. Threading
  • Desktop/MAUI overlays run their drawing on a background thread by default. Are you using a ThinkGeo overlay or are you doing your own reprojection calls on the UI thread?
  • If you’re calling reprojections directly in your UI code—consider offloading it to a background task (e.g. Task.Run for example).
  1. Reduce repeated work
  • Cache projected points : if your geometries aren’t moving, project them once (when you load or when the map projection changes) and store the results in your InMemoryFeatureLayer . Don’t reprojection thousands of points on every refresh.
  • Reuse a single converter instance : opening a GDAL converter is expensive. Avoid opening it every time before reprojecting a point, instead only open it once before reprojecting the first point.

Also, it seems WMS layer slows things down. If you are using Desktop or Maui, you can add Wms and the points to 2 different overlays so they can render concurrently.

Thanks,
Ben

#3

Hi Ben

We don’t have control over this. We set the Projection of InMemoryFeatureSource from the layer and added it to the Map with LayerOverlay. Is there a way to speed it up?

Best wishes
Mahdi

#4

Hi Mahdi,

Which Desktop edition and version are you using?

When you say you don’t have control over caching, do you mean you can’t cache the reprojected points? Instead of adding the original point to your InMemoryFeatureSource each time, could you add the projected point? Or is there something in your code that prevents this?

You can also enable tile caching:
layerOverlay.TileCache = new FileRasterTileCache("cacheFolderPath", "cacheId");
Note: this won’t help if your data is constantly changing.

If you add features directly via inMemoryFeatureSource.InternalFeatures , call BuildIndex() afterward to rebuild the R‑Tree index. You need to do this each time you update data through InternalFeatures . If you use layer.BeginTransaction() / layer.CommitTransaction() , the index is managed automatically.

Also, rendering thousands of points is inherently slow. Consider:

  • Showing fewer features at higher zoom levels
  • Using clustering to reduce the number of points rendered

Give these a try and let us know how it goes!

Thanks,
Ben