在Dotspatial中从FilePath加载栅格数据

Question

我在DotSpatial

中有这么简单的代码

var raster = Raster.OpenFile("X://Data//4mr_project.tif");

为什么栅格只是获得空值？

我在同一目录中也有.aux，.ovr，.tfw个文件。

编辑：

我发现下面这行正常：

var featureSet = FeatureSet.Open("X:\\Test Data\\shap\\edited.shp")

因为Dotspatial默认情况下可以加载.shp文件。但是加载栅格数据.tif格式，Dotspatial需要GDAL个扩展名。现在的问题是如何使用GDAL在Dotspatial中手动加载C#个扩展名。

Answer 1

通过使用AppManager组件，您可以在自己的应用程序中支持GDAL扩展。您可以将其拖放到表单上。这允许来自GDAL数据扩展的支持，并且还将支持其他插件。以下是将AppManager添加到表单上只有Map的新项目的基本步骤。

1）在Visual Studio工具箱中，右键单击并单击“选择项目”

2）在对话框中，选择“浏览”并浏览到DotSpatial.Controls.dll库。

3）根据需要单击“确定”以关闭对话框并返回“工具箱”。

4）找到刚刚在工具箱中添加的AppManager组件。

5）将AppManager组件拖到表单上。 （不在地图上，但在表格上）。您的表单下方的新实例应显示在非可视组件列表中。

6）选择此组件以在“属性”对话框中查看其属性。

7）设置appManager（或其他组件，如果您正在使用它们）的地图。

8）GDAL组件甚至不需要定义Map以便工作，它应该正常工作。但是你需要GDAL扩展。您可以在“Windows Extensions”文件夹中找到DotSpatial.Data.Rasters.GdalExtension。确保输出目录中有一个类似的文件夹，其中包含必要的GdalExtension。一种方法是确保手动将其放在最终的分发文件夹中。

9）（可选）您可以使用的一个技巧是确保在发布文件夹中包含GDAL插件，以将库添加为内容。这样，无论您是在处理调试版本还是发布版本，它都将确保GDAL数据扩展使其成为输出文件夹。

10）确保您正在使用的目录（如“Windows Extensions”）列在AppManager的Directories属性中。下图显示了“Application Extensions”和“Plugins”的默认文件夹。我认为它最初是“Application Extensions”，但后来更新为“Windows Extensions”。不幸的是，我认为他们没有更新默认文件夹。

11）在某处的代码中（可能在表单构造函数中），您需要调用appManager1.LoadExtensions（）;如果您不调用它，即使您将GDAL库作为项目的一部分，它也不会实际加载GDAL扩展名。

12）将SpatialDockManager，SpatialHeaderManager，SpatialStatusStrip添加到项目中。然后将这些属性分配给AppManager上的属性，就像执行地图一样。由于我离开之后并且在我离开后实现的原因，先前开放式设计结构已经改变，现在如果程序不包含这些内容但是您尝试使用扩展，它将抛出消息框错误。 “ProgressHandler”属性采用SpatialStatusStrip。

在完成所有这12个步骤（并在x86模式下运行项目）后，您在初始问题中发布的栅格代码可以正常工作，您可以打开地理位置。我还将GDAL扩展推送到根“Application Extensions”目录，同时尝试让它工作，但我认为你不必这样做。如果它在子文件夹中，它应该有效。

Answer 2

很抱歉这么晚（希望永远不会太晚），但是如果您希望在不使用AppManager的情况下使用该插件，因为您可能正在编写一些自定义内容，并且不想依赖于主要的DotSpatial应用程序框架（请注意（AppManager利用一些稍微先进的“魔术”使它们一起工作），您可以自己完成以下几个简单任务：

1）添加对该文件的引用

（DotSpatial发行文件夹）\ Windows  Extensions \ DotSpatial.Data.Rasters.GdalExtension.dll

到您的项目（这是GdalExtension插件的主要输出文件）。

2）该文件夹还包含一个 gdal 子文件夹。将文件夹本身原样复制到您的输出路径（通常为 ... \ bin \ Release \ 或 ... \ bin \ Debug \ ，具体取决于您的组态）。当然，在您的最终项目中，您可能希望使用构建后复制事件来自动执行该过程，或者仅将该文件夹作为内容包含在应用程序构建输出中，就像Ted在其答案的第9步中提到的那样。 >

3）尽早在您的代码库中，创建一个新的 GdalRasterProvider ，该文件现在应由在步骤1中添加的dll文件引用。这意味着，将以下行添加到您的项目

var grp = new DotSpatial.Data.Rasters.GdalExtension.GdalRasterProvider();

此后，帖子中的第一行代码应按预期工作。因此，从技术上讲，原始问题的答案是DefaultDataManager类找不到任何合适的提供程序来执行实际加载Raster文件的任务。因此，您剩下一个空变量。

有趣的是，您不需要在任何地方保存引用（即，使用变量grp进行任何操作）。如果检查源代码，则构造函数本身将执行将自身添加到DefaultDataProvider.PreferredProviders字典的任务，该字典最终将在调用 Raster.Open（string）方法的幕后被调用。唯一的“困难到无法完成”的部分只是在您的应用程序输出路径中复制gdal文件夹，因为GDAL扩展名在任何提供程序实例化时都会加载位于其中的许多引用，并且加载基于“ gdal”子文件夹，位于应用程序所在的文件夹中并从中执行。

（请注意，该插件还包含另外两个提供程序（GdalImageProvider和OgrDataProvider）。要使这两个提供程序正常工作，您需要实例化它们，还需要将它们手动添加到DefaultDataProvider的PreferredProviders字典中，通常也要早于您的应用代码）