[HOT] The status of iD in HOT contexts/projects

Sat Sep 28 09:21:32 UTC 2013

Hi John et al.,

Thanks for the update!

Acknowledged that imagery may have to wait a while. C'est la vie — I know you all are kept quite busy as things are.

Regarding conflict detection, I think myself, Kareem Ahmed, and the wonderful folks at the Kathmandu Living Labs will have a lot more constructive feedback after our training this week. We'll keep a running log of issues with all the softwares we're using and report back regarding the highest priority fixes for iD. Overall I agree that a full blown versioning editor is beyond scope for iD — we just need something a little more user-friendly than the current error messages.

Many thanks to Simon and the Operations Working Group for their GPX / Waypoints help!

Cheers,
Robert

Robert Banick | GIS Coordinator | International Services | Ì American Red Cross<http://www.redcross.org/>
2025 E Street NW, Washington, DC 20006
Tel 202-303-5017 | Cell 202-805-3679 | Skype robert.banick

From: John Firebaugh <john.firebaugh at gmail.com<mailto:john.firebaugh at gmail.com>>
Date: Thursday, September 26, 2013 11:35 PM
To: Robert Banick <robert.banick at redcross.org<mailto:robert.banick at redcross.org>>
Cc: "kathleen.danielson at gmail.com<mailto:kathleen.danielson at gmail.com>" <kathleen.danielson at gmail.com<mailto:kathleen.danielson at gmail.com>>, william skora <skorasaurus at gmail.com<mailto:skorasaurus at gmail.com>>, "hot at openstreetmap.org<mailto:hot at openstreetmap.org>" <hot at openstreetmap.org<mailto:hot at openstreetmap.org>>, Tom MacWright <tom at macwright.org<mailto:tom at macwright.org>>, Simon Johnson <SJohnson at redcross.org.uk<mailto:SJohnson at redcross.org.uk>>
Subject: Re: [HOT] The status of iD in HOT contexts/projects

Will, Robert,

Thanks very much for the thoughtful feedback. I've mentally updated some priorities, and can give you a status update on a few of the items you mentioned:

- GPS layer: see https://github.com/systemed/iD/issues/277#issuecomment-25187237
- Waypoint support in GPX traces: thanks to Simon Johnson's work, this will be included in 1.2.0, which I've just submitted to OSM.org.
- Imagery offset database: this is another feature where a pull request would greatly expedite things. It's on my radar, but not a top priority.
- Conflict detection: this could range from 'periodic preemptive check for new data', which might be fairly simple to implement, to 'full blown detection and resolution', which is very complex and likely out of scope entirely for iD. It would be helpful if you could add your opinion on what the necessary scope is and ideas for specific changes to the issue.

cheers,
John

On Tue, Sep 24, 2013 at 8:06 AM, Banick, Robert <Robert.Banick at redcross.org<mailto:Robert.Banick at redcross.org>> wrote:
Hi Will,

Super helpful feedback. I agree with your specific points but not with the overall thrust of your argument. Given that I'm about to conduct a training next week using iD, I hope I'm right :)

Some constructive responses:

Simon Johnson of the British Red Cross has been working on the GPX point layer since last week and has submitted a pull request to have it fixed. I'm not sure what the status of that pull request is but selfishly hope that it's incorporated by next week. Tom, John et al, any ETA on that?

I'm planning on using the tasking manager to organize the iD tracing, with the hope that we can avoid conflicts this way. I agree that conflict resolution is fairly poor and hope to get around it that way. Any experience on your end doing this?

I never plan on relying on Bing anyways, since it's too fuzzy in many rural areas of the developing world to be of any use. That's not the fault of the iD team of course, just the reality of imagery availability in its current state.

Robert

Robert Banick | Field GIS Coordinator | International Services | Ì American Red Cross<http://www.redcross.org/>
2025 E Street NW, Washington, DC 20006

From: "kathleen.danielson at gmail.com<mailto:kathleen.danielson at gmail.com>" <kathleen.danielson at gmail.com<mailto:kathleen.danielson at gmail.com>>
Date: Tuesday, September 24, 2013 8:49 AM
To: william skora <skorasaurus at gmail.com<mailto:skorasaurus at gmail.com>>
Cc: John Firebaugh <john.firebaugh at gmail.com<mailto:john.firebaugh at gmail.com>>, "hot at openstreetmap.org<mailto:hot at openstreetmap.org>" <hot at openstreetmap.org<mailto:hot at openstreetmap.org>>, Tom MacWright <tom at macwright.org<mailto:tom at macwright.org>>
Subject: Re: [HOT] The status of iD in HOT contexts/projects

Great example of constructive feedback, Will. I'm sure that Tom, John, and team really appreciate it!

On Sep 23, 2013 11:00 PM, "Will Skora" <skorasaurus at gmail.com<mailto:skorasaurus at gmail.com>> wrote:
Robert Soden mentioned the interest of using iD for OSM-related
trainings during today's HOT tech chat. While in Northern Haiti for
the CAP103 project in May-June 2013, a handful of the advanced mappers
in Northern Haiti had learned about iD and wanted to learn how to use
it, and I attempted to give 2-3 informal brief walkthroughs.
afterwards, I wrote my experiences about it and then forgot to share
them with the HOT community until now and thought it would be useful
to share since we haven't discussed the use of iD in HOT contexts.

First off, I truly admire the work done for iD. Its development has
been rapid, the developers are very friendly, humble, and responsive,
they set an example for the OSM developers' community. I understand
that iD developers have other competiting priorities to help improve
the editor but there's several issues that I've experienced and as a
result, would really hesitate to use iD in HOT contexts where these
issues would be appear.

- Lack of a GPS layer
 - you can currently upload a single GPS track to display in the
background, but you are not yet able to load the entire background of
GPS traces from OSM of a given area.
 https://github.com/systemed/iD/issues/277
 Although the quantity and quality of imagery sources available has
increased in recent years, there's still a handful of areas in the
world where there's no traceable imagery available, often in areas
where HOT has operated . In these instances, mappers still have to
rely solely on GPX points and GPS layers to map.

- Lack of waypoint support in GPX traces
https://github.com/systemed/iD/issues/1557
 As we often take waypoints as we often take GPS traces and write down
information that describes the area associated with the corresponding
waypoint.

 - In some areas, bing imagery is 'offset' - a road traced with bing,
for example, may be 30 or 50 meters away from where it is on the
ground. To fix this, 'offsetting the imagery' is necessary. At the
moment, iD has the capability to adjust imagery, but the adjustment
must be manually done each time a user opens iD to edit OSM.
Secondly, without a GPS trace layer (mentioned above), a user does not
know whether the data already mapped to OSM are currently offset or
not. This is a bit problematic to newer OSM users who may move data,
believing that it should match up with bing imagery.
 https://github.com/systemed/iD/issues/1124

 - conflict detection
  - no way to detect conflicts. This is problematic when there are
mapping parties and mappers are editing in areas very close to each
and you may be editing the same ways as your fellow users.
  https://github.com/systemed/iD/issues/1053

At the moment, iD is a great editor but the above issues can be quite
problematic in some HOT contexts (that don't have great imagery for
example) and would be considered dealbreakers in these HOT
environments.

Given the rapid development of iD, we may even have to reasses it in
just a few months. Until then, we should keep iD on the back burner.

Regards,
Will

_______________________________________________
HOT mailing list
HOT at openstreetmap.org<mailto:HOT at openstreetmap.org>
https://lists.openstreetmap.org/listinfo/hot

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/hot/attachments/20130928/715ef1dc/attachment-0001.html>