Yesterday, a groper in Cairo was convicted for the first time. This is a positive step forward in taking sexual harassment in Egypt seriously. We hope our HarassMap tool will be able to help contribute to this progress.

Our HarassMap project with our colleagues at Egyptian Center for Women’s Rights will give women a way to anonymously report incidences of sexual harassment as soon as they happen, using a simple text message from their mobile phone. By mapping these reports online, the entire system will act as an advocacy, prevention, and response tool, highlighting the severity and pervasiveness of the problem.

You can read more about our HarassMap project on the 2008 USAID Development 2.0 Challenge site: http://tinyurl.com/5hu3jd HarassMap was one of the final 15 in the Challenge. We are currently searching for full funding for this project.

Noha al-Ostaz, a 27-year-old Egyptian filmmaker, was standing on the side of a busy, traffic-choked Cairo street last June when a van driver reached out of his window and groped her. Then, pulling at her body, he looked into her face and laughed. Ms. Ostaz had seen women harassed on the crowded streets of the city before, and had seen them do nothing about it. Something inside her clicked.

“I just felt, I’m never going to let this happen again,” she said in an interview on Wednesday.
So Ms. Ostaz shouted and demanded that the driver get out of the van. He refused, so she jumped on the hood, vowing she would rather be hit by the vehicle than get off and let the man drive away. A crowd formed. Finally, the driver got out of the van. Ms. Ostaz, with the help of a female friend and one or two other bystanders, then physically dragged the man to a police station about four blocks away.On Tuesday, an Egyptian judge sentenced the van driver — Sherif Jebriel, 30 — to three years imprisonment with hard labor, a remarkably lengthy jail sentence by Western standards for such an offense. He was also ordered to pay 5,001 Egyptian pounds ($895) in damages to Ms. Ostaz. Women’s rights activists in Cairo hailed the verdict and sentence, saying that to their knowledge it was the first time an Egyptian court had ordered a groper to prison.

Full article: NYTimes

I just read this Directions Mag interview with Arne Kepp of OpenGeo about GeoWebCache, a tile caching server for WMS. If you’re serving WMS using Geoserver, you probably are already aware how important this service is to increasing the speed in which your WMS data is pushed to the client. Here’s the full interview:

Directions Magazine (DM): GeoWebCache speeds up map rendering to Web map clients. How does it do that?

Arne Kepp (AK): The key to GeoWebCache’s speed improvements is to divide the world up in to preset “tiles.” This is how commercial services like Google Maps and Virtual Earth achieve their speed, but GeoWebCache is different as it operates against any compliant Web Map Service (WMS) implementation. GeoWebCache acts as a proxy between the client and the WMS server. When a client requests a tile, the program will first check whether this tile has been requested before. If a tile matching the parameters has been stored, then it will simply return that. In this case, the tile cache will often be one hundred times faster than a WMS server, because all it has to do is stream a file to the network.

If it is a request for a new tile, it will create a request for a larger tile and forward this to the WMS backend. Once the response is received, the returned data are divided into tiles again, a process called metatiling, and stored for later use. The particular tile requested by the client is then returned. In this case the tile cache is slightly slower than a direct request to the WMS server. But GeoWebCache has built in tools to seed all the tiles in advance, so that this never happens when the server is in production.

DM: Describe how it might be used to speed data being rendered from GeoServer and Google Maps into a Google Maps client.

AK: GeoWebCache includes an adapter for the Google Maps client, so it is very easy to add your layers to this service. The caching works exactly the same way as it does for WMS; GeoWebCache will look for the tile and return it, if possible, alternatively forwarding the request to the backend. The only difference is that the Google Maps API facility to request a remote tile layer uses requests with integer grid coordinates instead of bounding boxes.

There is also an adapter for MS Virtual Earth, which actually uses the same grid, just a slightly different way of addressing the tiles. This means that if you create a set of tiles for one of these services, GeoWebCache will automatically let you use them in the other as well.

Both of these work great with GeoServer, but you can put GeoWebCache in front of any WMS server and make your data available on both Google Maps and MS Virtual Earth.

DM: What’s the history of GeoWebCache? What was the impetus for developing it? How did Google contribute?

AK: The impetus to develop GeoWebCache came from a desire for a caching solution that could be easily integrated with GeoServer. OpenGeo has been focusing on an enterprise quality, fully supported open source Web application stack. GeoWebCache plays a key role in the OpenGeo Stack, sitting between OpenLayers, the JavaScript front end, and GeoServer, which serves the data from a variety of data sources like PostGIS, Oracle, ArcSDE and more. A tile cache was needed to ensure scalability and improve the user experience. Since GeoServer was written in Java it made sense to use the same language to make it easy to install on all major platforms.

Through Google Summer of Code 2007 (a Google program that offers student developers stipends to write code for various open source projects), student Chris Whitney was able to spend a summer creating what became known as jTileCache. It had very basic functionality, but also original ideas like using the Java Caching System to store image objects and compress them on the fly. Over the next nine months jTileCache was reworked into what is today known as GeoWebCache. In the summer of 2008 the project benefited from another generous Summer of Code grant, allowing a second student, Marius Suta, to contribute code that enabled XML configuration using XStream and a RESTful configuration interface. Google’s Open Source Office has also funded OpenGeo to add streaming Google Earth support to GeoServer, and GeoWebCache benefited from this, gaining the ability to tile and cache KML placemarks and vectors.

DM: GeoWebCache is licensed under LGPLv3, meaning it can be included in other open source and non-open source offerings. Has it been/will it be included in commercial or open source offerings?

AK: We chose LGPLv3 because it has always been a goal to use GeoWebCache as a library. In fact, GeoWebCache is already integrated into GeoServer 1.7.1. Currently this is not a very tight integration, but it will become more so when we start expiring tiles automatically based on transactions and similar events. There are also plans to provide caching for WFS requests.

We are not currently aware of anyone using the code for commercial products, but this is not surprising since we released the first stable version this week. OpenGeo is fully committed to open source and will not use it in closed products, but we encourage others to do so, and hope they will join the community and improve it in collaboration with all.

DM: What are the implications for GeoWebCache for mobile applications?

AK: The biggest problems on mobile devices are bandwidth and response times. Tiling alleviates the former, partially because you do not have to refresh the entire screen when you pan, only download tiles for the missing areas. GeoWebCache is a natural fit anywhere you do tiling, and the quick response ensures that no unnecessary delays are introduced.

Earlier in 2008 a user contributed a patch for GeoWebCache so that it also has an adapter for Mobile GMaps. This is software that works similarly to Google Maps, but on any Java J2ME-enabled phone. One idea for future development is to export the tiles, so that you can put them on flash memory in your device. This would make the map instantly available at no charge.

DM: Besides speeding up delivery of maps to the client, are there any other big benefits of using GeoWebCache?

AK: In addition to the adapters already mentioned, GeoWebCache also supports Google Earth. With a regular WMS server this means you can create image hierarchies like those provided by Google, where the resolution increases as you zoom in. If you work against GeoServer it is also possible to serve regionated KML. KML stands for Keyhole Markup Lanuage and is an XML based vector format. Regionating in this context means that you show a few features when you are zoomed far out, and load more as you zoom in. This means you can serve a lot of data without cluttering the display or overloading the client. Though it is still evolving and more clients have to be developed, OpenGeo is convinced that KML will play an important role for sharing information in the years to come.

Finally, not only is GeoWebCache fast, but you can also serve hundreds of simultaneous clients with a single instance of GeoWebCache. This can translate into significant cost savings if you have a busy site.

An article this morning in Directions Mag talkes extensively about “an interactive Map Center” built for a UN Humanitarian Information Center website in response to Cyclone Nargis. While I think it’s great the company, IDV Solutions, that built the map could deploy it in a week and there are some very sophisticated features bundled in the application, a few big red flags came up right away for me. First, their solution is tied exclusively to Microsoft SharePoint – integrating it with any other system does not seem to be possible. SharePoint and their solution, Visual Fusion, are both proprietary – we have no idea how these applications work under the hood and if someone else, say at the UN, wanted to replicate this system for another crisis, even if they had the expretise to do so, they could not deploy it themselves. That’s one reason why Ushahidi stands out. It’s open platform will allow any organization with the expertise to deploy their application, whereas with this solution, the UN has to keep coming back to the well. Finally, it appears to be entirely Flash-based on the front end, which might be painfully slow in low bandwidth conditions, or might not work at all on older machines with older browsers. This might look fantastic in the UN headquartes in New York, but in the field I can forsee hardware and bandwidth issues being too much for the system to overcome.

Our Crisismapper friends over at Ushahidi recently lent their alpha code to Al Jazeera to deploy War on Gaza, which is allowing civilians subjected to the fighting to post incidents via SMS, Twitter, and web form. Erik Hersman of Ushahidi has an excellent blog post here detailing how the deployment came about. Here at NiJeL, we’re very interested in how this deployment ultimately handles Arabic language support – our work on HarassMap is just beginning and we’re hoping to support both Egyptian Arabic in Arabic script and Egyptian Arabic in semi-standardized Latin script, so there could be many lessons to learn from Ushahidi and Al Jazerra’s work on this vital project.

Thanks to you both HarassMap and FloodSMS are finalists in the 2008 USAID Development 2.0 Challenge!

We will be attending the awards ceremony at the Newseum in Washington D.C. on January 8 to discuss these projects with attendeees and cheer Ushahidi on as one of the top three that may win the big award!

White papers for both projects can be found below:

HarassMap – Reporting & Mapping Sexual Harassment On The Streets Via SMS A joint concept between NiJeL and ekgaon technologies

FloodSMS – Early Detection And Warning Of Catastrophic Flooding Via SMS A Joint project between NiJeL and Egyptian Center for Woman’s Rights

Over the weekend, NASA’s Earth Observatory showcased these images from Landsat 5 showing before and after overhead views of the collapse of the earthen dam surrounding a fly ash containment pond at the Kingston Fossil Plant in Tennessee. The first image shows the intact pond from November 2008 and the second images shows the spill area on December 22 immediately after the spill occurred:

November 20, 2008 (full image)

December 22, 2008 (full image)

The comments from the Earth Observatory explain in greater detail the background of Kingston and how to interpret the imagery:

In the early morning hours of December 22, 2008, the earthen wall of a containment pond at Tennessee’s Kingston Fossil Plant gave way. The breach released 1.3 million cubic meters (1.7 cubic yards) of fly ash—a coal-combustion waste product captured and stored in wet form. As fly ash dries, it is typically moved to new containment areas to continue drying, and it was one of these areas, housing dredge cells that facilitate further drying, where the containment wall broke. Some of the sludge traveled north through a valley, and some flowed to the east, where it damaged dozens of homes. The spill infiltrated the Emory River, buried some 120 hectares (300 acres) in sludge, and even knocked a nearby home completely off its foundation.

The Thematic Mapper on NASA’s Landsat 5 satellite captured these images of the Kingston Fossil Plant and its surroundings on November 20, 2008, a month before the spill (bottom); and December 22, 2008, immediately after the spill, (top). In these false-color images, water appears blue, and sediment-laden water appears light blue. Vegetation appears green, and bare ground and urbanized areas appear pinkish-brown.

In the November image, walls visibly contain two adjacent slurry ponds at the plant—one in the northwest and one in the southeast—but in the December image, the walls of the northwestern slurry pond have given way. In this image, light blue slurry covers the ground to the north and east of the plant. Sediment also clogs the nearby Emory River, evident from the waterway’s relatively light blue color.

A report released by the Tennessee Valley Authority stated that the plant’s byproducts included arsenic, lead, chromium, manganese, and barium, although tests of drinking water upstream from the plant indicated that the water there was safe to drink. Estimates of the time required to clean up the spill ranged from weeks to years.

Officials suspected that the breach occurred along the northwest corner of the northwest slurry pond. Representatives of the Tennessee Valley Authority cited heavy rains and freezing temperatures in the days leading up to the breach as factors in the incident. A preliminary report of a plant inspection conducted in October 2008, described a wet spot on one retaining wall that might be associated with a leak. The U.S. Senate Environment and Public Works Committee scheduled a hearing on the spill for January 2009.

Happy New Year everyone! I hope that the new year has already brought you both perspective and happiness. Unfortunately, our two USAID/NetSquared Development 2.0 Challenge projects, HarassMap and FloodSMS, did not make it into the final three. While we were obviously disappointed, we are still extremely pleased and humbled that, with your help, both projects made it into the top 15. Also, we’re very excited that we have been invited to attend the awards ceremony at the Newseum in Washington D.C. on January 8, and we will be in attendance talking about NiJeL and these two worthwhile projects.

Thanks again for your support. We greatly appreciate it!