[HOT] Status of pre and post quake imagery friendly licenced to OSM for tracing in support of Pak Floods crisis mapping
acrosscanadatrails at gmail.com
Fri Aug 13 16:40:27 BST 2010
the system that we are using for canada, works great.
and it will work great in an emergency for fast mapping an area.
the constant variable is in the grid system, an extention of the nts
system with quad-tree tiling.
all .osm data is split into managable squares, small enough for 1
person to handle at a time.
the googledocs chart showing this data is updated in real time and
also has an instant chat feature.
irc chat, while working also is helpful, for instant feedback.
the chart system can handle multiple datasets.
it would also require a little 'give' from osmland to permit the
uploading of a tile grid, since degree lines are not possable in josm
to view, and listing the area grid system works.
i have never done archeology, but the way to view a archoligical dig
site is the same. each square in the grid is numbered.
..... thankfully, computerteddy already has the planet #s for 1x1 degrees.
my 2 cents.
im on the #osm-ca sometimes if anyone needs moreinfo
On 8/13/10, Fran Boon <francisboon at gmail.com> wrote:
> 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,
>> all in formats that make automated ingest extremely difficult or
>> 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
>> mechanical turkization we should certainly coordinate our approaches
>> 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
> 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.
>> On Fri, Aug 13, 2010 at 12:28 AM, Mikel Maron <mikel_maron at yahoo.com>
>>> 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
>>> for duplication. Or looking at a tile of satellite imagery and tracing
>>> 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
>>> be reviewed multiple times. The task could go through various processes
>>> before being presented to a human ... for instance, it might attempt to
>>> a match for an existing feature in OSM, based on name or even foreign
>>> 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
>>> 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 --
>>> 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
>>> issue -- surely there are precedents for solving this problem? Can we
>>> it without JOSM or potlatch?
>>> 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
>>> HOT mailing list
>>> HOT at openstreetmap.org
>> David William Bitner
> HOT mailing list
> HOT at openstreetmap.org
IRC: irc://irc.oftc.net #osm-ca Canadian OSM channel (an open chat room)
More information about the HOT