There are already Windows packages available for MapServer ready for deployment. However if you need to make a modification to the source files, apply a patch, or just want to see how MapServer is made then you can build MapServer from its C source files. Thanks to the ready made build kits this process should only take 10-15 minutes from start to finish.
Prerequisites: Microsoft Visual Studio with C++
1. Download the MapServer SDK (Software Development Kit) from http://www.gisinternals.com/sdk/. I’m using Visual Studio 2010, and building on a 32-bit Windows machine (still using XP..), so I’m using release-1600-dev
These build kits, provided by one of MapServer’s developers Tamas Szekeres, contain everything you need to compile both MapServer and GDAL. Checking out all the files from the MapServer SVN repository is not enough, as this does not contain the GDAL or RegEx dependencies (DLLs that MapServer depends on), or SWIG – a tool used to create MapScript files for each of the different scripting languages available in MapServer such as Python, Ruby, PHP, Perl etc.
This post details how to add a Subversion (SVN) plugin to Aptana to allow you to compare OpenLayers code with previous versions.
A straw poll was taken on the OpenLayers mailing list in April 2010, and OpenLayers v3 development is taking place in git, with the central repository stored on GitHub. This means working with SVN and OpenLayers may become redundant. However as many OSGEO projects are stored in SVN with no current plans to move the same plugin and knowledge of working with SVN will still be useful.
For further details on working with SVN there is a free e-book “Version Control with Subversion” available at http://svnbook.red-bean.com/
Installing the Plugin
1. Open the Plugin Manager, by clicking on the green jigsaw piece in the toolbar below.
First a little background on what I was trying to achieve. I am developing a GIS that has both a web and desktop component. It’s built using SQL Server 2008, MapServer, OpenLayers, and using MapInfo and QGIS for desktop connections.
On the web system I have an OpenLayers map, with an OpenStreetMap background layer. As with nearly all the online tiling services, these are projected in EPSG:900913 (the Web Mercator / Google projection).
I wanted to display a road network on top of these as a WFS (Web Feature Service). The source data is defined in the Irish National Grid projection (EPSG:29902).
At the same time I also wanted people to be able to connect to the WFS via a desktop GIS client using the Irish National Grid projection. Read more
This question was posed on the GIS Stack Exchange, and the replies include a number of interesting approaches. Below is another one.
Why not just use .NET?
I have several years worth of DLLs built using VB.NET and ArcObjects. Recently I’ve been using more and more open-source libraries, the majority of which can be manipulated using Python.
A major advantage of using a interpreted language (rather than one that needs to compile) like Python is that you can easily change paths and variables in a script.
You can deliver a folder of .NET ArcObjects DLLs, a sample Python script and an end user can automate their workflow themselves. This negates the requirement to build a UI on top of your code as a (Python familiar) user can script it themselves.
DLLs still have their place as ArcObjects includes many functions not available in the ESRI Python libraries. It is also easier to write and test ArcObjects code in Visual Studio with all the advantages of error checking and auto-completion. Read more
The same origin policy prevents code from one domain accessing data from a different domain. For a mapping site requests for KML, GeoRSS, WFS services, and some WMS operations are all affected by this policy, and therefore require a range of workarounds, usually involving a proxy.
Thanks to this Unwritten Guide to Yahoo Query Language it became apparent you can get Yahoo to automatically do this wrapping for you. Whilst using YQL is still technically a proxy, it’s a proxy you don’t have to worry about maintaining. Read more