An interesting article I came across recently describes the use of Internet traffic counters to track “web hits” in order to determine earthquake locations, according to NewScientistTech. Thus based on the surge in ‘Hits’ for a certain geographic area per unit time, it can be determined to some extent that something has taken place in the region - in this case, an earthquake. The study is carried out based on usage statistics of European-Mediterranean Seismological Centre. Again, social networking to the rescue…

Choice: an important thing, especially if you’re short of time and other valuable resources, especially during crisis situations. I mentioned sometime back that the goal of the SahanaGIS work was to allow existing GIS users, using existing technologies, to make use of the system without disrupting the flow:The GIS catalog is an important part of this..

The Sahana GIS catalog is an administrative module within Sahana that allows users to configure geographical data/feeds. It attempts to provide users with a somewhat intuitive interface to configure various layers, which in turn can be viewed by the Sahana GIS client which uses OpenLayers. Support for newer ‘types’ of layers/feeds are added frequently: our goal is to support quite a few of these in the near future.

At the time of writing, the following are configurable and thus usable from within Sahana: OpenStreetMap (both Mapnik and Osmarenderer), remote and local TMS layers, remote and local WMS layers, Commercial Mapping APIs: GoogleMaps, YahooMaps, Microsoft Virtual Earth, Multimap, and feeds: GeoRSS and KML. The files layer can be used to upload and use the following: KML, GML, OSM. WMS and TMS layers accept multiple layers within them. Layers can be enabled by the administrator so that they are visible within the OL mapping client by default. This works perfectly for data from custom mapping servers: either local or remote. Maps served as WMS via mapping servers such as UMN/Mapserver can be accessed by configuring the WMS layer in the GIS catalog. Likewise, tiles from TileCache and the likes can be accessed by configuring TMS to point to them. In turn, the configured layers are displayed within the mapping client, depending on their visibility settings. There are a lot of items on the roadmap as well: including WFS support… Check out the Sahana GIS Infrastructure Roadmap to see what we’re upto…

Google has released its revolutionary mapping client, Google Earth, for web-browsers, according to Google LatLong

Today, I’m happy to announce the release of the new Google Earth Browser Plug-in, which brings the full power of Google Earth to the web, embeddable within your own web site. Driven by an extensive JavaScript API, you can control the camera; create lines, markers, and polygons; import 3D models from the web and overlay them anywhere on the planet.

However, as is the case with many Google applications (including Google Earth for some time), us Linux users have to wait - again. The technology is currently available to Firefox 2 and Internet Explorer 6/7 on MS Windows only. However, I guess this move will create a lot of interest - Google Maps API certainly did - add 3D ability to that now, and imagine the possibilities !

We used Google Maps API within Sahana as the primary plugin for GIS. We now concentrate on having OpenLayers as the main mapping client, allowing a host of services to be accessed through it, including the GoogleMaps API. So once the Linux/Mac ports are done, I wonder if and when OpenLayers support for GE would be on the roadmap..

Along with the recent surge in the Geographical Information System (GIS) development stuff of Sahana, I guess its high time I posted something on this:  The Sahana Disaster Management System’s geographical capability has been improving in recent times. The purpose of GIS development in Sahana (a.k.a SahanaGIS) is  not to create a fully functional GIS: there are enough and more brilliant solutions out there: rather, our focus is on allowing users to get the maximum geographical capabilty out of the system, by making use of existing systems and standards.

The SahanaGIS is built on a distributed architecture of small reusable components that serve each other. Each component is standard-compliant based on Open Standards, and makes use of existing F/OSS projects and services. This allows for standards based interoperability with existing systems, and existing F/OSS or proprietary GIS solutions can be used interchangeably with these components to achieve full GIS capability within Sahana through collaboration. At deployment, Sahana would probably contain a rich set of data regarding the disaster it is setup to manage: the ability to share this data integrated with spatial data of the region would mean a rich set of geographical data being served out to the GIS community in times of a disaster. This project also provides the ability to manage the Sahana data sources, feeds, files and mapping APIs via a GIS catalog module, allowing a wide variety of sources to be added and configured on the fly, which means that a fairly substantial GIS can be configured by someone with little or no experience of GIS.

SahanaGIS provides the flexibility for users to use tools of their preference: we do not intend to build a newer tool to replace existing tools that users are comfortable with. For instance, data served out of Sahana can be viewed using the inbuilt Sahana GIS client built uing OpenLayers. Alternatively, users can use the myriad of GIS clients out there: qGIS, uDig and the likes, to acheive the same. Similarly, mapping servers such as UMN/Mapserver can be setup to serve data to Sahana clients. Thus, Sahana can be used within existing GIS infrastructure, without distrupting the flow by requiring users to migrate to newer software: which is not practical during disasters, especially considering the level of expertise required in Geographical Science.
Well, that’s a start from me: definitely more stuff to come…