Create a Custom Layer Provider

Developer
Mar 2, 2011 at 12:29 AM

Hi Team,

We need to create a new type of Layer for displaying LIDAR data points in DotSpatial. We can't use the built-in MapPointLayer and FeatureSet, because the LIDAR datasets contain a huge number of points. Therefore, the points have to be drawn on demand, based on the current extent and zoom level.

Does anybody here have experience with creating a custom layer provider for DotSpatial? If yes, could you please give us some hints:

  1. Which interfaces to implement?
  2. How to make the custom layer provider DLL recognized by DotSpatial (there are examples for VectorDataProvider and RasterDataProvider, but not for LayerProvider)

Thanks,

Jiri

Apr 6, 2011 at 11:19 PM

Team,

I would also benefit from a layer (data format) that can handle LiDAR points loaded from LAS file format(s).  I can offer extensive .net code for loading/saving LAS data, but have hit a brick wall on displaying a LiDAR point feature set populated with LiDAR data in map view.  Typical point files have around 5-10 million points and 12-16 fields/columns per point/record.  I would suggest making the layer type basically a mirror of the LAS version 1.2 definition.  Once created, it would be simple to maintain the layer definition to match future LAS file versions.  Please let me know if I can assist in development on this and related issues.

It seems that Jiri's 2nd question is the most pertinent, and I would also add that it must developed in 64-bit.

Thanks,

 

Matt

Coordinator
Apr 7, 2011 at 3:04 AM

Matt, 

The DotSpatial libraries are set up such that everything is defined by an interface that is then given specific implementations. So the LiDAR provider could be implemented at a low level by implementing the iFeatureData interface or a bit higher up by implementing the iPointFeatureData interface, or even higher up the chain by implementing the iMapLayer interface directly. The difference is that the iMapLayer interface is at the drawing level whereas the FeatureData interfaces are at a data read/write level and can be drawn by existing implementations of MapLayer. So basically if you or someone wanted to try to implement a LiDAR data type you would have to decide at which point to implement it. I would do it as an IMapLayer so that you can handle the file reading and writing separately and have some method for only grabbing a subsample of the points to actually show in the map on every map zoom/redraw. 

So that's the general approach. I don't have anyone in my lab right now working on this, so maybe it's something you could try taking a crack at. I (and others) could try to guide you through it using this discussion forum...

- Dan

Apr 8, 2011 at 12:45 AM

Hi Dan,

It makes sense to implement as an IMapLayer.  LiDAR data sets are large and can easily create memory issues and/or unexpected failures, so simplicity and reduction of overhead should be primary factors for development.  There are two reasons to explore FeatureData interfaces before answering this question, however.  One, is ease of implementation for users by extending ASPRS compliant reading/writing libraries for LAS data (something that really isn't trivial code and a reason LibLas is gaining popularity).  Two, if the data are loaded into a FeatureSet then all processes, including visual display in a map view, can be done w/o redundancy (i.e., loading LiDAR points into memory and then creating all or a subset in IMapLayer creates extra memory overhead, rather than just using a LiDAR FeatureSet for analysis or display).  Which interface yields lower memory overhead and rapid access for analysis is an open question.  My guess is that we will not know until the layer or featureset is defined.  I'll start looking into creating an interface. 

It would be great if you can pass along documentation that would help me get started.

Thanks,

Matt

Coordinator
Apr 8, 2011 at 2:51 PM

This is great, Matt. Any progress you can make on this will be much appreciated and highly useful. Please keep me/us posted through this forum.

- Dan
--------
Daniel P. Ames Ph.D.
Idaho State University Dept. of Geosciences
dan.ames@isu.edu
--------
Sent from my Droid

On Apr 7, 2011 6:46 PM, "mboyd" <notifications@codeplex.com> wrote:
> From: mboyd
>
> Hi Dan,It makes sense to implement as an IMapLayer. LiDAR data sets are large and can easily create memory issues and/or unexpected failures, so simplicity and reduction of overhead should be primary factors for development. There are two reasons to explore FeatureData interfaces before answering this question, however. One, is ease of implementation for users by extending ASPRS compliant reading/writing libraries for LAS data (something that really isn't trivial code and a reason LibLas is gaining popularity). Two, if the data are loaded into a FeatureSet then all processes, including visual display in a map view, can be done w/o redundancy (i.e., loading LiDAR points into memory and then creating all or a subset in IMapLayer creates extra memory overhead, rather than just using a LiDAR FeatureSet for analysis or display). Which interface yields lower memory overhead and rapid access for analysis is an open question. My guess is that we will not know until the layer or featureset is defined. I'll start looking into creating an interface. It would be great if you can pass along documentation that would help me get started.Thanks,Matt
>
>