[Imports] Facebook's AI-Assisted Road Tracing for OSM

[Johan C]

2017-03-17 14:28 GMT+01:00 Rory McCann <rory at technomancy.org>:

> Hi,
>
> Yes, we must treat Facebook the same as all others. We ask importers to
> show all the data. FB have shown part of the data. If they want to import
> lots of data for Thailand, then they could show all of that data for review.
>
> The Automated Edits & Imports guidelines do call for documentation of the
> algorithms/source code. I think there are ~3 processing steps. The computer
> vision code, the custom iD editor (w/ validator), and (maybe) some server
> side processing/"internal processes". Many places bugs could creep in. With
> many eyes, we can find bugs and possibly help make it better.
>
> From my reading, you should show the data or the code. Yes, we don't ask
> for ArcGIS to be open source, but in that case one provides the data.
>
>
>>
>
For some unknown reason a nice example of the demand for an algorithm on
http://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_conduct
disappeared on 31st May 2015. So I think it's still valid:

* i.e. it is not enough to write "fix misspelled tags" but you will have to
provide a full explanation on how exactly you are fixing what

You write that the import guidelines calls for documentation of the
algorithms/source code. You possibly refer to Step 4, part 2, which is near
similar to providing a full explanation on how exactly you are fixing what:

* You *must* write a plan for your import in the OSM wiki. Create a wiki
page outlining the details of your plan. This plan must include information
such as plans for how to convert the data to OSM XML
<http://wiki.openstreetmap.org/wiki/OSM_XML>, dividing up the work, how to
handle conflation <http://wiki.openstreetmap.org/wiki/Conflation>, how to
map GIS attributes to OSM tags <http://wiki.openstreetmap.org/wiki/Tags>,
how to potentially simplify any data, how you plan to divide up the work,
revert plans, changeset size policies, and plans for quality assurance
<http://wiki.openstreetmap.org/wiki/Quality_assurance>. An example for this
can be found at Import/Plan Outline
<http://wiki.openstreetmap.org/wiki/Import/Plan_Outline>


It seems that that is all 'we' require on algorithms/source code. And it's
logical. Nobody wants a Tiger import again. The datasets to be imported
have to be reliable, the ingration into OSM should add value and not
problems. There isn't a single requirement to know in full detail how the
datasets to be imported *got* reliable. What is important that a claim for
reliability can be checked. And that's exactly what the on-the-ground
principle is for. FB can easily perform a test import on an area to be
checked by mappers. Ideally, local mappers. If the reliability and the
integration is okay, than it's okay. As long as FB complies with Step 4,
part 2 (and of course the other steps), it's not necessary to open source
the algorithm. It might be closed source, which is fine. I would be more
interested to know whether community buy-in is okay. I haven't seen a
response from the Thai community on this posting. I think they should be
responding in this discussion before any import.


*Why did you choose Thailand?* Facebook has a high number of users in this
country and we would like to improve that map for this community. It is
also our mission as a company is to make the world more open and connected
and one way we can do is by filling in the missing gaps on the map. We also
saw a strong OSM community that we could learn from and engage with while
we refine our process for mapping. We are hoping for community feedback as
we move forward so we can contribute high quality edits.


Cheers, Johan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/imports/attachments/20170317/9247395e/attachment.html>