Random Shelterfinder thoughts
Wendy Edwards
Decide who our expected users are. Are they currently aware of
ShelterFinder? If not, outreach is important. If so, try to get
feedback on whether SF is likely to meet their needs.
Outreach
Find existing relief agencies and establish relationships with them.
Figure out how our work could fit in with theirs, and whether anyone's
interested in sharing data. Would we be likely to interact with
government agencies or community organizations? If so, get some ideas
about who we should talk with.
Software
Currently uses DB, scripting, and Google Maps. User interface looks
good, but it would be helpful to have end users test it. It might
also be useful to incorporate feeds (e.g., RSS) when available, to try
to keep our information current. Would it be worthwhile to expand to
Google Earth (more sophisticated, but possible more
bandwidth-intensive)?
Internationalization
Are there any standard internationalization packages that we could
plug in to make it easier for non-English speakers to use?
paola....@gmail.com
they are all good points
below some thouughts from me
p
Preliminary
Decide who our expected users are.
i think you could say anyone who does relief in an emergency area could find usefulness
in such a tool
Are they currently aware of
ShelterFinder?
i doubt it
If not, outreach is important.
need list of ngo email addresses in the area, will draft email - anyone can supply some
emails there?
If so, try to get
feedback on whether SF is likely to meet their needs.
i think they'll either use it or not use it, proabbly if these guys are up into the neck with work
feedback is likely to be yse/no thanks - but I agree with could work with them to develop the tool
Outreach
Find existing relief agencies and establish relationships with them.
okay I got three or four emails somehwere, lets start making a list
Figure out how our work could fit in with theirs, and whether anyone's
interested in sharing data. Would we be likely to interact with
government agencies or community organizations? If so, get some ideas
about who we should talk with.
someone I do not see that shelterfinder is 'our' tool and that they would be sharing data with 'us'
Its a tool that they can use for their own internal and external coordination, in case they do not have antying similar. I think shelters and camps are forming spontaneusly, and each worker will be aware of one or two of them, as they come across them.
Software
Currently uses DB, scripting, and Google Maps. User interface looks
good, but it would be helpful to have end users test it.
I have already tested it as if I was an end user, and reported what improvements I would see useful
It might
also be useful to incorporate feeds (e.g., RSS) when available, to try
to keep our information current.
that should be easy, but personally i canot maniupulate the home page cause I do not know how to
edit it, so maybe its easier on the wiki?
Would it be worthwhile to expand to
Google Earth (more sophisticated, but possible more
bandwidth-intensive)?
i think thats a good idea, but after the functinality is up and as a 'google earth' version
so that we have both low and high bandwidth options incorporated and the user choses which one to use -
Internationalization
Are there any standard internationalization packages that we could
plug in to make it easier for non-English speakers to use?
in my experience that is not easy but can be done with most tools
I assume the tools is entirely written in php, and it looks like there is an indonesia php nuke
version
http://mail.cpgnuke.com/pipermail/cvs_cpgnuke.com/2004-August/000773.html
i think Anand has done a great job at adding some indonesia words in data interface so far
maybe we shold have two plans
short tem:
get it up as it is, fix the bugs, find a few users and start working with it
long term
consider adding a customisable interface, possibly using other tools
p
--
Paola Di Maio
Systems Analyst
www.content-wire.com
paola....@gmail.com
i have to go for a few hours
please lets consider using sahana code to power sheltefinder
i have is it worfk online and its good
but to incorporate our feeds and maps to it
as it doesn have it he
code and all with angelo
i ll be back
cheers
pdm
Thanks for this, Wendy and Paola. I seem to be having trouble posting to the ShelterFinder group, as my Google account has changed, but some thoughts in response below.
The stuff on Sahana looks interesting - what we were doing, basically, but maybe better organised and resourced. Keep us in touch with what you find Paola - no point reinventing wheels!
Preliminary
From my point of view, we still need a much clearer picture of end-users and their needs, and have direct conversations with them. Aiming at everyone and hoping is too vague - that didn't work for Katrina, doesn't work in general aid interventions.
I wonder if we should even aim to become a major clearing house for disaster data, given our lack of resources and 'official' organisational support. Perhaps we're better positioned to try out and demonstrate some ideas to show what is possible, and influence the debate and development of tools in that way. One key element was mapping, which may already be mainstreamed now. The others are collaborative data collation/entry/maintenance, open standards for data exchange, etc. We might be more realistic in aiming to get the big players to say, "wow, I didn't realise that was possible already, and how powerful it is. We should be doing that".
Another overlapping aim would be to create a picture of events and needs that allows the public to see what is happening on the ground in a more real way, and respond however is appropriate for each disaster (which will vary). Thats closer to whatever you were planning with p2pAid, I guess.
Each specific aim will have specific requirements, rather than the vague all-encompassing ones that I for one don't find clear or useful.
Outreach
People involved will be busy, already too swamped with information to try out something new from a cold e-mail, and that is a problem for us at the moment. Unless we have personal contacts, its unlikely to work. Aid organisations can be territorial, blinkered and overstretched in general.
Data (- I've added this category)
We still don't have clear examples of what the system can do which could 'wow' a user in a clear, unconfusing way. Partly that is the system being unfinished, but its also partly not having enough meaningful data to populate it with. I've got four vague addresses for hospitals, no real current data except speculation, and almost no location data - forget data on any shelters (unless there is info Angelo has got which I haven't seen). We don't have any of this information after several days, and I haven't seen anyone scoping that issue. Instead of building code then waiting for data, or gathering data before we build the code, we probably need to do both at once.
Software
The current system is creaking, and hasn't been reconfigured or tested properly yet - I woke up today to about 2,500 automatic error message e-mails from just a few searches overnight. That is not surprising - it was built for a different situation in the States, and at speed, so even the original code was ropey. I am not going to put days of my time again, unless I see some progress on the other things (esp data as mentioned above) - but Paola and Wendy have the code, if anyone else wants to try.
'Would it be worthwhile to expand to Google Earth'
All this needs is a feed for KML from the site. We still need mechanisms for adding and updating data for locations, but how that is output and represented (Geo-RSS, XML, XLS or KML) seems independent to me, from what I understand.
Internationalization
Language/local differences are an issue here, as are getting accurate map data/geolocation. This isn't as straightforward as plugging in a 'standard internationalization package', as the underlying code was not built with this in mind, and I don't know of any such 'standard packages' - we'd probably have to build the standard and then a framework for packages to be created. Ideally for future disasters we (or someone else) would be more prepared in advance.
When I reworked the system for Pakistan, I abstracted away from specific place name types - I'm now using fairly generic structures (address1-6) etc in the database, with customisable labels. You're seeing that in action now for Indonesia. On placenames Its already much easier than last year to get location data files and geolocate for other countries, and that will get easier with time (although I currently have a problem for Indonesia, without postcode-level data I can geolocate from). We don't need a huge location database in any case - just to be able to geolocate the key places, like shelters, hospitals etc as needed, as simply as possible.
For text (all the explanatory stuff) ideally we'd want that translated, with multiple languages available. That would require a fairly stable core version of the text, instructions, which requires a settled version of the system itself, which we don't have yet. Each disaster has different priorities and local aspects too, so it still needs some flexibility built in.
All of this takes preparation, especially if it was all readied and in standby mode for many countries. It would be more realistic, I think, to have a fairly simple and stable system, well-documented, with clear standards and set-up tasks, which can be used to create the necessary data and text on-the-fly for each affected region after a disaster happens, using the help of some experienced volunteers and new ones too. We're not close to that at the moment, and need some clearer vision to get to that stage.
Anand
Angelo Embuldeniya
you could do is reuse the mapping feature within Sahana, given that
sahana was originally built on top of mambo in jan 05 and then a code
revamp was carried out to rebuild it to include many drupal modules
and base structures.
sahana's linux distros and source packages
are available here:
http://www.sahana.lk/node/11
demo is up here:
http://www.sahana.lk/sahana2/
and if necessary we could touch base with the core sahana team :)
I know that parts of sahana being deployed for java might not be made
available to an open audience online or offline for that matter as
seen in the tsunami in sri lanka and the quake last yr in pakistan...
however shelter finder might just take the base code off sahana and
integrate it or fit in within the mapping/rss of sf.
Consindering that sahana is a drupal/mambo system.. am pretty sure
it's awfully easy to top in an rss or mapping compononent.. it might
have already been done though am not so sure,
What are your thoughts?
cheers,
angelo.
PS: re mapping I've just got a call from Mapaction in the uk who
deployed their team to indo today morning and they've said they'll be
delighted to share information and collaborate once something is up...
they mean collab now and for future disasters,
Angelo Embuldeniya
http://www.sahana.lk/sahana2/index.php?mod=gis&act=default
Angelo Embuldeniya
islamabad for the pak quake.. i don't have contact info right now of
the team their deploying but i will in the next 12 hours. the reason
their system is not online yet is becuase its still being set up
remotely from sri lanka while their team of 3 is flown to indo.
unfortuately the site is offlimits to citizens and relief volunteers.
considering that sahana have their distros available online... its a
good possibility that as sf have done in the past we take their sys
and put it up on a server and keep it open for future disasters?
i see the reason for governments closing sahana installs up --
sensitivity of certain areas.... retape maybe something else..
On 6/4/06, Anand Madhvani <an...@dosima.org> wrote:
> Hi Angelo,
>
> It looks like Sahana could do what we're looking to do, from what I can
> see on their site - including a few screenshots of maps. I just can't
> find any working instances on Indonesia at the moment. It looks like
> the code is there, but no-one is using it online for this right now.
>
> They seem to have had a lot more momentum and work done than SF, and I
> don't want to be reinventing wheels - am not attached to our existing
> code.
>
> Their focus may be more for closed systems though for the aid agencies
> only, whereas I think we've deliberately kept data open, including the
> feeds etc. Java too might be a barrier to potential users, as you say.
>
> One of the lessons from Katrina was that there was a lot of 'grey' data
> out there, parallel to what agencies might be using, and the internet
> opened up new channels of communication and information
> gathering/dissemination they might be underestimating the value of.
> Thats partly why I was keen to keep the basic interface and data-entry
> as a simple HTML interface, rather than moving entirely into Google
> Earth or some more sophisticated platform.
>
> Still, I'm sure Sahana could get set up in an open way. It probably
> would be useful to talk to their team, and find out what is happening now.
>
> Anand
paola....@gmail.com
i havent been thinking much about this, but given that your code is cosing you a lot of time
maybe we should se t it aside and get something up that isready to deploy
my first thought would be: get the code up on the server, and incorporate with our current functions like te gis and feeds
if there is something that their code doesn do, we extend it further
at least we have a basic implementation that can be used
please take a look at what angelo circulated earlier and let me know what you think
and what you may need from us, or from sahana, in order to use their code if thats what we decide
i am going to be travelling long haul as of tomorrow , so i wont be around much
pdm
> >> > > > also be useful to incorporate feeds ( e.g., RSS) when available,
Anand Madhvani
have!
It would also be easier to customise something like this that has been
properly designed and documented - the current SF code was thrown
together in late night stints during Katrina.
We need a bit more clarity about the Java side, but am happy to move
aside on this one.
Anand
paola....@gmail.com wrote:
> Anand
>
> i havent been thinking much about this, but given that your code is
> cosing you a lot of time
> maybe we should se t it aside and get something up that isready to deploy
>
> my first thought would be: get the code up on the server, and
> incorporate with our current functions like te gis and feeds
>
> if there is something that their code doesn do, we extend it further
> at least we have a basic implementation that can be used
>
> please take a look at what angelo circulated earlier and let me know
> what you think
> and what you may need from us, or from sahana, in order to use their
> code if thats what we decide
>
> i am going to be travelling long haul as of tomorrow , so i wont be
> around much
>
> pdm
>
>
>
>
>
> On 6/4/06, *Angelo Embuldeniya* <angelo.em...@gmail.com
> <mailto:angelo.em...@gmail.com>> wrote:
>
> Their team i believe is the same one that went in and set up in
> islamabad for the pak quake.. i don't have contact info right now of
> the team their deploying but i will in the next 12 hours. the reason
> their system is not online yet is becuase its still being set up
> remotely from sri lanka while their team of 3 is flown to indo.
>
> unfortuately the site is offlimits to citizens and relief volunteers.
>
> considering that sahana have their distros available online... its a
> good possibility that as sf have done in the past we take their sys
> and put it up on a server and keep it open for future disasters?
>
> i see the reason for governments closing sahana installs up --
> sensitivity of certain areas.... retape maybe something else..
>
> On 6/4/06, Anand Madhvani <an...@dosima.org
> <mailto:paola....@gmail.com> <paola....@gmail.com
> <mailto:paola....@gmail.com>> wrote:
> > >> > anand
> > >> > i have to go for a few hours
> > >> >
> > >> > please lets consider using sahana code to power sheltefinder
> > >> > i have is it worfk online and its good
> > >> >
> > >> > but to incorporate our feeds and maps to it
> > >> > as it doesn have it he
> > >> > code and all with angelo
> > >> >
> > >> > i ll be back
> > >> > cheers
> > >> > pdm
> > >> >
> > >> >
> > >> >
> > >> > On 6/4/06, Anand Madhvani <an...@dosima.org
> > >> > > www.content-wire.com <http://www.content-wire.com>
> > >> > >
> > >> > >
> > >> >
> > >> >
> > >> >
> > >> > --
> > >> > Paola Di Maio
> > >> > Systems Analyst
> > >> > www.content-wire.com <http://www.content-wire.com>
> > >> >
> > >>
> > >
> >
>
>
>
>
> --
> Paola Di Maio
> Systems Analyst
Wendy Edwards
additional modules for that if we want more functionality and share
them with the Sahana group.
Wendy
Wendy Edwards
> From my point of view, we still need a much clearer picture of end-users
> and their needs, and have direct conversations with them. Aiming at
> everyone and hoping is too vague - that didn't work for Katrina, doesn't
> work in general aid interventions.
>
> I wonder if we should even aim to become a major clearing house for
> disaster data, given our lack of resources and 'official' organisational
> support. Perhaps we're better positioned to try out and demonstrate some
> ideas to show what is possible, and influence the debate and development of
> tools in that way. One key element was mapping, which may already be
> mainstreamed now. The others are collaborative data
> collation/entry/maintenance, open standards for data exchange, etc. We
> might be more realistic in aiming to get the big players to say, "wow, I
> didn't realise that was possible already, and how powerful it is. We should
> be doing that".
Yes, I'd really like to see us join forces with some of the bigger
players - we show them possibilities, and they give us feedback how
our ideas would fit in with their needs.
> Another overlapping aim would be to create a picture of events and needs
> that allows the public to see what is happening on the ground in a more real
> way, and respond however is appropriate for each disaster (which will vary).
> Thats closer to whatever you were planning with p2pAid, I guess.
That could be useful too, though it would be worth looking into
whether this is already being done (e.g., ICRC).
> Each specific aim will have specific requirements, rather than the vague
> all-encompassing ones that I for one don't find clear or useful.
Yes, specific requirements would help a lot. Of course, we may have
to adjust some things, but that's still better than vague goals.
> Outreach
> People involved will be busy, already too swamped with information to try
> out something new from a cold e-mail, and that is a problem for us at the
> moment. Unless we have personal contacts, its unlikely to work. Aid
> organisations can be territorial, blinkered and overstretched in general.
True. On the positive side, I think some of us have developed at
least a few contacts. It'll be important to be realistic about not
expecting quick responses during a disaster.
>
> Data (- I've added this category)
> We still don't have clear examples of what the system can do which could
> 'wow' a user in a clear, unconfusing way. Partly that is the system being
> unfinished, but its also partly not having enough meaningful data to
> populate it with. I've got four vague addresses for hospitals, no real
> current data except speculation, and almost no location data - forget data
> on any shelters (unless there is info Angelo has got which I haven't seen).
> We don't have any of this information after several days, and I haven't seen
> anyone scoping that issue. Instead of building code then waiting for data,
> or gathering data before we build the code, we probably need to do both at
> once.
I'm trying to take a longer view - how can we create a general
application to help during diasters? It seems like ideally, the basic
functionality would be in place ahead of time, and as soon as the
disaster struck, it would be a matter of getting the specific data
into the system. We might also want to get some ideas ahead of time
about where to get data quickly (GIS, relief agencies, etc.)
> Software
> The current system is creaking, and hasn't been reconfigured or tested
> properly yet - I woke up today to about 2,500 automatic error message
> e-mails from just a few searches overnight. That is not surprising - it was
> built for a different situation in the States, and at speed, so even the
> original code was ropey. I am not going to put days of my time again,
> unless I see some progress on the other things (esp data as mentioned above)
> - but Paola and Wendy have the code, if anyone else wants to try.
>
To be honest, I'm liking the idea of trying Sahana. The SF code was
great, but we're a small team. I'd rather leverage a bigger group's
efforts.
> 'Would it be worthwhile to expand to Google Earth'
> All this needs is a feed for KML from the site. We still need mechanisms
> for adding and updating data for locations, but how that is output and
> represented (Geo-RSS, XML, XLS or KML) seems independent to me, from what I
> understand.
We should probably still have a plain maps option, because Google
Earth demands more power and more bandwidth.
> Internationalization
> Language/local differences are an issue here, as are getting accurate map
> data/geolocation. This isn't as straightforward as plugging in a 'standard
> internationalization package', as the underlying code was not built with
> this in mind, and I don't know of any such 'standard packages' - we'd
> probably have to build the standard and then a framework for packages to be
> created. Ideally for future disasters we (or someone else) would be more
> prepared in advance.
Yeah, I agree.
> When I reworked the system for Pakistan, I abstracted away from specific
> place name types - I'm now using fairly generic structures (address1-6) etc
> in the database, with customisable labels. You're seeing that in action now
> for Indonesia. On placenames Its already much easier than last year to get
> location data files and geolocate for other countries, and that will get
> easier with time (although I currently have a problem for Indonesia, without
> postcode-level data I can geolocate from). We don't need a huge location
> database in any case - just to be able to geolocate the key places, like
> shelters, hospitals etc as needed, as simply as possible.
>
> For text (all the explanatory stuff) ideally we'd want that translated,
> with multiple languages available. That would require a fairly stable core
> version of the text, instructions, which requires a settled version of the
> system itself, which we don't have yet. Each disaster has different
> priorities and local aspects too, so it still needs some flexibility built
> in.
Yes.
> All of this takes preparation, especially if it was all readied and in
> standby mode for many countries. It would be more realistic, I think, to
> have a fairly simple and stable system, well-documented, with clear
> standards and set-up tasks, which can be used to create the necessary data
> and text on-the-fly for each affected region after a disaster happens, using
> the help of some experienced volunteers and new ones too. We're not close
> to that at the moment, and need some clearer vision to get to that stage.
Yes, I think you're right.
Anand Madhvani
Thanks for your points - I'm glad we're talking at this level, as its helping to clarify and get our ideas into step. It sounds like Sahana is the obvious thing to try, and find out the limitations in terms of Java requirements etc. Who will do this?
Mikel Maron wrote:
While I idealistically hope for systems that bypass the inefficiencies and complexities of the large aid organizations, I don't know if that will be effective on a large scale in the short term. At the very least, these orgs will continue to play a role even in a p2pAid situation. They are after all mostly composed of people trying to do good things.I'd disagree with the first part of this - I want to see the aid organisations and governments to be better organised and more efficient, not bypassed, in the longer term. It seems to me like we should be demonstrating what is possible, but then moving on when that is being adopted. I think a lot of these things are gradually being taken up because they are obvious things to do, and feel positive about that for the long-term. Our role might be to speed up that process, to catalyse it.
Wendy Edwards wrote:
Yes, I'd really like to see us join forces with some of the bigger
players - we show them possibilities, and they give us feedback how
our ideas would fit in with their needs.
I also suspect there are people in the organisations pushing for cooperation, but their main organisations may be slow, unresponsive and territorial. (I used to work for the European Commission trying to improve tropical forestry aid coordination, so have some first-hand experience of this). GLIDE is a step in the right direction but still just a shared numbering system, not real cooperation.
On the specific detail about placenames, the involvement of MapAction is great news. That will make things easier. In a few years of course, Google and others will have everywhere covered in any case, so I don't see mapping as a long-term problem.
Mikel Maron wrote:
>When I reworked the system for Pakistan, I abstracted away from specific place name types - I'm now using fairly generic structures (address1-6) etc in the database, with customisable
> labels. You're seeing that in action now for Indonesia. On placenames Its already much easier than last year to get location data files and geolocate for other countries, and that will get
> easier with time (although I currently have a problem for Indonesia, without postcode-level data I can geolocate from). We don't need a huge location database in any case - just to be able
> to geolocate the key places, like shelters, hospitals etc as needed, as simply as possible.
http://geonames.org/ is a very good source for internationalized placenames, in a wiki style, with data export.
Geonames is an growing resource which I've already used to populate the current database with places in the region, although what they have is patchy in places (big regular square gaps when you try and map it, suggesting missing data). I'm attaching the dataset used on the site at the moment (SQL format), which Paola and Wendy previously saw, but probably should go on the Wiki now we can upload files.
There are two immediate issues I can see:
1. what we need is to be able to geo-locate a village, shelter or hospital easily, when someone enters it, without worrying about
finding the latitudes/longitudes etc.
I hadn't set this up yet, but its relatively easy to query a site like Geonames (or even Google, though they don't want you to)
whenever someone enters a location, and get the lat/longs out. (I used Maplandia before for Pakistan but they blocked
my automated scraping). Geonames is explicitly set up with structured data query tools to allow this. It has limited data
for Indonesia at postcode level - but could give you town, village, city etc.
It also needs some creative thinking how it displays on a map (it may give the same lat/long for every location in,
for instance, Yogyakarta, so they would cover each other up on the simplest mappings. Thats why finer-grained
data, like mapping at postal code level, would be more useful).
2. their administrative regions aren't tiered - you can't tell which village falls under which sub-district falls under which province, etc.
With Katrina it was useful to get breakdowns by state, county etc and aggregate needs on the ground in that way, once
this information was in the database, and linked with individual data items like shelters then.
Wendy Edwards
It looks like MapAction is willing to talk with us, and I'd like to
work cooperatively with them (now and in the future). As far as
large aid orgs and inefficiencies, I don't think we need to be
completely controlled by them - it's more like establishing contacts
and developing working relationships.
Assuming I can get the Linux partition on my laptop updated, I'm
willing to set up Sahana and test it.
BTW, I'm wondering if it's worth looking at ESRI some more - they
have free disaster data available, and I can check it out.
http://www.esri.com/disaster_response/indonesia053006.html
They're also coming out with some free ArcExplorer software, which
I'm planning to try this week.
Wendy
Mikel Maron
> I'd disagree with the first part of this - I want to see the aid organisations and governments to be better organised and more efficient, not bypassed, in the longer term. It seems to me like we
> should be demonstrating what is possible, but then moving on when that is being adopted. I think a lot of these things are gradually being taken up because they are obvious things to do, and
> feel positive about that for the long-term. Our role might be to speed up that process, to catalyse it.
> I also suspect there are people in the organisations pushing for cooperation, but their main organisations may be slow, unresponsive and territorial. (I used to work for the European
> Commission trying to improve tropical forestry aid coordination, so have some first-hand experience of this). GLIDE is a step in the right direction but still just a shared numbering system,
> not real cooperation.
> On the specific detail about placenames, the involvement of MapAction is great news. That will make things easier. In a few years of course, Google and others will have everywhere
> covered in any case, so I don't see mapping as a long-term problem.
> It also needs some creative thinking how it displays on a map (it may give the same lat/long for every location in,
> for instance, Yogyakarta, so they would cover each other up on the simplest mappings. Thats why finer-grained
> data, like mapping at postal code level, would be more useful).
> 2. their administrative regions aren't tiered - you can't tell which village falls under which sub-district falls under which province, etc.
> With Katrina it was useful to get breakdowns by state, county etc and aggregate needs on the ground in that way, once
> this information was in the database, and linked with individual data items like shelters then.
-Mikel
Mikel Maron
> Assuming I can get the Linux partition on my laptop updated, I'm
> willing to set up Sahana and test it.
> BTW, I'm wondering if it's worth looking at ESRI some more - they
> have free disaster data available, and I can check it out.
>
> http://www.esri.com/disaster_response/indonesia053006.html
> They're also coming out with some free ArcExplorer software, which
> I'm planning to try this week.
Btw, is anyone here also going to the Where 2.0 conference next week? This would be a good opportunity to get in touch with the commercial players, and see what they can offer.
Angelo Embuldeniya
is that the vosocc finally got in there as the coordination module.. i
know it's off limits for some folks but I'm hoping that evenutally
some inform such as the summaries will get aggregated for public
access.. currently vosocc doesn't have rss, or maybe that's something
they're working on Mikel?
Also i never figured out why gdacs had a nice sms feature that doesn't
really work but the vosocc one has it within a forum like
apprearance...
re mapaction, they're cooperating :) out of experience their work is
wonderful... im not saying unosat isn't either but mapaction is more
flexible, web2.0 friendly and open source fans.. some of their mapping
tools might not yet be oss but we should give them some more time
:)... hey they've said they'll share gps/cords data with us :) open
source there.
cheers,
angelo.
Mikel Maron
I believe RSS is playing a role on the backend for VOSOCC-GDACS integration. Also useful to hear about problems with their SMS alerts. Perhaps we can gather suggestions and comments on GDACS, and start a discussion with them.
MapAction collaboration is great. I'm actually hoping to become a volunteer in the fall.
-Mikel