[Imports] Facebook's AI-Assisted Road Tracing for OSM
Rory McCann
rory at technomancy.org
Wed Mar 22 14:30:37 UTC 2017
Hi Drishtie,
Thanks for replying.
If you don't want to release lots of source code, that's your call, but
then you should show the data that you plan to import, like all the
other imports for OSM.
Some further thoughts:
On 21.03.2017 22:02, osm wrote:
> *Who are your editors?* Our team consists of 3 engineers and 14
> editors, and usernames can be found on the Import wiki. All editors
> have also updated their profile to say they map for Facebook. You can
> see their names on their profile. All our mappers are qualified for
> editing with backgrounds in GIS, geography and are extremely
> technically savvy. We have also spent a considerable amount of time
> over the last 5 months training specifically for OSM.
It's not clear, but I presume those editors are being paid by Facebook.
"training from OSM" and no details about their main OSM account, I
presume the editors are new to OSM?
What connection/knowledge the editors have with/about Thailand? Local
knowledge is important to interpret aerial imagery.
Local community buy in is a *vital* important part of an import or
mechanical edit. Can you tell us what the Thai OSM community thinks of
this import (if you've started that aspect). Has the Thai OSM community
given any tips for mapping Thailand? For interpreting aerial imagery?
Software written by people in San Francisco might presume things that
aren't true in Thailand (or other countries).
> *Can you Publish Source Code for ML* We cannot share the source code
> for Machine Learning at this time
:(
> *Can you Publish Source Code for internal tools?* We are absolutely
> going to share our tooling. We are currently working on creating a
> Github where we will post soon.
Great! :)
> Road masks are processed to remove low confidence predictions and
> add connections between short breaks.
Can you release the software which makes these connections? In your
first sample there's a change which looks like an over-zealous
way-joiner gluing a highway to a landuse area. Or maybe a mistake
from a mapper. By looking at that algorithm/programme, we can find out.
You don't want to upload data which is over-zealously gluing things
together! JOSM validator won't detect this sort of thing (since it's not
always an error).
> Our modified iD tool is equipped with data validation
> functionalities similar to JOSM and osmlint
> https://github.com/osmlab/osmlint/.
I suggest you load your data into JOSM, run the validator and find
"false negatives" to look for mistakes your validator missed. Maybe look
at what Osmose detects too. e.g. in the first sample data, you weren't
detecting for "overlapping highways".
> We have attached a few samples that we are sharing based on the 3
> Phases explained above.
The road geometry looks good, definitely comparable to what a
human would enter. (From looking at the blocky Mapbox Satellite images)
How do you decide the highway tag? You seem to almost randomly choose
between service, unclassified and residential. I can't really see the
logic. Some of the choices seem a little weird.
Why are there are no relations in those files? Does your software skip
them? There are relations in the areas covered. There were relations in
the first sample file. I don't know what would happen if you were to
upload that file in JOSM (or iD). I /presume/ it wouldn't delete the
relation/the relation membership. But...
Whatever is generating these files is a little too trigger happy to mark
objects as "modified" (as I said last time). Do you know what's going on
there? I don't think it'll cause a problem, except generate extra
version numbers. A better solution would be to not mark an object as
modified if you haven't modified it.
Can you release your code for that so we can see where these weirdnesses
is coming from?
Thanks,
Rory
More information about the Imports
mailing list