Yesterday was one of the coolest and most satisfying in a long time. We finally got to show an international audience that SDI-East Africa is at least taking baby steps and could in the another year or so start walking confidently and even be running, skipping and jumping.
The venue was the 8th session of the UN Geographic Information Working Group (UNGIWG). Long-time readers might recall was that it was at the UNGIWG meeting last year that the first seeds of SDI-EA were planted, then heavily fertilized at the UNGIWG Global Partners' Meeting earlier this year. So it was somewhat satisfying to return to that forum and show that their inspiration had wrought.
The previous post post to this blog noted that, since the East African consultation back in October, there'd been a flurry of inspired activity to actually get data-sharing services on line. Yesterday we were able to show how flood-related data, originating from four different UN agencies (UNHCR, OCHA, FAO/SWALIM, UNEP and GEMS/Water) and hosted on three different servers in Nairobi and one in Canada, could be at least visually integrated to provide humanitarian relief managers with both synoptic and detailed views of potential impacts on refugees and displaced persons in the region. Across a variety of open-source and commercial services, all agreeing to 'speak' an OGC-standard interoperability dialect called Web Feature Services.
These views were previously separately available but never before brought together on demand. We were also able to showcase the crucial role to be played by facilities such as the inter-agency Data Exchange Platform for the Horn of Africa (DEPHA) as a broker publishing data on behalf of agencies that cannot afford or lack mandate to build the capacity to publish data on-line themselves. The KML needed for spinning the showcase up in Google Earth is <here>. Give me a month or so to get back from leave and I'll have equivalent packages for NASA WorldWind, MS Virtual Earth, uDIG and QGIS, all working off the same services
The amazing part is that it worked. Not just the technology, but the message - UN agencies field and regional offices can actually afford the luxury of starting to think about this sort of inter-operation. The technology hurdles are not the insurmountable barrier so often assumed.
Yes, the scenario shown was limited and somewhat contrived. Yes, there were many, many components of a true SDI missing, like the abilities to discover and integrate additional mdata sources, or to discover and display stuff using the correct UN-standard symbols, or even to know the most basic background information about where the data originate or how they can realistically be used. On the other hand, others here in the UNGIWG meeting do Get It and are keen to start plugging gaps in the next year - FAO Geonetwork will work with us to plug the discoverability gaps; OCHA will work with FAO to get symbologies hosted, discoverable and accessible; WFP with the UN Joint Logistics Centre and the ITHACA project will starte getting their transportation data model to integrate automatically to help drive the symbology and portrayal needs. All good, One-UN sort of stuff! I believe we have a viable kernel around which the emerging UN spatial data infrastructure will gain and document its own experiences and growing pains and lessons learned.
Now I just have to convince my bosses to let me keep up my involvement in all this as we move into next year's shiny new work programme!
I'm off on holiday for three weeks. I may or may not be inspired to follow up this post soon - I should: there were some interesting chats with the ESRI rep that bear telling.... If I don't, and happy end-of-year/ mid-winter/ mid-summer/ whatever season to you all
Saturday, 1 December 2007
Friday, 16 November 2007
Sunshine and Happiness
A few months back I realized that, after six months of collective SDI-A effort, there was not actually any more data flowing in East Africa than before when we started the exercise. I got all despondent and sort of lost interest in maintaining this blog. Silly me. Events during the past three weeks have brought the sunshine back into the world of SDI-EA.
The first was the meeting at the end of October that brought together over 40 of the SDI-EA players in East Africa under the theme of Better Data Sooner to consider the question of how best a United Nations SDI would have to be run to be most useful to countries, organizations and societies in the region. Yes, there were all the recommendations about how the UN ought to help SDI proponents with getting policies and standards in place, with finding capacity building opportunities, with getting data flowing out of the UN system while providing opportunities for governments, NGOs and sectoral programmes to publish their data into the UN system. There's more about the SDI-Live effort at http://dewa03.unep.org/live-sdi/ and the report should be out Real Soon Now. I'll describe the motivation for the meeting in a later post but suffice to say it s recommendations seem needed as input to the upcoming UN Geographic Information Working Group UNGIWG meeting in Bangkok when we consider UNSDI implementation over the next year.
What was the real surprise was that, having recognized the crucial necessity of communicating clearly with senior policy types, the participants hit on the notion of building SDI showcases around realistic and solid scenarios that managers could associate with. What was even more surprising was they actually went off and started doing it. Within the space of 10 days we went from having only one real internet-accessible source of data on the network in East Africa (that being UNEP) to having nearly half a dozen - FAO/SWALIM, UNHCR, OCHA, UN-Habitat - and can start telling meaningful stories: a lot of the current data being served concerns the floods across Africa during 2007, their potential impacts on refugees and displaced persons. All of this can be spun up in Google Earth, WorldWind, desktop GIS and the likes. Have a look at this bit of KML ( http://dewa03.unep.org/sdi-ea/system/files/SDI-showcase.kmz ) or at least the screen caps here and here to get an idea where this might go.
It's actually becoming necessary to think about getting a services registry going for this part of world!
Now, how to maintain this momentum? How to use this profile to get more services running - RCMRD, are you reading this?
The first was the meeting at the end of October that brought together over 40 of the SDI-EA players in East Africa under the theme of Better Data Sooner to consider the question of how best a United Nations SDI would have to be run to be most useful to countries, organizations and societies in the region. Yes, there were all the recommendations about how the UN ought to help SDI proponents with getting policies and standards in place, with finding capacity building opportunities, with getting data flowing out of the UN system while providing opportunities for governments, NGOs and sectoral programmes to publish their data into the UN system. There's more about the SDI-Live effort at http://dewa03.unep.org/live-sdi/ and the report should be out Real Soon Now. I'll describe the motivation for the meeting in a later post but suffice to say it s recommendations seem needed as input to the upcoming UN Geographic Information Working Group UNGIWG meeting in Bangkok when we consider UNSDI implementation over the next year.
What was the real surprise was that, having recognized the crucial necessity of communicating clearly with senior policy types, the participants hit on the notion of building SDI showcases around realistic and solid scenarios that managers could associate with. What was even more surprising was they actually went off and started doing it. Within the space of 10 days we went from having only one real internet-accessible source of data on the network in East Africa (that being UNEP) to having nearly half a dozen - FAO/SWALIM, UNHCR, OCHA, UN-Habitat - and can start telling meaningful stories: a lot of the current data being served concerns the floods across Africa during 2007, their potential impacts on refugees and displaced persons. All of this can be spun up in Google Earth, WorldWind, desktop GIS and the likes. Have a look at this bit of KML ( http://dewa03.unep.org/sdi-ea/system/files/SDI-showcase.kmz ) or at least the screen caps here and here to get an idea where this might go.
It's actually becoming necessary to think about getting a services registry going for this part of world!
Now, how to maintain this momentum? How to use this profile to get more services running - RCMRD, are you reading this?
Tuesday, 11 September 2007
Moving Refugees
This is unprecedented! Two contributions from one person in one day!!
Firstly: A bunch of us got an e-mail today from John Marinos at the UNHCR Somalia. I begged and pleaded and he finally relented to me posting his message to the SDI-EA blog. Why? Because to it's got all (well, many) the right elements we seek in SDI-EA: innovative communication, collaboration within a community etc. etc. Of course, in my version of A Perfect World you'd be posting these data to the likes of SWALIM and/or DEPHA and, through the magic of interoperablnes finding it being served in ready-to-use guises through Google Maps or Google Earth, GIS clients and flat browsers, all at no extra cost. I guess we got a ways to go yet but I think it's a goal worth bearing in mind. Anyway, John's KML is posted at http://dewa03.unep.org/downloads/UNHCR_IDPs_Sep06_to_Aug07.kmz
"Dear colleagues,
"This email attempts to kill 3 birds with one stone... as the saying goes.
"1) I am distributing to the usual suspects, the latest version of the PMT [That's Population Movement Tracking for those of us outside humanitarian space. Mick] database. This version is the same as the one circulated last month but now includes the movements from August 2007. It is for your use, and if you'd like to post it for dissemination on GeoNetworks or DEPHA (as a WFS) then go for it. The attached zip file contains the data as a shape file, along with metadata and a document to explain the fields in the table.
"2) Also attached is the latest PMT map. Feel free to put this on ReliefWeb, GeoNetworks, OCHA-Somalia, or wherever.
"3) Lastly, I've been trying to find a way for people to see and appreciate the scale of IDP [Internally Displaced Persons a.k.a refugges that haven't crossed an international border. Mick] movements in Somalia. With the help of Craig Von Hagen, who forwarded a useful email to me we've put together a KMZ file that allows you to use Google Earth (v.4) to view the locations of IDPs and the reasons for movement - per month. It covers the period Sep 2006 until August 2007.
"By double clicking on the KMZ file below it should open Google Earth (assuming that you have it installed on your machine). It includes the districts of Somalia along with 12 maps (actually image overlays) each showing locations where IDPs have moved for that particular month (according to PMT reports received by our partners). Each location is color coded* by the reason for displacement** If you have Google Earth version 4 installed, it will recognize the time tags and a sliding bar will appear at the top of your screen - to the left of your navigation control. This will allow you to "scroll" through time and see the different monthly maps. Notice how Nov 07 had a lot of flood displacement? Notice the displacement because of insecurity from Feb till now, with a lull in May? The goal is to provide you with an easy to use (and very cool) tool to view the data we've collected on IDP movements this last year. The secondary goal is to stop me from making PP presentations with this same information.
"Some problems:
"* I don't know how to put a legend in Google Earth. Therefore there is a PDF attached showing what the different colored dots mean.
"** There are some locations that have 2 different reasons for movement in the same month. (i.e. Some people moved to Baydhaba because of drought, some people because of insecurity). In these cases only one reason for movement is displayed. I've tried unsuccessfully to fix the situation. I'll continue to try. Remember this is only a test!
"If you are one of the techies who would like more information on the methodology of the PMT project or on other Protection Cluster initiatives, don't hesitate to ask. If you're a non-techy and want to know more about the data we have available and how best to use it, don't hesitate to ask.
"I look forward to your comments on the KMZ file.
"Best Regards,"
Secondly, later also from John:
"In other exciting news. I've used my fancy new upgraded MapInfo to log onto DEPHA's Geoserver.
http://dewa03.unep.org/geoserver/wfs?request=GetCapabilities&service=WFS&version=1.0.0
I've even downloaded the (old) Admin boundaries for Somalia. Look! Its there now. I'm using data on my PC thats sitting on your server. How cool is that!?!
"Now that I'm able to party with you guys, may I kindly request that you post some data sets that may of interest to the community.
"1) IDP settlements in Somalia
"2) IDP locations
"- these are different. #1 is the actual IDP settlement within various towns in Somalia. #2 are the towns/villages that have received IDPs over the last few months.
"Now that Somalia is covered I'm sure there are regional datasets that our Regional Hub can send over that people are sure to enjoy.
"Forgive me if I"m jumping the gun a little. You guys at DEPHA are not our personal data posters.. Let us know if you're interested in this data, then in what format it should be in to be the easiest for you to work with. Also bear in mind that this data gets updated frequently.
"Viva la EA-SDI!!!!
"JOHN"
Not a bad day's work, I think.
Firstly: A bunch of us got an e-mail today from John Marinos at the UNHCR Somalia. I begged and pleaded and he finally relented to me posting his message to the SDI-EA blog. Why? Because to it's got all (well, many) the right elements we seek in SDI-EA: innovative communication, collaboration within a community etc. etc. Of course, in my version of A Perfect World you'd be posting these data to the likes of SWALIM and/or DEPHA and, through the magic of interoperablnes finding it being served in ready-to-use guises through Google Maps or Google Earth, GIS clients and flat browsers, all at no extra cost. I guess we got a ways to go yet but I think it's a goal worth bearing in mind. Anyway, John's KML is posted at http://dewa03.unep.org/downloads/UNHCR_IDPs_Sep06_to_Aug07.kmz
"Dear colleagues,
"This email attempts to kill 3 birds with one stone... as the saying goes.
"1) I am distributing to the usual suspects, the latest version of the PMT [That's Population Movement Tracking for those of us outside humanitarian space. Mick] database. This version is the same as the one circulated last month but now includes the movements from August 2007. It is for your use, and if you'd like to post it for dissemination on GeoNetworks or DEPHA (as a WFS) then go for it. The attached zip file contains the data as a shape file, along with metadata and a document to explain the fields in the table.
"2) Also attached is the latest PMT map. Feel free to put this on ReliefWeb, GeoNetworks, OCHA-Somalia, or wherever.
"3) Lastly, I've been trying to find a way for people to see and appreciate the scale of IDP [Internally Displaced Persons a.k.a refugges that haven't crossed an international border. Mick] movements in Somalia. With the help of Craig Von Hagen, who forwarded a useful email to me we've put together a KMZ file that allows you to use Google Earth (v.4) to view the locations of IDPs and the reasons for movement - per month. It covers the period Sep 2006 until August 2007.
"By double clicking on the KMZ file below it should open Google Earth (assuming that you have it installed on your machine). It includes the districts of Somalia along with 12 maps (actually image overlays) each showing locations where IDPs have moved for that particular month (according to PMT reports received by our partners). Each location is color coded* by the reason for displacement** If you have Google Earth version 4 installed, it will recognize the time tags and a sliding bar will appear at the top of your screen - to the left of your navigation control. This will allow you to "scroll" through time and see the different monthly maps. Notice how Nov 07 had a lot of flood displacement? Notice the displacement because of insecurity from Feb till now, with a lull in May? The goal is to provide you with an easy to use (and very cool) tool to view the data we've collected on IDP movements this last year. The secondary goal is to stop me from making PP presentations with this same information.
"Some problems:
"* I don't know how to put a legend in Google Earth. Therefore there is a PDF attached showing what the different colored dots mean.
"** There are some locations that have 2 different reasons for movement in the same month. (i.e. Some people moved to Baydhaba because of drought, some people because of insecurity). In these cases only one reason for movement is displayed. I've tried unsuccessfully to fix the situation. I'll continue to try. Remember this is only a test!
"If you are one of the techies who would like more information on the methodology of the PMT project or on other Protection Cluster initiatives, don't hesitate to ask. If you're a non-techy and want to know more about the data we have available and how best to use it, don't hesitate to ask.
"I look forward to your comments on the KMZ file.
"Best Regards,"
Secondly, later also from John:
"In other exciting news. I've used my fancy new upgraded MapInfo to log onto DEPHA's Geoserver.
http://dewa03.unep.org/geoserver/wfs?request=GetCapabilities&service=WFS&version=1.0.0
I've even downloaded the (old) Admin boundaries for Somalia. Look! Its there now. I'm using data on my PC thats sitting on your server. How cool is that!?!
"Now that I'm able to party with you guys, may I kindly request that you post some data sets that may of interest to the community.
"1) IDP settlements in Somalia
"2) IDP locations
"- these are different. #1 is the actual IDP settlement within various towns in Somalia. #2 are the towns/villages that have received IDPs over the last few months.
"Now that Somalia is covered I'm sure there are regional datasets that our Regional Hub can send over that people are sure to enjoy.
"Forgive me if I"m jumping the gun a little. You guys at DEPHA are not our personal data posters.. Let us know if you're interested in this data, then in what format it should be in to be the easiest for you to work with. Also bear in mind that this data gets updated frequently.
"Viva la EA-SDI!!!!
"JOHN"
Not a bad day's work, I think.
Saturday, 8 September 2007
Back to the Conservation Community, and our First Abject Failure
Hmmm. It would seem that my subconsience has been censoring me, probably to prevent embarrassment to both of us. I did in fact write this up a month ago and somehow have just not posted it...
The SCGIS conference back in July brought two important potential follow-ups for SDI-EA, one being with Kenya Wildlife Service to get them to start spinning their protected areas data into the World Protected Areas database (a long-standing goal, yet to be realized), and the second with the Africa Conservation Centre. ACC support SCGIS and are motivated players in the SDI game, and I see them as a potential lynch-pin on regional SDI service targeting the conservation and resource management communities.
So, John and I are off to Lan'gata to meet up with Lucy Waruingi and other friends. And, lo!, they have a little linux (Fedora) server running as their relay for e-mail via and always-on satellite link and with a static IP address. Looks like a piece of cake to get the geoserver in place and set up a Geonetwork node for them, avoiding some of the pitfalls we struck with ICRC. Wrong.
You think you've covered all that bases, that you've planned for all the hardware wrinkles and variants, which you have a good flexible toolkit able to provide the work-arounds you need. More wrong.
We have all our installation software on USB devices. Obviously. So convenient. Does Lucy's server see the USB ports? Of course not. Shoot. Do we know ho to get Fedora to mount the USB ports? Of course not, we only ever cut our teeth using Mandriva and the commands it provides are not the real, low-level unix ones and so we get caught out. Who knows: maybe the server, being intended solely as a mail relay, has some minimal kernel not built with such luxuries as hotplug support. The point is that John and I should better anticipate these realities. Once again, going back to first principles is shown to be the wise move and, once again, we get caught when we cut corners.
Yes, of course, plugging this knowledge gap should take 10 minutes on the net with Google but it's late Friday afternoon and everyone wants to go home and we look like donkeys anyway. Not the best of time for thinking straight. I still think it will be a great face-saver if the USB ports turn out to be kaput anyway, but I have no faith in this.
Oh well, no problem, I've got all the software on DVD as well. But: why won't Lucy's server read the DVDs? Shoot, again! It's not a DVD reader, is it? It's a CD-ROM reader, and of course the UNEP Brains Trust does not have the software on CD. Total frustration. Go home and drink beer.
So, of course, no we're well equipped with many copies of software on CD-ROM and low-level knowledge of how to talk nicely to USB ports on all sorts of linux systems, and look forward to mounting a triumphant return expedition to ACC to rescue our sullied reputations. But I can't help but wonder "What's going to catch us next time?"
The SCGIS conference back in July brought two important potential follow-ups for SDI-EA, one being with Kenya Wildlife Service to get them to start spinning their protected areas data into the World Protected Areas database (a long-standing goal, yet to be realized), and the second with the Africa Conservation Centre. ACC support SCGIS and are motivated players in the SDI game, and I see them as a potential lynch-pin on regional SDI service targeting the conservation and resource management communities.
So, John and I are off to Lan'gata to meet up with Lucy Waruingi and other friends. And, lo!, they have a little linux (Fedora) server running as their relay for e-mail via and always-on satellite link and with a static IP address. Looks like a piece of cake to get the geoserver in place and set up a Geonetwork node for them, avoiding some of the pitfalls we struck with ICRC. Wrong.
You think you've covered all that bases, that you've planned for all the hardware wrinkles and variants, which you have a good flexible toolkit able to provide the work-arounds you need. More wrong.
We have all our installation software on USB devices. Obviously. So convenient. Does Lucy's server see the USB ports? Of course not. Shoot. Do we know ho to get Fedora to mount the USB ports? Of course not, we only ever cut our teeth using Mandriva and the commands it provides are not the real, low-level unix ones and so we get caught out. Who knows: maybe the server, being intended solely as a mail relay, has some minimal kernel not built with such luxuries as hotplug support. The point is that John and I should better anticipate these realities. Once again, going back to first principles is shown to be the wise move and, once again, we get caught when we cut corners.
Yes, of course, plugging this knowledge gap should take 10 minutes on the net with Google but it's late Friday afternoon and everyone wants to go home and we look like donkeys anyway. Not the best of time for thinking straight. I still think it will be a great face-saver if the USB ports turn out to be kaput anyway, but I have no faith in this.
Oh well, no problem, I've got all the software on DVD as well. But: why won't Lucy's server read the DVDs? Shoot, again! It's not a DVD reader, is it? It's a CD-ROM reader, and of course the UNEP Brains Trust does not have the software on CD. Total frustration. Go home and drink beer.
So, of course, no we're well equipped with many copies of software on CD-ROM and low-level knowledge of how to talk nicely to USB ports on all sorts of linux systems, and look forward to mounting a triumphant return expedition to ACC to rescue our sullied reputations. But I can't help but wonder "What's going to catch us next time?"
Sunday, 26 August 2007
A Matter of Reliability
What do you learn in a community-building exercise when the community building almost fails to happen?
One obvious answer is "Ahh, forget it. We are none of us perfect. Try again and it'll be better". Another is "Well, you guys have failed sometimes; cut some slack to the others". Both are fair answers. But the question itself, and the quality of the answers, underpin a more crucial aspect of the governance of 'bottom up' SDI's, namely how do we fare when, later on, there are services over which we've built our own value-adding services and, tomorrow, the service custodian goes out of business, so to speak: a change of policy, a shift in budgets, loss of key personnel. Any number of reasons might pertain, but suddenly our customers are no longer happily receiving their service.
The point is that when you expose open-standards services to the web then I can come along and build on your service, adding a new value or servicing a new audiences that you hadn't planned for. Sure, you can argue that I'd be at least slightly daft to build a critical need on your service without some sort of agreement, let alone recognition. Okay, but, when I try to make a phone call to the other side of the world, my success or failure depends on a whole chain of agreement between telco operators, any one of which can fail just when I need the service. To what degree can I blame my local telco? Not much, if the failure is three networks away in Outer Mongolia. Problem is that it doesn't matter to me where the failure is - my call hasn't gone through. I'm an unhappy frustrated customer.
So, Tuesday should have been a neat day - meeting with the secretariat of the Kenyan national SDI, with two purposes were in mind, Firstly, helping them set up for evaluation some open-standards tools for establishing a national metadata archive, and the ability to serve geo-spatial data directly to remote clients (Geonetwork and geoserver, respectively). Secondly - and more importantly for me - engaging KNSDI's help to organise a meeting in September where we hope to get together all the national SDI players in East Africa along with their UN counterparts. The purpose? Try to start mapping the institutional interfaces that will be needed between the national and regional SDIs and the emerging UN spatial data infrastructure counterpart.
The UN is meant to serve member states, and the UN relies upon member states to provide data and services needed to inform and address trans-national and global issues. If a UNSDI's purpose is (amongst other things) to promote interoperability, shall this be on the basis of 'best effort' by the member states? Is the UN obliged to help members meet minimum levels of reliability and accountability? If so, what levels, and who is to measure and ensure them? If not, what is tolerably good enough, and what happens when gaps in data availability or reliability lead to flawed assessments or decisions? These and many more questions require attention, probably over and over as methods and approaches are tried.
So what happened? The Nairobi traffic Gods frowned, and three out of the four KNSDI participants got stuck in a jam. Could happen anywhere, couldn't it? Could as easily have been a delayed flight, a flood, or sick child to deal with. You bet, all very normal and we can schedule around it and (I hope) we can get our regional meeting organized notwithstanding.
But it did seem to me a specially pertinent reminder that, as we in SDI-EA try to promote SDI and build interoperability amongst distributed services, that the fragility of the communications and transportation infrastructures remain a constraint. What does it mean if we can implement a world-class on-line repository for satellite images in Nairobi if operational agencies and NGOs cannot access it precisely when needed? Who is liable if, in three or five years' time, humanitarian services' crucial decisions are delayed by lack of reliable data services.
Tough questions that won't go away if we ignore them. Neither, it seems to me, are they likely to be more easily answered unless we start now to articulate and specify the requirements to which telcos and other service providers can respond on a fair and contractual basis.
Anyway, we were back to KNSDI on Wednesday, had a happy and fruitful meeting to organize the consultation, and John at least got through the Geoserver installation training. We'll still need more time to get Geonetwork in and running for them, but at least we hit this important milestone and - fingers crossed - the KNSDI folk will like it enough to move it across to their production server. I'll be especially pleased if we can go into the September workshop with Survey of Kenya delivering on-line one of their signature framework data layers, like administrative boundaries. That really would be a feather in the collective caps. But only if it can be made reliable.
Sunday, 12 August 2007
Teflon rules!
Friday two weeks back was the day I've been waiting for - the day the Teflon Principle seemed to actually kick in.
John and I were invited to join Byron from RCMRD (http://www.rcmrd.org in a trip to meet the staff from the Geomatics Unit at the Jomo Kenyatta University for Agriculture and Technology (http://www.jkuat.ac.ke). Professor Gacahri out there is one of the movers in the KNSDI, and had responded to Byron's suggestion that some of the staff out there be given a walk-through on what, in practice, participating in operational SDI could mean to them.
The first surprise was thelab facilities. Remember, I've been in East Africa since the times when a simple PC cost a lecturer's annual salary, a single diskette cost 10 dollars, and too many undergraduate's use of GIS was limited to what they could read about in text books. Here were 30-odd PCs, a functioning LAN and good internet connectivity. My, how things change. And not a bad start at all.. no server, though.
During discussions two interesting things emereged: the first being that, when they'd had the Geonetwork toolkit described to them, the JKUAT staff immediately saw its usefulness to teh school as a potential publisher and provider of geospetial information (as well as the - to me - more obvious attraction of being able to find stuff). The second, and the one that always makes John happiest, is when they twigged that establishing and managing a geospatial would not only streamline their data provision to the students but would open up the possibility for lateral integration of data across studies, rather than just vertically within them. John's alway happiest when this data cohesion aspact emerges spontaneously.
So, the followup is that somewhere towards end of August John and Byron and I will be back out to JKUAT to do the full-blown hands-on training with the Geomatic facluty, and then two weeks after that to do another with the final-year students, though for that one I'll push that it should be the faculty that do it, with John and other's back-stopping them. Like I say, we have to maintain the Teflon Principle, and the idea of a centre of excellence emerging at a school that's already leading the effort for geospatial awareness in the region, achieveing it without any massive financial outlay, and doing it collaboratively with the RCMRD and their training services seems like a marriage made in heaven.
John and I were invited to join Byron from RCMRD (http://www.rcmrd.org in a trip to meet the staff from the Geomatics Unit at the Jomo Kenyatta University for Agriculture and Technology (http://www.jkuat.ac.ke). Professor Gacahri out there is one of the movers in the KNSDI, and had responded to Byron's suggestion that some of the staff out there be given a walk-through on what, in practice, participating in operational SDI could mean to them.
The first surprise was thelab facilities. Remember, I've been in East Africa since the times when a simple PC cost a lecturer's annual salary, a single diskette cost 10 dollars, and too many undergraduate's use of GIS was limited to what they could read about in text books. Here were 30-odd PCs, a functioning LAN and good internet connectivity. My, how things change. And not a bad start at all.. no server, though.
During discussions two interesting things emereged: the first being that, when they'd had the Geonetwork toolkit described to them, the JKUAT staff immediately saw its usefulness to teh school as a potential publisher and provider of geospetial information (as well as the - to me - more obvious attraction of being able to find stuff). The second, and the one that always makes John happiest, is when they twigged that establishing and managing a geospatial would not only streamline their data provision to the students but would open up the possibility for lateral integration of data across studies, rather than just vertically within them. John's alway happiest when this data cohesion aspact emerges spontaneously.
So, the followup is that somewhere towards end of August John and Byron and I will be back out to JKUAT to do the full-blown hands-on training with the Geomatic facluty, and then two weeks after that to do another with the final-year students, though for that one I'll push that it should be the faculty that do it, with John and other's back-stopping them. Like I say, we have to maintain the Teflon Principle, and the idea of a centre of excellence emerging at a school that's already leading the effort for geospatial awareness in the region, achieveing it without any massive financial outlay, and doing it collaboratively with the RCMRD and their training services seems like a marriage made in heaven.
Frustrated Ambitions
One purpose of attempting SDI-EA has been (optimistically?) to test how feasible SDI technologies are outside OECD-type countries, using the UN's own capacities to augment local infrastructure where needs be. Over the last two week has been an exercise in frustrated realization of what the limits can be like.
It all started with a flurry of requests for data and land cover change analysis - one from the GEF evaluation office, the second from a UNEP study of refugee camps, the third from researchers in land use conflict avoidance in Kenya and Tanzania. All good stuff and, thinks I, a good chance to test some of my theories against cold, hard reality.
All these requesters, by thge way, were suffering from the delusion that UNEP/GRID still acted as some sort of massive data archive that would have the necessary data on hand. Alas, no. That's a business model that went the way of the dodo many years ago. Frustration #1 was discovering that our own backyard is in desperate need of a cleanup - the Landsat data and stuff that I know NASA delivered to us years ago is nowhere to be found. Or, more accurately, no-one knows where to find it. Oh dear.
Anyway, this is the age of the internet and postals and all we need do is know how to find the data and use our satellite capacity to pipe it into Kenya for our clients, right? Theory says that we can be clever and use on-line services to slice out justthe bits of the images for relevant study areas - a few megabytes rather than 10's or hundreds of them, smart use of limited bandwidth, more readily accesible to users in developing countries and so on.
Second frustration: NASA's geobrain (http://geobrain.laits.gmu.edu/) usually provides a neat web coverage service whereby you designate your are of interest and it goes off, interrogates the LAITS catalogues and comes back with thumbnails of the available scenes; you make your selection and it then goes to the WCS, excises the footprint you've selected and send a nicely bundled tar package your way in a matter of minutes. What's wrong with this picture? Just the fact that the services is off the air this week. Sigh
So now I'm using sites that only deliver full scenes, such as the Global Land Cover Facility's Earth Science Data Interface (http://glcfapp.umiacs.umd.edu:8080/esdi/index.jsp). Obviously a much greater demand on our satellite link but worth a try. Except for the fact that the link has been slow and flakey and up and down all week - what might otherwise be an easy 20 minute 16 Mb transfer sometimes taking half a day. Sigh. Not the sort of reliable service we'd like to offer our partners.
Glad I didn't offer to mortgage the house as guarantee of being able to deliver on the requests made to us. Maybe things will be better next week. It's still not a great advertisement for SDI, is it?
------------------------ 24 Hours later ---------------------------
Well, things have picked up a bit, and last night I actually managed to pull down 4 MMS scenes and a full TM set, a total of about 350 Mb - not a huge volume of data in these days of streaming media but significant in this part of the world. Now, if only GeoBrain start behaving itself....
--------------- ... and 24 Hours after that? ----------------------
Well, some hacks and work-arounds later, I've managed to pull down about 10 Thematic Mapper and half a dozen MSS scenes, a total of about 2 gigabytes of compressed data moved as scheduled downloads overnight while UNEP's bandwidth is mostly unused. Frustration the Thjird:As it turns out, the usefulness of all this data was pretty limited, usually because the change signals being sought were not significant at the resolution of the Landsat data. This is where having had Geobrain working earlier would have really helped: at least the limitations of the images would have been apparent earlier and more quickly, and the requesters could have adapted their expectations.
Now, this gets me thinking: why am I downloading data from Maryland anyway? What if the Regional Centre for Mapping Resource Development here in Nairobi could bring its Landsat archive on-line, a sort of Geobrain East Africa? Must have a word with my friend Byron about that possibility...
It all started with a flurry of requests for data and land cover change analysis - one from the GEF evaluation office, the second from a UNEP study of refugee camps, the third from researchers in land use conflict avoidance in Kenya and Tanzania. All good stuff and, thinks I, a good chance to test some of my theories against cold, hard reality.
All these requesters, by thge way, were suffering from the delusion that UNEP/GRID still acted as some sort of massive data archive that would have the necessary data on hand. Alas, no. That's a business model that went the way of the dodo many years ago. Frustration #1 was discovering that our own backyard is in desperate need of a cleanup - the Landsat data and stuff that I know NASA delivered to us years ago is nowhere to be found. Or, more accurately, no-one knows where to find it. Oh dear.
Anyway, this is the age of the internet and postals and all we need do is know how to find the data and use our satellite capacity to pipe it into Kenya for our clients, right? Theory says that we can be clever and use on-line services to slice out justthe bits of the images for relevant study areas - a few megabytes rather than 10's or hundreds of them, smart use of limited bandwidth, more readily accesible to users in developing countries and so on.
Second frustration: NASA's geobrain (http://geobrain.laits.gmu.edu/) usually provides a neat web coverage service whereby you designate your are of interest and it goes off, interrogates the LAITS catalogues and comes back with thumbnails of the available scenes; you make your selection and it then goes to the WCS, excises the footprint you've selected and send a nicely bundled tar package your way in a matter of minutes. What's wrong with this picture? Just the fact that the services is off the air this week. Sigh
So now I'm using sites that only deliver full scenes, such as the Global Land Cover Facility's Earth Science Data Interface (http://glcfapp.umiacs.umd.edu:8080/esdi/index.jsp). Obviously a much greater demand on our satellite link but worth a try. Except for the fact that the link has been slow and flakey and up and down all week - what might otherwise be an easy 20 minute 16 Mb transfer sometimes taking half a day. Sigh. Not the sort of reliable service we'd like to offer our partners.
Glad I didn't offer to mortgage the house as guarantee of being able to deliver on the requests made to us. Maybe things will be better next week. It's still not a great advertisement for SDI, is it?
------------------------ 24 Hours later ---------------------------
Well, things have picked up a bit, and last night I actually managed to pull down 4 MMS scenes and a full TM set, a total of about 350 Mb - not a huge volume of data in these days of streaming media but significant in this part of the world. Now, if only GeoBrain start behaving itself....
--------------- ... and 24 Hours after that? ----------------------
Well, some hacks and work-arounds later, I've managed to pull down about 10 Thematic Mapper and half a dozen MSS scenes, a total of about 2 gigabytes of compressed data moved as scheduled downloads overnight while UNEP's bandwidth is mostly unused. Frustration the Thjird:As it turns out, the usefulness of all this data was pretty limited, usually because the change signals being sought were not significant at the resolution of the Landsat data. This is where having had Geobrain working earlier would have really helped: at least the limitations of the images would have been apparent earlier and more quickly, and the requesters could have adapted their expectations.
Now, this gets me thinking: why am I downloading data from Maryland anyway? What if the Regional Centre for Mapping Resource Development here in Nairobi could bring its Landsat archive on-line, a sort of Geobrain East Africa? Must have a word with my friend Byron about that possibility...
Subscribe to:
Posts (Atom)
