Thank you again for all of this feedback. We joined this forum to work with you directly and support high-quality data with your expertise. We are always willing to share and answer any questions you have. My sole focus at Facebook is on OSM, so you will reach me and my team directly if you talk to us through these discussion posts or email us at osm@fb.com (please email if you need a quicker response). Our goal is your goal: to efficiently and accurately create maps powered by our community.
We look forward to continuing to share our derived data so the community can work together to create high-quality maps. We will be sharing sample data with the community next week via the import list. Following that, we’ll share the area we hope to start mapping in Thailand through this forum.
We are currently using the HOT Tasking Manager and iD tool and are working to share our editions/changes to these tools as well. Stay tuned.
Thanks to Kevin for clarifying the intentions and philosophy of DigitalGlobe. We are indebted to the people who produce the satellite imagery we use every day and without which we would be lost.
Drish, I wonder if the iD editor is the best one to use for this project. I am not all that familiar with it but the few times I have used it, I found it very limiting. The learning curve is steeper but I think using JOSM will save time and prevent problems in the end. It is very customizable. One can create and use “presets” for example, that make data entry more uniform. In an effort like yours, where many people are adding similar data, you don’t want some of them to tag an object one way while some others choose a different tagging scheme. Also, tagging an object with a preset requires only a couple of keystrokes no matter how many tags are involved.
It’s your project and your decision might need to weigh other important factors. Many of the most prolific contributors to OSM use Potlatch or iD so you are in fine company in that regard. Still, I feel that you might as well be using the most powerful and flexible OSM editor available and that is, unquestionably, JOSM.
Another feature of JOSM is the inbuild validator which can detect common mistakes, like crossing ways, not connected way, bad tagging, etc. The Find and To-do plugin can help find and fix errors like this. In computer generated imports like this, you want to be able to automatically detect and fix problems to ensure a high quality of data.
The White Spots on the map of Thailand are still enormously big. Last December in Isaan, I was in places with nothing at all mapped within 10 km from my location. And let’s take a look at the contributors to the map of Thailand: most data were contributed by farangs.
We need some organisations helping us to complete some tasks. Roads, rivers, landuse can be seen on images. Place names, road numbers, shops, hotels, etc. can’t be detected there: we need people on site who will do that. And I hope they’ll more likely be willing to contribute when they see that the map is good (which it isn’t - also Google maps actually isn’t good as it does not differentiate between roads and tracks).
Although the examples shown by Stephan and Dave are very terrible, let’s try to integrate the FB team into the OSM community. With a slower approach, they could get feedback on small change sets, without causing too much disturbances with bad data. Also try to map connected items instead of singular segments. As I see from Dave’s comment, it could be helpful if the FB team tried to work in places where good and recent imagery is available also to us (instead of only to them).
Thank you for the advice on tooling. As mentioned in our wiki page we do use both JOSM and iD. We totally agree that JOSM is superior for what we are trying to do and are all familiar with both tools. In fact, we started primarily with JOSM for the exact reasons you mentioned In order to create a better internal process, our engineers have made changes to the iD editor to mirror the cool features JOSM has.
For example here are a few changes we have made to iD that help us be more efficient.
The ability to load/save locally generated .osm files much smoother and faster.
Customizing colors and highlighting specific point, lines or polygons. For example, we highlight roads so editors can quickly tell the difference between our edits versus what is currently in OSM.
Added conflict validation to iD so edits cannot be saved unless all conflicts are resolved.
Batch tagging for multiple selected roads
Automated suggestion for road connections. So we can easily connect roads in neighbouring tiles when working in the bounding box of a task from the tasking manager.
We are happy to share these and are working on ways to do this in a thoughtful way.
These sound great and make powerful editing features that were only available in JOSM more accessible to mappers. Looking forward to a publicly usable fork.
Again FB shows that they are not interested in cooperation with the community. Instead of presenting their ideas and working together with the community on improving the tooling they speak about creating their own toys and a fork.
Besides that:
When will the existing mess be cleaned up? Does Facebook expect the community to clean up after them?
I’m tempted to immediately revert uploads done by RVR007 and others. Removal of rice-field tracks are no big loss.
Given that it’s likely that most of these errors were introduced by Facebook, it would be good to see a response by e.g. Drishtie about this here.
Further up this thread I said:
and that still stands. There are a number of tools around that can “revert everything that hasn’t been since touched by another mapper (e.g. to correct it)”. In this case it’s not quite as straightforward as it might be because non-import accounts used for other mapping activities have been used for the import.
Although I’d be normally very happy for a person who made a buggy import to revert it themselves, given the lack of technical competence demonstrated by Facebook so far I’d personally be somewhat concerned if they did the revert on their own without anyone else checking it. If Drishtie or someone else at Facebook wants to do the revert, then it’s best that they say so here before doing so. If someone from this forum wants to do it, great - but probably best to say so here first to avoid duplication. If not, the DWG can clean up the data (which as I understand it was all imported by mistake), and if I do it I’ll say so here first.
@Stephan I’d also be interested in seeing where you came up with those numbers.
From what I can tell from OSM Inspector, Thailand has barely any issues with duplicate ways (only about 10 ways have issues out of the entire country - in my opinion that’s pretty darn good!). https://tools.geofabrik.de/osmi/
Out of those 10 ways that have issues only 1 of them is from Facebook and another is from yourself @stephank, you don’t validate before pushing your edits? http://www.openstreetmap.org/way/474870936
Stephane, next time you try to use a fancy outdated graph to threaten a revert, please try to actually look at the OSM data before you speak.
@Denis: way 474870936 was one of the tagging fixes for Balthus. It fixes only tags. If there had been duplicates before they had not been touched by this. Was not the scope of fixing the tags.
Don’t try to blame pokemon users. These mentioned changes all have “#nsroadimport#thailand” listed in the comment. This clearly points towards Facebook.
Again: It is Facebook doing imports. So it’s Facebook to prove they are executing this in a technically correct way. We have enough examples indicating this is not the case!
And don’t try to switch topic. Yes, there are other bad edits in the database. But here we are discussion about those caused by Facebook.
Thank you for your feedback. Based on our analysis, we found that out of the 5919 duplicate geometries shown in the Osmose tool, Facebook mappers added 35. We appreciate your time in helping us flag this issue. We have taken steps to correct this in our workflow to ensure that we prevent this in the future.
As noted on our wiki, these are our mappers with links to their profiles and names. All of our edits go through one of these accounts.
During the initial tidy-up there were people using other accounts for changesets with “#nsroadimport#thailand” tags but I guess that this was just accidental in the hurry to fix the data.
With regard to the “new mappers” behind e.g. https://www.openstreetmap.org/way/472343677/history and https://www.openstreetmap.org/way/472279193/history , it just looks like a common-or-garden geography class project to me. It ticks all the usual boxes - uploads only buildings, first time users using JOSM, very few changesets each, all changesets done within a few days (i.e. when they move on to the next part of their geography course).
Maybe someone in this forum knows a geography class somewhere who it might be, maybe not. It can be useful to find out as these classes tend to run periodically with new students each time.
Thanks for providing the list of user accounts used for your edits. I changed your wiki page so that a search for the username actually finds it. I missed it because the search did not catch it due to the name not mentioned.
So you are saying that Facebook is not involved in the recent addition of over 20.000 building footprints in the south of Thailand, right? It simply matched from a timeline and geographical point of view the areas you said you are working on.
But ok, let’s assume it is a different party. In that case the source of the duplicates are indeed not related you your edits. They come from these building footprints which uploads duplicate geometry and also point different outlines on top of each others. https://www.openstreetmap.org/#map=19/7.68799/100.37925
As Andy asked already: Does anyone knows details about who is responsible to setting up tasks for mappers to draw building outlines on a large scale?
Stephan, I can confirm that Facebook was not involved in the recent addition of over 20.000 building footprints in the south of Thailand. We are only working on roads.
In order to create a better internal process, our engineers have made changes to the iD editor to mirror the cool features JOSM has.