General Mapping Questions:
MapServer Questions:
Why didn't you just use OpenMap?
NeXtMidas actually uses some of the OpenMap libraries. However OpenMap has a number of limitations that prevent its use with the large data sets commonly seen by NeXtMidas users (often 1-2TB of data). The MAP Option Tree for NeXtMidas addressed these issues with:
Additionally OpenMap does not an provide easy way to add features (like ellipses) on to the maps. (It is possible... but with some difficulty.)
See Other Mapping Applications for a comparison of some of the mapping applications available.
Why didn't you just use GoogleMaps?
NeXtMidas can act as a client to the GoogleMaps server. However, we can't use because our customers have internal networks that do not have direct access to one of the Google servers. Also, our users' require more custom control over the maps than GoogleMaps makes available. It was decided that the cost of making our own Google-like server was less expensive than purchasing several copies of the Google server and paying Google to add the required features.
There is also a philosophical issue here of choosing COTS (Commercial Off-The-Shelf) vs GOTS (Government Off-The-Shelf) software. Commercial suppliers tend to cater to their largest market base (for Google this is advertisers and they cater to helping people find local retailers). With GOTS software you get a product designed for use by a government customer that meets the needs of that customer. With GOTS you also get full support including on-site support from the developers.
Why didn't you just use GoogleEarth?
Short answer: GoogleEarth only runs on Windows and our users require support for Linux, Sun, and Windows. Also the Google map server is not available on the correct network (see Why didn't you just use GoogleMaps?).
See Other Mapping Applications for a comparison of some of the mapping applications available.
Why didn't you just use OpenEV?
OpenEV is an imagery analysis tool developed by Vexcel Canada. It is designed to be "tightly integrated with Vexcel Canada's commercial software products" (OpenEV web site). It is a file-based tool with an interface similar to OpenMap (see Why didn't you just use OpenMap?). While it claims to be able to "gracefully handle very large (gigabyte) raster datasets" (OpenEV web site), is designed for the viewing of maps and does not have an easy way of adding features and ellipses on top of the maps.
See Other Mapping Applications for a comparison of some of the mapping applications available.
Why didn't you just use the OpenGIS WMS?
Short Answer: The reference implementation of the OpenGIS WMS (Web Map Server) from Demis is extremely limited. It only runs on Windows and does not handle the NGA file types (including RPF), that need to be supported. For more details please see the discussion on Why didn't you use the OpenGIS WMS protocol?.
See Other Mapping Applications for a comparison of some of the mapping applications available.
Why didn't you use the same protocol as Google?
We did, as much as was possible, but had to make some minor changes in order handle some of the special requirements from NeXtMidas users.
Why didn't you use the same projection as Google?
Google uses the Mercator projection. However the NGA data we needed to work with was in LatLon (Equirectangular) projection. LatLon was also the default projection used by most users. By keeping the images in LatLon at all times we were able to improve speed and image-clarity for the majority of users.
Why didn't you use the OpenGIS WMS protocol?
The OpenGIS Web Map Service (WMS) is similar to what we are doing (they even use some of the same examples files). The only primciple difference is in the request (we follow the Google approach):
There is no reason we couldn't do both from a technical side. However, from a practical side the Google approach forces all users to use identically-sized tiles at pre-determined locations. The Google approach makes it possible to cache images as well as pre-render them. This improves performance by eliminating the first of the three "slow spots" in the map server concept:
The WMS approach (which we initially considered... and people often ask about) basically eliminates any options for caching (the odds of multiple users requesting images that were exactly the same - not off by 0.01 deg - is very low). The other problem is that if a user pans their map the WMS approach re-fetches an entire new image, whereas a Google-like client is able to cache the tiles they have viewed and only requests tiles for the "newly visible" area.
One benefit of the WMS approach would be reduced transfer time over the network since you never request "extra" data and since everything is done with a single request. (The NeXtEarth client does the requests in parallel so the overhead of the "extra" requests is hidden from the user, to some extent.)
That said, if you are doing STATIC maps (such as in a web page) the WMS approach would be better because you have more control over what is returned, however the Google approach is better for DYNAMIC applications (such as the NeXtMidas client) which can easily work around the limitiations of fixed-size, fixed-AoI tiles.
When we designed the map server we focused on the DYNAMIC application. But since the syntax of the Google and WMS protocols is substantially different and since the WMS protocol includes a "Service=WMS" field, it would not be too difficult for the NeXtMidas Map Server to support both protocols simultaneously.
We have not added this feature only because we have not had a specific requirement to do so. If this is a feature that you require, please contact the NeXtMidas team and it can be added in.