humanitarian.info

Security Reporting, Accessible Maps and GeoRSS

with 21 comments

21 Responses to 'Security Reporting, Accessible Maps and GeoRSS'

Subscribe to comments with RSS or TrackBack to 'Security Reporting, Accessible Maps and GeoRSS'.

1. Perhaps what you want is something like this? You give it GeoRSS and it does the right magic to parse the GeoRSS and write the JavaScript to put the GeoRSS on top of a Google Map. GeoRSS seems to be well developed, if not widely known and supported yet in map rendering tools, so I agree with you that it’s the right way to hold.

   Then you just have a problem of conveniently setting the locations of the items without going into Notepad and copying and pasting Lat/Long info from Google Maps. I don’t know what the right solution is for that… It would be cool if there was a little industry of Google Reader mashups that we could leverage, but I don’t know of such a thing. I’d like to tell my Google Reader to let me use Google Maps to add a location to a story, then have Google Reader re-export a location-annotated version of the original RSS feed. (Paul, can we get a Google Reader guy on this CC line and find out if such a thing already exists?)

   I am working on some ideas to make Google Earth and Google Maps more usable in an off-line or low-bandwidth scenario. I’ll keep you guys in the loop if I come up with anything that’s worth sharing. (RIght now, it’s vaporware. Basically, I’d like to have a plugin for a Linksys router running OpenWRT that can mount a DVD via CIFS and serve the Google Imagry off of the DVD. Then I just need Google to make the DVD, or at least give me permission to make it for my own use!) I’m also considering using Google Gears to store the map images in the browser for offline use, but I don’t like that as much as the transparent solution.

   

   Jeff Allen

   19 Aug 07 at 12:17
2. GeoRSS is now supported by every major mapping API - Google, Yahoo, MSFT, etc. and it’s quite easy, if you know javascript, to put layer a GeoRSS file over any of these directly. With Google Maps, you can even just go to the site and paste in the address of a GeoRSS feed and it will be rendered there. And with Mapufacture and my site :), you can assemble multiple feeds together on a single map easily, without any programming.

   There’s loads of ways of authoring GeoRSS. If you have a “vanilla” RSS feed, send it through Geonames RSS to GeoRSS converter. Sites like platial, tagzania, and google’s my maps allow you to simply author annotations, and export the results as GeoRSS. There’s a plugin for WordPress (an excellent blogging tool), to produce GeoRSS, called GeoPress.

   

   Mikel Maron

   19 Aug 07 at 12:22
3. At the end of the day who is this all for? My concern is for the aid worker in the field. When I was out there my day consisted of waking up at 3am, coffee, packing the vaccines, driving 2 hrs to a remote site, vaccinating 6,000 people, driving 2hrs back in the rain, unloading the vehicles, dinner, prepping vaccines for the next day and bed at 12am. I did that for three months and I can tell you that if I had to enter my epi stats at 12:30am and if it took more than 30min then my base and all others hoping to catch the latest data would be out of luck. If I had to choose between posting some stats or getting ready for the following day, guess which takes precedence? And so we lose that day’s data and the system begins to fall apart because if it is the same for me it is the same for most team members. I would encourage the use of one platform, which I feel at this point is GE (Steve-I won’t mention the bandwidth issue ;)) because everyone knows it. The latest poll I did of non-IT field folks indicated that they all knew of and loved GE but the licensing (no longer an issue thanks to GE Pro Grants) and bandwidth issues kept them from using it.

   The question is who is going to post the data? Most orgs do not have roving field IT, let alone GIS folks, and even the big players have one or two for 20-30 countries. Sure we can train people locally and there are in some countries exceptionally competent individuals (Iraq, Pakistan, Indo, Kenya…) but that is not the case everywhere. Any tool developed has to be accessible to the technically illiterate who are operating in the most extreme circumstance imaginable: 120F, dust storms, gun play, etc. Also, don’t forget that while aid orgs work together in the field to achieve a common goal they are also extremely territorial and protective of their data, any data. That is just out of habit. Aid orgs don’t like sharing unless you are talking about generator parts and they are hyper-competitive. If they post their vaccination stats and they are worse than yours are you going to get the donor money? That is a reality. And any info the aid worker collects in the field belongs to the organization (Paul and I have discussed public vs. private data) and not to the aid worker. Odds are if he posts that data without approval, which sometimes needs to come from DC or NY he will get fired. And, I know that on the sites I ran I would not want individuals arbitrarily posting data for fear they would publicly, and inadvertently, post lat-longs to my evac routes, compounds, etc. which could compromise a team and get their members killed. I have seen it happen many times and once you are in the field you realize that the amount of data going out is going to slow to a trickle. You wouldn’t want your team hurt because you were unfamiliar with the software and what it could do so again, the data stops flowing and the system degrades.

   Now I am sure all of you can come up with solutions to these problems and I think that GeoRSS is a brilliant solution to a truckload of problems but there are also many non-technical obstacles that need to be overcome. First, we need to decide on a common platform and until I see something else that has what GE has, GE wins. (I am not pandering here.) Also, the email function built into GE worked beautifully for me when I was building layers for the famine response in Niger in 2005 and Lebanon last year. I can email any post to selected team mates and it is auditable trail. That is one key, you have to be able to track the data flow, who sent it and when. I realize GeoRSS addresses these issues but shamefully I am not fully aware of how. GE already has the collaborative functionality that I need and it has for some time. Once we get past the bandwidth hurdle we will be almost home. And if we agree to use GE as the common platform then we can decide how best to integrate GeoRSS so that timely, relevant and correct data can be posted in a safe and effective manner.

   Lastly, Jeff and I put some Clark Connect boxes in Indo in March and while I am a massive proponent of locally caching data (this is really the answer to most of our problems) I am very wary of trying to get DVD’s into a disaster zone. I love DHL but the reality is that they are not always on time (think customs). Sure, someone can carry it but who? And who decides who gets access to the data. Forget controls because once that DVD leaves the keepers hand bootleg copies will be in every bazaar from Banda to Baghdad. If one team gets the data and another doesn’t then there will be hell to pay. And who is to say the data won’t get passed to some rather unsavory individuals. There are a million things that can and will go wrong with DVD distribution. If it works, and I sure hope it does, that’s great. But, and I agree with Mikel, we are talking about Google’s data. Better to post for all. If we can get imagery for only the countries we need (Sorry Steve), even better. With Jeff’s box we can then cache locally and save the bandwidth. Remember, over BGAN satellite modem 1MB is $4-8 and an oversold VSAT is $1200/month. But if the maps and data are clean people will pay the bandwidth costs.

   Next thing we need to work out is how to post to GE from a Thuraya (think Twitter) and an imagery ‘request line’ for field teams.

   

   Jonathan Thompson

   19 Aug 07 at 12:23
4. Let me give three other examples of field life, so that you all can see a wider view of what life is like in the field and how it relates to this fruit of this thread, if we do happen to come up with the perfect GeoRSS + RSS + map system for plotting security info.

   First, is my experience in Liberia, as the log for an MSF-operated basic health care project in a stable post-conflict context. Our security rules limited our movements to either a handful of pre-approved places inside the city, or pre-planned movements. The rest of the time we were in our compound. We had twice-weekly car trips to the capital city, 6 hours by car away. My day was not the crazy 20 hour day you live on a vaccination project. (”Official” MSF procedure is that the log catches a few winks of sleep in the back of the land cruiser during the heat of the day, while the vaccination continues under a tree. Jon forgot to include that tidbit…) My day started at 7am. I chased technical details (security, food inventory, vehicle maintenance, construction management) and human resources problems until 5pm, with a solid hour and a half of quiet time around lunch. I worked 10-15 hours a week after hours on accounting work (best accomplished in peace and quiet — also counting thousands of US dollars with people around is not allowed by the security rules). Once a week or so we would have a movie night where the guy from Action Contre le Faim next door came over and shared their 80 gigs of DIVX movies with us. This was the maximum extent of inter-organization data sharing! I slept 8 hours a night, except 2 nights a week on average when I was awakened for an hour or so for some problem (generator, transport problem, freight arrival). I spent 4 hours a week helping MSF nurses with their data entry in (brain damaged) Excel worksheets. I had a GSM phone on the global network (in/out to USA and Europe as easy as 00 coutntry-code local-number). I had reliable email
   connectivity via satellite with a bit rate of around 100 kbit/sec. I could not do HTTP nor HTTPS. I submitted my reports and did “offsite backups” by burning a CD and sending it on a car to Monrovia.

   [EDITED AT COMMENTER'S REQUEST]

   As a third data point, my boss in Monrovia Liberia had almost precisely the same lifestyle as the man I described in Bandah (but he didn’t record songs, that I know of!). Bandah and Monrovia are actually quite alike.

   In these situations, the logisticians had time and attention available (perhaps 3 hours a week) for IT-based mapping tools and some data entry, especially when it could generate instant gratification in our local area of operations. We did not have the resources to debug stuff, download patches, or write programs. None of us could reasonably use Google Maps, let alone Google Earth.

   

   Jeff Allen

   19 Aug 07 at 13:39
5. Thanks Jeff and John for pictures of what life is like in the field. Paul as well has written a thought provoking response, in this stream, to my presentation on OpenStreetMap and disaster response.

   My point of view is from someone who’s never actually been out in these situations (though I’m looking to change that) and only has an inkling that there are some systematic problems and potential solutions, or a means to a solution, through new approaches to information management informed by the web. The more I have the privilege to discuss these things with people who have real experience, the better informed this inkling becomes. I still definitely think there’s something here, and it hasn’t been tried yet.

   Some things I’m gleaning. There’s little time to capture and report data. Certain kinds of data, in certain situations, can lead to security exposure. For various reasons organizations are by nature resistant to sharing data. Bandwidth is severely limited. Other means of distribution like DVDs have vulnerability. Open systems require very accurate reporting of sources, and ability to rank and filter those sources. Thinking about these restrictions poses one of the greatest system design problems I’ve ever seen.

   Note that Google Earth is only a piece of the puzzle. It does have provide the means for visualizing and authoring, but there’s no infrastructure for sharing. GeoRSS, through its RSS aggregation roots, gives a model for sharing, though really the data format doesn’t matter, KML works just as well (and efforts are currently underway at the OGC standards body to bring them closer together). The system for sharing, that is informed by these incredible design constraints, doesn’t exist yet. When it does, the system itself shouldn’t care much about the client, as these data formats are widely understood by a host of tools. Michael currently has a project planned at the Holocaust Museum to trial something like this.

   

   Mikel Maron

   19 Aug 07 at 13:41
6. As to the offline usage of GE, GM: This is a problem we have to endure as part of our GIS development work for Sahana. Since the first versions of Sahana depended on GoogleMaps, Internet connectivity was a must. And since the system represented nearly the whole disaster management stack, it is a must for the system to perform in Internet-less environs, in order to be practical and effective. We thus started moving to other alternatives in addition to it, which I’ll present below.

   I’m not too sure whether the discussion is on making GE/GM better, with caching. In addition to that, an approach where the user has a wide variety of options to be used as data sources would be helpful? We currently use OpenLayers as the front-end GIS client within the Sahana web application. The client in turn can access a wide variety of back end layers, including the GoogleMaps, Yahoo, MS Live API, and more importantly, the wide variety of open WMS data sources out there. The Advantage: The superior data sources of Google is still available, but there is also the option of serving local sources off a local Intranet, thus the client is not left in the dark when Internet connectivity disappears. Moreover, like GoogleMaps, OpenLayers handles and displays GeoRSS too. We also plan to use a modified version
   of MagpieRSS to handle GeoRSS.

   I love the effort Google has put into GIS, and this solution is complementary to it, giving users a wider choice. Our next step would be to link up with GeoNames. Kevin’s problem is an interesting one, and would certainly be useful for Situational awareness applications. We currently follow a Wikimaps type emulation atop Googlemaps to achieve situation awareness, thus allowing users to collaboratively manage spatial content, such as the many mashups that popped up during Katrina.

   However, being a techie twice over, the real world and the field-work during humanitarian operations is Greek, at least to me. I’ll love to see what works and what doesn’t. Hope this thread leads to ultimate truth..

   

   Mifan Careem

   19 Aug 07 at 13:43
7. I should say that in many situations raster data is more useful than vector data. For most locations where we work there are simply no maps. This point was made clear in 2005 during the Nias Island earthquake response off the west coast of Sumatra. We arrived at the coordination meeting early the next morning only to find that the only workable map was a Dutch map from the early 1900’s. They ran it through a copier and zoomed in on each quadrant so eventually there was a b&w patchwork of A4 paper one meter square. All those millions of dollars and all we had was a hand drawn map with a small number of villages approximated and their names inked in with exquisite handwriting. It was a beautiful map but for the most part useless.

   My dream machine for that situation would have been a laptop loaded with Google Earth, a digital projector, and high res imagery cached on a DVD (Steve/Jeff) or we could have jacked in a BGAN which would have been easy enough to do. There was plenty of power and with everyone sitting around throwing out the latest info from folks on the ground we could have come up with an extremely well populated map. At the end of the meeting everyone could plug in their flash drive and take the data with them or just wait for the HIC to kick out an email with the updated data (although I’d rather take the data with me).

   Even if I didn’t have the latest high res imagery, just some high res stuff, I could make pretty accurate guesses as to affected areas, possible landing zone locations for folks like AirServ/UNHAS (although you can’t beat an overflight), possible transit routes and with 3D terrain available (Nias is full of mountains) you can estimate travel times. Once we populated that map in the meeting, and overlaid a transparency of the Dutch map or some of the surf maps that were available, posted rapid assessment reports and dropped in some snapshots from the pilots and first teams in, we would have had an extremely useful tool. But without that base imagery to build on, and granted it has to be half way decent, we would not have been much better off than we were. If you can simply see a village in a photo you don’t have to rely on someone telling you where it is or how to spell the name. (One of the greatest location based problems is how to correctly spell the name of a site. This is particularly problematic in the Middle East.) I see it, you see it, there it is next to the river, etc… Even folks who have never seen a satellite image can quickly locate landmarks.

   Another problem is that roads move all the time. In eastern Chad you approach a sand dune and basically guess the route. Sand shifts, roads shift and disappear. Also, the way sand builds-up in wind shadows you will have different densities and while good drivers can read the terrain and navigate accordingly so can’t. That means that you might come off 1/2 mile of dune in a spot 1/4 mile from where you did the day before and, if there are tracks, you just might follow them. This has implications other than inconvenience since some alternate routes may run through unfriendly locations. Often times you will find yourself with a city driver who has no idea about bush driving and possible tribal tensions. This is really a long way of saying if I can open up my laptop and stare at an image, and then out at the terrain, I could possibly find my way to the next site. And if your driver is sick and you have to drive you need all the help you can get.

   Roads move, hills slide, pronunciation is tough, alternate routes are sometimes unavoidable, etc. GPS units are nice but in Ethiopia in 2001 technologies were strictly forbidden and a unit like that, had they picked it up at the airport (although not likely) would have gotten you in a pickle. Comm’s were also not allowed (they didn’t have GSM coverage) and the best method of communications was either yelling from hilltop to hilltop or sending a driver for a two hour drive with a question penciled on a piece of paper and waiting four hours for the response. Point is GPS units were not always welcome (although I am sure that now there are a multitude of folks driving around with Garmin units suctioned to their windshields and I’d like to hear about your experiences if you are one of them) nor is it convenient to carry the thing around with you all the time. Also, don’t forget US gov’t export regs for places like Darfur. Paul and Stefan wrote about the brouhaha some time ago and it seems to be mostly over but it was a pain in the butt for a while and GE was prohibited in Sudan for this very reason (I believe it was self-imposed from Google’s side). The host country might not care at all what you are carrying, including software, but the US gov’t certainly does, especially if you’re on their dime. Precise data collection isn’t always easy.

   Lastly, and I hear Mifan on this one, online systems just don’t cut it for various reasons.

   

   Jonathan Thompson

   19 Aug 07 at 13:44
8. Offline. Essentially this is the kind of modifications I’m thinking about for the OpenStreetMap platform. A self contained installation which can modify a map locally, but also sync with other “nodes” in the field when there is a bit of bandwidth available. OpenStreetMap.org is particularly concerned with copyright infringement, so we can’t trace from Google Earth, but in a disaster situation, this restraint just isn’t justified and data is collected by any means necessary; so this kind of data may not make it back into OSM proper unless “scrubbed”, where it can be helpful in the long term. There are all these maps being created during a crisis, which could be useful in the reconstruction phase and beyond, yet that data falls into a black hole once the emergency operations leave.

   Google Earth has good coverage, but not everywhere. And after a disaster, the landscape can be changed dramatically. This was the big wow of Global Connection’s work processing NOAA flyovers of the Katrina affected area into KML files. Responders should be able to easily take advantage of all data sources, and as Jon said a couple emails ago, easily request new imagery from government and corporate satellites, or request flyovers. Over the past few years, this has happened quite ad-hoc. One of the most recent being the search for Jim Grey, which brought all sorts of resources from every direction — imagine what could be available for a disaster affecting thousands. How can we make the channels to imagery providers more accessible? GeoEye has the GeoEye Foundation, there’s the Global Charter — but there are far more potential resources out there.

   Jon, your emphasis on the initial face to face meeting seems to say that the key time for sharing is before the response takes place. But you also mention the examples of dynamic roads and routes in Chad. And generally the situation is always very dynamic. I guess it must be easiest to share when everyone’s in the same location, of course. The systems I’m thinking about are to support continuous data sharing of both POI and rasters when aid workers are dispersed, which is of course a lot harder, but I reckon quite valuable.

   GPS are getting smaller and embedded in other devices. If they and other technology are banned, sure, there’s no place for systems like this. But hopefully that’s the exception.

   

   Mikel Maron

   19 Aug 07 at 13:45
9. I am hopeful that groups, whoever they might be, will realize how critical it is to push imagery out ASAP and not pause to think about the ramifications. I realize there is a massive amount of technical prepping that has to be done with an image before we see it but even a few good shots are better than nothing at all.

   I think what we’re getting into here is the difference between an emergency and a long term response and the importance that vector and raster data play in these different phases. (I have spent most of my time on emergencies and so I am biased for sure.) Generally, an emergency period is designated as 1-3 months after the event although this can be extended in extreme circumstances (Tsunami). This is an important distinction as it affects funding cycles and availability of resources. What type of mapping that is done prior to an event and subsequent emergency phase can significantly impact our ability to respond. (I was thrilled to read that Google was going to begin mapping Kenya and surrounding countries in earnest.) However, after an event a bit of high res raster data can give us an immediate view of roads that were previously mapped and are now covered by landslides. The Pakistan earthquake is a good example of this as is the West Sumatra earthquake in March. Jeff and I stood at the gov’t response center in Bukkit Tinggi and viewed photos of a massive landslide right outside of town that had blocked and main route in three directions. Gov’t helicopters had done a flyover and the pictures were very telling. We could have stretched them right onto GE, OpenStreetMaps, etc and had a very useful tool to work with. The govt’s response was swift and decisive so such a tool would have been useful but ultimately of limited use.

   Mapping as the emergency unfolds is typically the responsibility of the HIC which provides us with good quality maps and some imagery but typically the usefulness of these tools drops off over time and by the end of the emergency (1-3 month if not less) most responders are intimately familiar with the area’s terrain and as a sub-group possess more accurate data than the mapping centers. This is where post emergency data collection comes into play. While the maps can be fine tuned the really critical material comes as the emergency unfolds consisting of epidemiological data, etc. but I am getting ahead of myself… Once we have maps available we stick them on a wall and use them as reference but ultimately we seem to create a one off on an adjacent whiteboard where we can draw in logistical routes, landing zones, etc.) These begin to look pretty wild over time and that is why the ability to layer on something like GE, or similar, as the event unfolds would provide us all with a record of exactly what data was added and when and we could retain that data for future use. One swipe of the whiteboard and critical data could be lost. It is mind numbing when you think about where we are and where we could be.

   This is the type of data that you are referring to that could be useful in reconstruction, response training scenarios, etc. ReliefWeb is a good repository of data that is readily available where I can go and pull maps from previous events. The more obscure the site the less likely it is that anyone will pull data from it. ReliefWeb has the benefit of being a job posting site for NGO’s so many field workers scour it daily for their next job. This high traffic allows them to put a ton of maps in front of a large group of people. It is a gathering place, watering hole, etc. for our community.

   So, the data that is first placed on a map in an emergency is for collaborative purposes, i.e. “Don’t go to that village because I am already there and have checked out the surrounding areas and here is what I know…” Afterwards, when working groups are put together for the Helath, Logistics, Wat-San sectors is when critical data collection should take place. Which roads are open? Where are you putting boreholes? Which village did you vaccinate for measles and what are your stats? This data should all be layered separately in the working groups and then presented at the main meeting, as it is already done, but it is not done in a coherent manner and more often than not a presentation is someone reading from a list and then struggling to find the location on a wall map. What you now get into are gross differences in reporting standards, how data is collected and, again, data sharing. Ugh. This is one place where we could really help. If we could create a rapid assessment form which is common to all parties, much like MSF’s rapid assessment form, with fields for locations which could then be uploaded to a common platform (GE, OSM, etc) we would be getting somewhere. Google Spreadsheets has captured this idea and I am sorry to keep ringing their bell but to their credit they have gotten closest to the solution. I don’t know which Epi software is in vogue but the CDC’s Epi Info should kick out KML files. I imagine you could use Arc2Earth for the transfer. Epi Info was the standard for many years and there are warehouses full of that data waiting to be mined.

   The data that is collected in the previous emergency can benefit not only the rebuilding but also the next emergency. Meningitis is a good example of this. Vaccinations in northern Ethiopia in 2001 were focused at the 2-30 age group. Anyone over that age was considered of less likely to contract the disease this time around as they had already passed through previous epidemic unscathed. (If it is a different strain of the bug the story changes but meningitis seems to be regionally specific.) The point here is that with a reoccurring bug like meningitis you know that you will see the same population sometime in the future. If you are the same group that vaccinated during the previous epidemic you can pull your stats that you collected (I think EpiCentre and MSF jointly hold the data for our work) and have a fairly good picture of what areas are most likely to be hit again. I may dead wrong but I think the vaccine efficacy period was 8 years (man am I getting old) so if you had another outbreak in the same loc after 5 years you could check your data against your previous vaccination cycle and make probability charts as to where the disease would be more likely to crop up. (The epidemiologists in the group and gonna kill me.) We were literally chasing the bug and relying on reports from regional health posts for our planning. The epi team would investigate new reports while we were still vaccinating thousands in various other locations. When you consider that most people we saw also had leprosy, various forms of TB, HIV, etc. you realize there is an incredible amount of data to track. I think all data is held by the Ministry of Health and therefore fairly accessible (most of the time) but if you don’t have access to previously compiled accurate data then you are really starting from scratch and when people are literally laying dying at your feet dying it pisses you off that there isn’t a better way. The Federation of the Red Cross was vaccinating in other districts but I cannot attest to their data collection. Here is where data collection in an emergency can have a massive impact on the lives you can or cannot save.

   

   Jonathan Thompson

   19 Aug 07 at 13:46
10. CartONG is using the GeorSS feeds. The NGO implemented some weeks ago. We still have some problems to read it…. however it works well with MapInfo for instance but for the consultation on line it is still not finished.. About the link with Geonames the links was done under Google map, but we finally removed it as it was bringing more confusion.

    True! Openlayers seems to be the future…Cartoweb4 will be based on the openlayer technology… Openstreet maps seems to be a good initiative as well. But as mentioned in the exchanges how could we be sure of the reliability of the information. Ranking information is fine…But it will still continue the duplication of work ? Someone/some organisation should be assigned as a manager. The interest to work with the attribute data ,like in the GeorRSS, or WFS is also the possibility to “encapsulate” in a field the source of the information. If we take the Ugandan context, we all know that most of the IOM GPS coordinates were not correct… working with high resolution imagery is the best way to create geographical information. Unfortunately, not affordable for most of the NGO’s…

    

    Yann Rebois

    19 Aug 07 at 13:49
11. I have now had the chance to read this thread properly, and here are some thoughts — just a warning, I am not an aid specialist nor a GIS specialist, just somebody who likes to play with new geospatial technologies…

    It looks to me like the challenges being described here can be subcategorized in several different ways along different axes:

    Making maps vs using maps: First, there is the need for accurate and up-to-date maps ASAP in the field, based on in-the-field corrections and updates to existing maps and recently taken satellite imagery. Second, there is collecting data that has a geospatial component to it (vaccinations when and where, new houses built when and where) with a view to vetting it, saving it for data mining, sharing it (though not too much) and making it accessible to queries from the field. The latter challenge depends on first challenge having been met.

    Quality of internet access: It seems that all too often there is spotty or no HTTP access, thought there maybe email access, or expensive GPRS data access via a mobile phone. Sending and receiving of data could be done via several different protocols, depending on what is available: Perhaps the simplest would be via an automated email parser that updates databases based on the contents of a structured email message (perhaps with spreadsheet or KML attachments). A more complicated portable system might hoard and share snippets of new data locally via wifi or thumbnail drives, and then send along info whenever a broadband connection is available, and then also download scrubbed, corrected versions of previously uploaded raw data. (I’m thinking this is what Mikel has in mind). In this kind of scenario, each created information snippet would require a unique ID for tracking, and to avoid duplication at the end destination, even if it is eventually sent by several people. Hmm. This sounds like a job for Atom/Rest, with snippets also sharable as simple XML files with attachments on thumbnail drives,

    One thing that struck me from the description of the mapping in Aceh was how it would have benefited enormously from one full-time mapping specialist, somebody who could act as data logger, scrubber, assimilator and ultimately republisher of mapping data, constantly providing new maps in the whatever format people need it, most likely KML but otherwise also making paper printouts or even just jpegs for storing on mobile phones.

    I think that in the coming two years mobile devices will finally be “good enough” for sophisticated use in the field. My Nokia N95 isn’t quite there yet, but it can already trace routes over high resolution Google Maps with the built-in GPS as I travelled over unmarked routes in Egypt. Downloading the tiles while roaming is expensive (and currently Google doesn’t have an API for mobile phones, so it’s not really legal) but there is also the possibility of caching these tiles. Another aspect of these newer phones is their on-board memory. the 2GB on my N95 is more than sufficient to store a big collection of KML and imagery — and 4-16GB will be the norm in 2 years. My phone also does wifi, Bluetooth and USB, so there are opportunities here for building a peer-to-peer mapping and data collection and sharing appication (on Symbian S60? Windows Mobile?) that could also update aid workers in a decentralized fashion. Ultimately, I don’t think these phones will be able to do GPS properly in the field (it sucks to try to use it as a phone if the batteries are dead because you left the GPS on — it could even be dangerous) but I think the solution is to use an external GPS unit and connected it either via a wire or via bluetooth, a solution that is already quite mature. The N95 also takes great photos with a 5megapixel camera, and apps like Shozu let you post them or send them via email directly — again, the main impediment is a data network’s roaming charges.

    Somehow, I feel like some of the challenges mentioned in this thread must have been solved somewhere, sometime in a big business setting. Don’t UPS and Federal Express, for example, have very sophisticated business intelligence for tracing packages and routing around obstacles? Couldn’t their deliverers’ mobile devices with bar scanners be repurposed for monitoring medicine deliveries and providing news of needs quickly?

    In the end, I suspect it may still be more efficient to send dedicated data people into the field who can tinker to adapt to local needs and act as a local hub for data gathering and dissemination — if the military does it that way, there is probably a good reason. (Maybe this last paragraph is exceedingly obvious — in which case my apologies!)

    

    Stefan Geens

    24 Aug 07 at 9:02
12. Stefan, your synthesis is on target, I think.

    But the route from your e-mail message to real world success stories is long and tough. Some of the things you discuss are possible now, but are on the bleeding edge of technology. Downloading new drivers to solve a bluetooth compatibility problem between my phone and my GPS when I was out in the field was not an option. Remember, I have 100
    kbit/sec of e-mail only, and less than 3 hours a week to devote to mapping-type work. That’s not enough time or bandwidth to futz around with stuff like this. It needs to “just work”.

    You proposed a solution to this is: to have dedicated technology folks in the field that can make this stuff “just work” for the people at the edge who can’t or don’t want to do it for themselves. This is related to the charter of Jon’s organization, Humanlink (http://www.hlink.org). Jon and I made an exploratory trip to Indonesia this year to see how it works. We were successful at finding problems to solve, and at solving them. But they were not the fun problems you are thinking of… they were of the “implement DHCP in
    this office”, “clean viruses off of these computers”, and “implement HTTP caching to reduce load on this satellite link” variety. Though I would have loved to be doing cool stuff with GPS, Google Maps, and cell phones, I was implementing technology form 1995 on small-office Ethernet networks. It’s not sexy, but it is unfortunately real life. There’s no such thing as silver bullets, nor quantum leaps in IT literacy. You have to drag people forward and you are not allowed to skip stages of technological development, no matter how exciting your new N95 phone is… someone’s still got to unclog the satellite link
    and setup a wifi AP before you can use your phone!

    (Data point: About the same time you were probably buying your N95 in Sweden, Jon and I were in Indo. We saw advertisements for the N95 on billboards in Bandah, Aceh. I didn’t look into availability and price, but Nokia is the dominant brand in Indo, and I’m certain that it was no fluke the N95 was on the billboard. The Nokia company store in Medan was nicer than Apple stores in the United States!)

    Your vision of tech people in the field is great, such a good idea that Jon is already working on it! I will let Jon chime in and tell you how it’s going. (Jon has also networked with other people with the same vision, and knows their successes/problems.)

    I am currently working (at very low, hobby-level intensity) on a project that could make it easier and cheaper to roll out server-based apps to the field. (One of the discoveries Jon and I made is that field sites should be using servers at the edge of their networks, but mostly are not yet because of lack up knowledge.) I’m exploring what’s capable on a Linksys router running OpenWRT. I’m working with this kind of cheap platform because it has attributes that make it usable in the field (low power, no fan, no spinning disk, cheap). This e-mail message, in fact, was posted from behind an HTTP proxy that (as soon
    as I finish debugging my broken-ass C code) can substitute locally stored content for remote content, thereby dramatically reducing the bandwidth and latency for assets with known long expiration times, like web app UI images, Google Maps tiles, etc. (This is different than standards-compliant HTTP caching: the content I’m serving is put on the device before it ever gets out to the field setting, and is served to the local users without waiting for a round trip to the remote server to check the expiration policy. The content is stored on the device in the form of an “offline content” module. Such modules
    could be created by the publishers themselves, if they wanted to ease access to their data at the edge of the network.)

    

    Jeff Allen

    24 Aug 07 at 9:03
13. Jeff, I agree with your analysis. One of our challenges is to determine the balance between what is technically possible, and what is practical and valuable. Although all sorts of solutions are possible, it is important to start with robust, basic solutions, which give value to people in the field.

    I think it important to stay connected with the needs of the people we are trying to help - rather than trying to implement the latest “sexy” solution.

    I think a lot of work goes into developing fancy technical systems, without enough consideration for the situation in the field. I have an Indonesian friend working for the UN Aceh. He’s got a PDA-Phone which they gave him to collect data in the field, however he finds that it is too slow to enter interview information, so he still writes it down on
    paper, and then enters it in his phone later.

    I know of some projects involving software which has been developed in a western context, but is inappropriate for use in developing countries. As a result the projects have failed, and this makes people more cautious of technology in future.

    I definitely agree that a better forum (email list etc) is required for sharing idea in this field. Does anyone have any suggestions?

    In regards to Kevin’s initial problem, I would go with Mikel’s suggestion of WordPress (www.wordpress.org), with some of the GIS plugins. I’ve currently using a Geo-Mashup Plugin (http://www.cyberhobo.net/downloads/geo-mashup-plugin/) which allows me to
    add a Google map, plotting the locations of my posts, to my blog (http://www.fromthehorizon.com/blog-map/). It was relatively easy to set up, and very easy to use (location details can be added to posts with GPS co-ordinates, Geoname or selected from Google maps). I’m pretty sure that you can import RSS feeds into wordpress too. http://www.chrisandabigail.com/?page_id=71 is another Google maps plugin. It might be worthwhile converting the Google map to an image, which can be then sent as an email attachment, or more easily downloaded. My low-tech solution to this would be the “Print-Screen” key.

    

    Michael Howden

    24 Aug 07 at 9:03
14. As for WordPress plugins, Google Maps just became embeddable on any website, no API needed, and Daniel Denk over at Remote Sensing Tools has just turned that newfound functionality into a very easy to use Wordpress plugin.

    

    Stefan Geens

    24 Aug 07 at 9:05
15. Odds and Ends…

    A couple of weeks ago I was emailed Paul Currion and happened to mention that I wanted to plot RSS news feeds on an easily accessible map. Paul passed my question onwards and it mushroomed into an interesting conversation between some very clever peo…..

    

    Patronus Analytical Blog

    1 Sep 07 at 9:48
16. Hi all!
    I normally do not read or write to blogs, as I feel my time is never enough… But through Mikel’site I cam to this thread, and reading Jonathan’s comments I could not resist posting some comments.
    First, on the bandwidth issue in the field, we are a bit too comfortable “accepting” a BGAN @4$/min or a VSAT some company offers for 1200$/month… There are many other solutions, offers, many using local so-called “spot beams” for the satellite link, and that makes them much cheaper, but little effort is made to find those options… We should all try harder…
    Second, on the off-line access to GE content, when I visited GE in Mountain View last year, they mentioned the idea of having a tool to “package” a DVD with the licenese and data for a specific region, and take it to low-connected or non-connected sites for use… They were asking if the UN would be interested in such, and I clearly said YES… We will remind them again that such a solution would help us all, and will address also Jonathan’s issues. No need to worry about getting the DVD in the “wrong hands”, as long as all data is “cached” online content freely available anyway… At least we can avoid investing our time in efforts that are already addressed by GE for example…
    Thirdly, for imagery coverage and “imagery lines”, we as UN have an informal agreement with GE about putting together priority area lists, after internal consultations among some 15 UN agencies through UNGIWG (the UN Inter-agency Working Group on Geographic Information), and GE will make every effort to prioritise loading those areas’ DG imagery into the GE database, up to a certain percentage of their monthly acquisitions budgets… We would be happy to team up with other field colleagues and make this a consultative process including external partners to the UN, especially in emergency situations where quick improved coverage is needed, if it would help… So such “imagery lines” do exist and can be improved, if my understanding of Jonathan’s concept is right…
    I hope these comments help, and please feel free to contact me for more details, if needed. Apologies for ny misspellings due to the quick typing!

    

    Lorant Czaran

    23 Sep 07 at 20:32
17. Lorant-
    Many thanks for your comments and thanks to Paul for alerting us to your update.
    Please clarify which spot beam options you are referring to. I find that even if the service price is competitive the equipment is often what gets you.
    I do hope that more relevant imagery is pushed. I still have reservations regarding DVD distribution. Perhaps the HIC can handle replication and distribution in the field?
    My only wish is for ‘clickable’ countries in GE so that only relevant country imagery is pulled down. If that were the case no DVD’s would be necessary.
    I would very much like to see ReliefWeb publish all their maps in KML for easy loading into GE. Any chance of this happening?
    I would be very interested in discussing this further. If not here please send your email to humanlink@gmail.com.
    Cheers!

    

    Jonathan Thompson

    24 Sep 07 at 6:09
18. Let me ask a stupid question. I am not in the humanitarian business nor in the IT business either. However I have an interest in mapping for extreme cases.

    I have some experience with stratospheric flight and with their ability to provide near satellite resolution:
    http://hasp-geocam.blogspot.com/2006/10/comparing-satellite-imagery-and-geocam.html

    but I can see where it is not practical to fly a balloon in a disaster or a war zone. While UAV might be interesting, I believe it falls under all kinds of either US export controls or the host country’s regulation and let’s not even talk about customs.

    I wonder, I have done some test from commercial jets and Cessnas and one can really assemble some type of map from flyovers. Do you think that this would be a good idea, I have written about this here:

    http://nuit-blanche.blogspot.com/2007/09/imaging-from-sky-when-you-become-map.html

    for instance if you fly over an area with no clouds, you can get results such as this one.

    http://bp3.blogger.com/_0ZCyAOBrUtA/Ru-PgiyMQWI/AAAAAAAAAo8/RJ2Ujl5Il_8/s1600-h/10khigh1Pano+-+IMG_3848+-+1925×521+-+SLIN+-+Groupe+d%27image.jpg

    And as I have mentioned before no need for experts, just drag and drop. I all boils down to a question of memory but we are now getting 8 GB SD card so a lot of data imagery can be gotten. The sharing of the data can be done with memory card or over the web using another free software.

    No need for GE either.

    Igor.

    

    Igor Carron

    26 Sep 07 at 9:33
19. Igor-
    Sorry for the delayed response! I think you nailed the solution dead on. Why reinvent the wheel?
    More to come on this.
    Cheers,
    Jon

    

    Jon Thompson

    10 Oct 07 at 6:06
20. Jon,

    It is not really re-inveting the wheel. The automatic stitching algorithm did not see the light of they day until 2004. It has only been commercialized for the past three years and never used for that type of application (producing large maps).

    One more thing that provides some additional data points:

    http://nuit-blanche.blogspot.com/2007/10/producing-maps-using-commercial.html

    Igor.

    

    Igor Carron

    18 Oct 07 at 16:13
21. [...] brings up the DVD issue.  Rather than reiterate past arguments I’ll post an excerpt from the discussion we had over at Paul Currion’s excellent humanitarian.info almost a year [...]

    

    Google Earth and the case for ‘clickable countries’ (cont.) « Aid Worker Daily

    18 Jul 08 at 22:20

Leave a Reply

Name (required)

Mail (will not be published) (required)

Website