Rebooting the DotSpatial Steering Committee

Coordinator
Sep 10, 2013 at 3:29 PM
Hi all, we are interested in rebooting our DotSpatial steering committee. If any of you are using DotSpatial in a project or are otherwise interested in the success of the project, we would encourage self-nominations for our committee.

Just post a reply to this comment and give us a quick introduction.

Thanks,

Dan Ames - DotSpatial Project Manager
Developer
Sep 10, 2013 at 10:24 PM
Hello,

My name is Kyle Ellison. I have been a developer on DotSpatial since 2010. I am a software architect for GeoCue Corp. in Madison, AL (USA). I recommended and led the effort at our company to incorporate DotSpatial as a core component of our commercially available geospatial production management software. The DotSpatial version of this software has been in use in the field for over 2 years. I have been a proponent of making DotSpatial perform well in demanding situations where large datasets are the norm.

Thanks,
Kyle
Sep 13, 2013 at 9:11 PM
Not sure what a "steering committee" does, but for a starter how about just having someone at home here? The simple patch I submitted in May has not been applied yet. It fixes 3 bugs.

If people perceive that a project is moribund, they typically suspend working with it, as I have.

Thanks.

-Phil
Sep 15, 2013 at 1:38 PM
Hi,

In the past I understood that DS is the next version of MapWindows, using the .net framework and abandon the OCX component.
So I thought the developers from MapWindows will migrate to DS during the next years.
But now I saw that a new MapWindows version is coming out.

https://mapwindow5.codeplex.com/

Why we need to develop 2 projects so similar? Why not make a base component and add special extension libraries for special functions and interfaces.

Better one active project than 2 projects with low contributions.

Thanks

Thomas
Sep 15, 2013 at 4:06 PM
Why we need to develop 2 projects so similar?
I see MapWindow and DotSpatial as two rather different projects.

MW is a good standalone GIS for ad hoc work. It can be easily extended with C#/VB.NET plugins (eg, add a menu for your own custom features). MW is Windows only obviously because of its dependence on a huge .ocx.

Main competitor to MW is probably something like QGIS, also a good standalone GIS for ad hoc work. It can similarly be extended with Python plugins. QGIS is fully cross-platform (Win, Linux, OS X) and uses the Qt libraries for UI.

I see DotSpatial as more of a library of both (a) WinForm-based presentation assemblies and (b) non-UI geoprocessing assemblies. You can use these assemblies to build your own branded GIS, for example (or even a MapWindow GIS).

What interested me about DS was (b) - and also the DotSpatial.WebControls assembly, which is only available as source since it's very much incomplete. WebControls allows you to create ASP.NET Web apps and WebControls also works fine with Mono on a Linux server (and even on OS X). Even the DS extension system seems to work cross-platform - eg, the GDAL native library, which is required to do any work with grids (if you can figure out how to build the C# wrappers for Linux/OS X).

A competitor to DS's non-UI geoprocessing / server use would be SAGA, which has both Python and command line interfaces. SAGA is also cross-platform (Win, Linux, OS X) and uses wxWidgets for UI.

A challenge to both MW and DS is that they're kind of stuck in the Windows world. A challenge to all of these projects is that they're kind of stuck in the desktop world, whereas the real world is rapidly moving to Web and mobile. Explain to someone who has worked with spectacular interactive maps with MapBox on an iPad why your GIS tool only works on Windows.

Thanks.

-Phil
Developer
Sep 16, 2013 at 5:14 PM
I have not ever worked in Dan Ames' lab, but I have been involved from a distance for a while, so I thought maybe my perspective might be useful.

MapWindow 4, with most of the functionality in the OCX and in plugins, makes no apologies about being a Windows application. It was designed from the start to be the best Windows GIS that it could be, partly in reaction to cross-platform open source GIS of the day that did not look very good Windows. The OCX has been re-used by several projects to build their own Windows application, some with interactive maps and others with only background geoprocessing.

At one point, it was thought that DotSpatial would replace MapWindow 4, but it turns out that MapWindow 4 has developed its own community which is happy and is not very interested in moving to something new, so MapWindow 4 continues to have a life of its own.

DotSpatial was started to see whether we could make a pure .Net GIS library and map control. This was partly motivated by wanting it to be more cross-platform. Avoiding using an OCX that requires registration on Windows was also seen as a way to solve installation troubles, especially when installing more than one program that uses MapWindow OCX on the same computer. DotSpatial has been less focused on making a full-featured GIS application and more focused on re-usable libraries, based on how much more interest there was in re-using the MW4 library than in using the full application.

Re-implementing all the GDAL grid handling in .Net has not seemed worthwhile, so DotSpatial does depend on the GDAL libraries, but they are not the same barrier to installation and to cross-platform usage that the OCX was.

I don't think there is necessarily much point in debating the relative merits of cross-platform vs. Windows native here, but my opinion is that any software will work best on the platform used by the developers. DotSpatial has plenty of potential for cross-platform use and only needs developers with interest to keep pushing on keeping it compatible with Mono and providing smooth ways to get the source code and compiled packages working well on OSX and Linux. Most developers to date have been focused on Windows, but there has definitely been interest in other platforms.

Although I like the idea of cross-platform and of web-based front end, for my own use it only matters how well it works on Windows because that is the platform my company develops for. We program mostly in VB.Net. I also use C# which is really very similar to VB.Net. I can program in C++ if I have to, but would rather not. Others in my company have no interest in C++ or Python, so MapWindow and DotSpatial are a better match for us than any of the other open source GIS out there.
Sep 16, 2013 at 6:03 PM
DotSpatial has been less focused on making a full-featured GIS application and more focused on re-usable libraries
Yes, a good idea.
Re-implementing all the GDAL grid handling in .Net has not seemed worthwhile, so DotSpatial does depend on the GDAL libraries
The right decision, although once you start mixing unmanaged code with managed code, you start losing some of the managed code advantage.
Others in my company have no interest in C++ or Python, so MapWindow and DotSpatial are a better match for us than any of the other open source GIS out there.
Back when it looked like .NET was going to take over the world, it might have seemed like a no-brainer to go all-.NET as opposed to, say, the GDAL approach (C++ libs with C interface that can be wrapped in C#). Now that it's clear that isn't going to happen, maybe not so much. Even MS seems conflicted about .NET.

If you look at the typical Silicon Valley / SOMA district start-up, you see a pattern emerging: Web-based, eg, deploy to Amazon Linux servers, PostgreSQL, Python, etc. That's the stack you see over and over these days. At least for these companies, Google seems to be what they're modeled after, not MS.

Note that you can probably use IronPython with DS non-UI assemblies. I've used it with some of my assemblies and it works fine (note that it's Python 2.7, not 3.x).

The fate of Mono on Linux is also kind of up in the air. Xamarin is now the Mono developer and they seem interested only in iOS, Android and Mac. I'm not even sure how you would get the latest Mono for Linux short of building it yourself. Also note that the VB.NET compiler does not appear to be included with Mono anymore - again, you would need to build it yourself. This shouldn't affect VB.NET assemblies compiled with MS's compiler, but it might make C# a better choice if you ever think you might need to compile on Linux.

Thanks.

-Phil