[HOT] Status of pre and post quake imagery friendly licenced to OSM for tracing in support of Pak Floods crisis mapping

[Fran Boon]

On 13 August 2010 14:30, David William Bitner
<bitner at sahanafoundation.org> wrote:
> The whole mechanical turk process is something that has been brought up
> within Sahana many times as well. We have consistently run into problems
> where we get dumps upon dumps of spreadsheets, pdfs, scanned documents, etc.
> all in formats that make automated ingest extremely difficult or impossible.
> It may be possible to build this system in Sahana such that it can be
> leveraged by the HOT.  If nothing else, as we both go down the road towards
> mechanical turkization we should certainly coordinate our approaches and/or
> code as much as possible/practical.

Yes, I was thinking that the basic features of a 'Tasking Server' are
pretty much the same as a 'Ticketing Module' so would definitely be
core Sahana functionality which it seems wasteful to duplicate
elsewhere.
There are specific Geospatial contexts for OSM tracing, of course, but
these could also be usefully added to a Ticketing Module - e.g.
allocating areas for search teams to look through.
So whilst this would be brand new advanced functionality, it seems to
have better reusability if developed inside Sahana rather than as a
standalone app.
Any Python/OpenLayers devs wishing to work on this would be made to
feel very welcome :)

PS The Sahana instance for Pakistan is up anyway, so even if inelegant
for the purpose, it can be used for the Ushahidi -> OSM processing
whilst doing it's other work.

F

> On Fri, Aug 13, 2010 at 12:28 AM, Mikel Maron <mikel_maron at yahoo.com> wrote:
>>
>> Yes, a tasking server. That's something we've wanted to develop since
>> Haiti, and there's been a couple attempts at Camp Roberts. Tasks could be
>> something examining a point from Ushahidi, tagging it properly and checking
>> for duplication. Or looking at a tile of satellite imagery and tracing out
>> roads. Or getting an update of open schools from the national govt. etc.
>>
>> The task would have a simple interface, but with enough information to
>> properly review, ie maps, access to tags/history/users, etc. Each task could
>> be reviewed multiple times. The task could go through various processes
>> before being presented to a human ... for instance, it might attempt to find
>> a match for an existing feature in OSM, based on name or even foreign key.
>> Completed tasks can be pushed directly to OSM.
>>
>> I do think of it like an open source mechanical turk, for OSM. Or maybe
>> Swift River for maps?
>>
>> == Mikel Maron ==
>> +254(0)724899738 @mikel s:mikelmaron
>> http://mapkibera.org/
>> http://wiki.openstreetmap.org/index.php/Haiti
>>
>> ________________________________
>> From: Chris Blow <cgblow at gmail.com>
>> To: Fran Boon <francisboon at gmail.com>
>> Cc: "hot at openstreetmap.org" <hot at openstreetmap.org>
>> Sent: Thu, August 12, 2010 8:55:26 PM
>> Subject: Re: [HOT] Status of pre and post quake imagery friendly licenced
>> to OSM for tracing in support of Pak Floods crisis mapping
>>
>> There is something elegant about linking two crisis map systems with a
>> third. Unfortunately there is also something quite inelegant about it -- at
>> least as a long term solution.
>>
>> It sounds like what is missing is not file conversion but rather some way
>> to queue and review a changeset. I would appreciate other feedback on this
>> issue -- surely there are precedents for solving this problem? Can we solve
>> it without JOSM or potlatch?
>>
>> c
>>
>> On Aug 12, 2010, at 4:12, Fran Boon <francisboon at gmail.com> wrote:
>>
>> > On 11/08/2010 12:34, Kate Chapman wrote:
>> >> We were talking about doing an integration with a manual step from
>> >> Ushahidi to OSM in Haiti, but nobody has an automated way to do this
>> >> that I'm aware.  The issue is that there isn't a good way to detect if
>> >> a feature exists to prevent duplication.  Making an easy way to go
>> >> from Ushahidi to OSM files could at least allow people to check data
>> >> and import it if it is okay.
>> >
>> > That could be done using Sahana Eden - this can read both Ushahidi &
>> > .osm & can write-out .osm.
>> >
>> > I set up an instance last night:
>> > http://eden.sahanafoundation.org/wiki/Pakistan
>> >
>> > F
>> >
>> > _______________________________________________
>> > HOT mailing list
>> > HOT at openstreetmap.org
>> > http://lists.openstreetmap.org/listinfo/hot
>>
>> _______________________________________________
>> HOT mailing list
>> HOT at openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/hot
>>
>> _______________________________________________
>> HOT mailing list
>> HOT at openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/hot
>>
>
>
>
> --
> ************************************
> David William Bitner
>