I've been thinking about possibly porting an internal custom GIS application built on top of Python / PyQt / Mapscript / GDAL-OGR / PostGis to C#.

I was wondering about the maturity of the C# mapscript bindings (and to a lesser extent, the GDAL/OGR bindings). Can they be considered as mature as the current (very nice) Python bindings since I assume both are SWIG generated?

(The most time intensive part will probably be redoing the current PyQt GUI parts)

Thanks in advance for any insight / experiences concerning this topic!

  • PS: can't create the mapscript tag since I don't have 150 reputation (yet) – ChristopheD Oct 19 '10 at 23:10
  • What's your reason for migrating from Python to C#? I recommend reading joelonsoftware.com/articles/fog0000000069.html – underdark Oct 20 '10 at 6:41
  • @underdark: good (lenghty) article, I've read it somewehere in the past. There are a couple of good reasons to port it in this case though... Amongst one: I've written the initial application (and am fluent in it's codebase) but my team members aren't skilled enough in Python (most of our internal work is currently C#). I think I'll have a go at it and see how it works out ... Thanks for commenting! – ChristopheD Nov 1 '10 at 21:34

As both a GDAL and MapServer developer, I would consider the C# bindings of both projects "mature". Tamas Szekerest does a great job working to keep feature parity between the Python and C# bindings of GDAL/OGR. While the basics of both the C# and Python bindings are essentially the same in GDAL/OGR, niceties around the edges can and often are quite different (raster data handling, for example).

The MapScript bindings for both Python and C# are generated from the same SWIG interfaces, and Tamas does a great job on these as well. The SWIG bindings for MapScript in general are quite stable in the sense that they haven't changed much in the last number of years. I am not an advocate of using MapScript, however, as a number of things have changed in the last couple of years that make the enforced rigidity of MapScript no longer necessary. If you are rewriting your application, this would be a good time to take advantage of these new features.

It is now possible to use MapScript to load chunks of text-based MapFile fragments in to various MapScript objects (including an entire mapObj -- see *loadFromString methods). This means that you can utilize your own (or your language's) templating tools to generate MapFile and send it off to MapServer without laboriously instantiating tons of MapServer fooObj's, worrying about their object lifetimes, and deciphering their various relationships. Another fact that makes this approach attractive is MapServer is first and foremost a CGI application, and MapFile is the real specification of its usage -- not MapScript. Features and behaviors MapScript almost always lags what happens in MapServer's MapFile mostly because the later has many times more users and developers than the former.

Another mark for MapFile is that a modicum of backward compatibility is preserved in its parsing -- hardly any is done for MapScript. Take this opportunity to free yourself from maintaining a MapScript application and simplifying its design with your language's templating facilities and some simple MapFile fragments.

  • Thanks a lot for this insightful answer (and for the great projects GDAL and MapServer!). Also I'll take a good look at the suggestion to implement the functionality in this template the mapfile form! – ChristopheD Nov 1 '10 at 21:18

I have worked on Mapscript dll with C# with no problems at all. And also, if any new version of MapServer comes in you can rebuild the binaries easily. It should not be an issue.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.