Jun 25 2014
This is the first of what should be a set of posts that detail a server build process for the San Francisco Enterprise Geographic Information Systems Program (SFGIS) Standard Geospatial Server (SGeoS). In fact, the build work has been ongoing for several weeks and is concluding here, with OpenSim.
The motivation for including OpenSim in the platform was a desire to provide support for legacy .NET applications that may exist in various departments. In the interest of creating a Microsoft-neutral build that is framed with Open Source components, it was natural to bundle the Mono framework into the SGeoS design. And while individual department applications are their own business and not part of the standard build, OpenSim serves as an excellent demonstration of the utility of the Mono framework as included on the server. That , together with my perspective that immersive 3D clearly should be associated with geospatial servers, is why OpenSim is included in the Standard Geospatial Server.
OpenSim is not trivial by any means, and yet it is not such a resource hog that it would be infeasible to bundle it. What’s more, it is an opportunity to distribute immersive 3D technology packaged with other geospatial capabilities.
Since the build descriptions are being transcribed from a build document that is approaching 80 pages on Google Docs, it seems prudent to break it up into individual modules. And since WordPress here is configured to show older posts below newer ones—I’ll start down at the end modules and post new build descriptions for earlier modules in later days.
The original notion for SGeoS was to have modular build chapters that could provide a unit of capability. That way, only selected modules need be configured. After discussions with VMware engineers, I became intrigued by the notion of making a single server image that could run everything, all at once, and then disable unneeded featured in an actual deployment. So the build document was initially structured with module-like chapters, but in fact the server builds them all—so it’s worth viewing the build document in sequence.
The modules will probably end up numbering about 10, including packaging for production and possibly default-disabling of most items. If one watches too closely, it might seem like I’m making a countdown to completion. But this will end with a stub for deployment packaging, work back through an OpenSim build, and end up with imaging an install of CentOS 6.5 onto a new VM guest system.
Leave a Reply
You must be logged in to post a comment.