Hi all<div><br></div><div>I thought I'd bounce this topic off the talk-AU list before waking up the slumbering millions on talk :)</div><div><br></div><div>Without giving too much away, I'm letting you know that NearMap are looking at/working on adding support for some basic OSM editing operations to our website. We're doing this to more directly address some of the weaknesses of OSM; in particular, absence of street names and building numbers. I'd be interested in your opinions on what we're doing: as ever, our aim here is to improve and support the OSM data :)</div>
<div><br></div><div>We are not building a replacement for Potlatch/JOSM - those tools are way too complex for a generalist audience and anyone who wants to do more in-depth mapping work will be encouraged to sign up at the OSM site and use the tools available. Our first release will support just those tasks mentioned above, using as simple a UI as we can build; add or correct a street name, and add or correct a house number (or a set of them).</div>
<div><br></div><div>Adding this support is a reasonably non-trivial task, since right now the OSM data is used to drive a rendering process chain that generates the street map tiles (you might be interested to know that we render many of these on demand, in real-time). That uses a "lossy" import of the OSM data, since until recently all that we needed to have was enough data for rendering. We're now working on an import that preserves enough contextual information to support edits; key attributes being osm_id (and yes, we've been following John's suggestions about UUIDs with interest). Right now, our strategy is to relay edits back to the OSM servers in near-real-time, so that we can verify the most recent state of an OSM entity and confirm the changelist and version numbers for our edits.</div>
<div><br></div><div>Now, we're aiming to make the process of adding/fixing up OSM data as easy as possible: in this case, that includes not requiring that an editing user have an OSM registration (since the process of signing up for one is sufficiently out of our control to make it difficult to integrate well into the NearMap site). We do have our own registration system, and we're going to require that a user be registered with us before we allow them to make edits.</div>
<div><br></div><div>Because of the above, edits applied to the OSM data would be submitted by a "nearmap" user. We're planning to tag edited OSM entities with information sufficient to identify the NearMap user who made the edit. We'll also be tracking the history of edits by users in our core database.</div>
<div><br></div><div>A key question is the best way that we can handle vandalism (the all-too-common downside of widening the user base). In the event that bad edits are reported or noticed we can, in theory, revert some or all the changes made by that user, but it's currently unclear how possible that becomes once those edits are established (and hence possibly used as the basis for subsequent edits). This is one reason we're only enabling specific, simple edits to start with; these are more easily reversible in ways other than just "reverse the changelist".</div>
<div><br></div><div>Comments welcome :)</div><div><br></div><div>Cheers</div><div>Ben</div><div><br>-- <br>Ben Last<br>Development Manager (HyperWeb)<br>NearMap Pty Ltd<br><br>
</div>