Hello,
Thank for your feedback. Here are more answers to clarify the questions you have raised. How do you deal with clouds in imagery? Our ML algorithm has been trained on images with no cloud cover only. So, for areas that have cloud cover, our ML model will not output any data. After manually verifying the data with other imagery sources in OpenStreetMap if we still cannot see imagery clearly we will not be adding data for that area and hopefully it can be filled in by Ground truth data. What is the mapping experience of those people in OpenStreetMap? Our editors are indeed Facebook employees. While most of the editors are new to OSM, and therefore do not have personal accounts they were hired because of their strong backgrounds in mapping and are well versed with GIS tools. In addition to the extensive training they have received using OSM tools and understanding the data structure over the last 5 months, they have been creating all the training data which includes many hours of tracing satellite imagery :) Part of our process is studying the structure and tagging across the country we are mapping in this case, Thailand. We have been talking to local community in Thailand and plan to do this more through the talk list as go forward. Using tools like Mapillary we also look at street view imagery to understand the context better. I completely agree that local knowledge is very important when remote tracing. While we do sit in San Francisco, this team is extremely diverse with a deep understanding of local context from countries in South America, Europe, Africa and Asia. We also have access to colleagues across the globe that are happy to share local knowledge and context :) I have also spent the the last two years training people on how to map in OSM at over 130 mapathons in multiple countries as well as lead field mapping in Africa, Asia and South America so I have been able to share a lot of my experience with the team. Where is the full data you plan to import? Since you don't want to share your process to produce the data it is necessary to look at the generated data you plan to import to do a proper evaluation As explained previously, our process is actually AI-assisted human mapping, not really a typical import where all the final data to import is totally ready. At this stage we only have machine generated data (before human validation) at province scale. As you all know in any project you have to balance resources, cost, and more importantly employee time. Preparing human validated .osm files at country scale is both costly and time consuming. Due to the gap in time taken to validate, share and wait for feedback we have decided to create data in small batches by province level. This reduces the possibility for conflicts because we can ensure we are working with current OSM data and validating conflicts quickly and smoothly as we add our generated roads. We can of course generate the human validated version of the previously shared sample .osm files, so that you guys can help verify the quality and share your feedback. Are you using any other data to produce what you want to import other than the DG imagery and existing OSM data? We are using Mapillary for training, ground truth and to verify alignment. We are also using population distribution maps<https://info.internet.org/en/wp-content/uploads/sites/4/2016/07/population_density_final_mj2_ym_tt2113.pdf> created by another team here at Facebook to help us understand where people are. This data<https://code.facebook.com/posts/1676452492623525/connecting-the-world-with-better-maps> was released and has been used by humanitarian organizations to help with planning and decision making. One example of how we use population data is to help us to find residential clusters so we can get as many roads leading to buildings as possible. We also use it to suggest tagging for road types. However, this is still in experimental mode and so we ask our human validators to explicitly cross check each road to ensure the tagging is consistent with OSM region-specific guidelines. Road masks are processed to remove low confidence predictions and add connections between short breaks. This is a great point and we are glad you all raised it. We had the same concern when we thought about how to do this. Firstly let me clarify that we only make automated connections to the ML output as suggested in Phase 1 before our data is merged with current osm data. This only happens for very few cases where we see small gaps, (threshold is less than 2 meters) on major roads. This happens very rarely for the major roads because in cases of tree cover or shadows. Secondly when we validate the merged osm data, we highlight the roads with auto-connections so the mappers pay extra attention to verify that the connection is correct as far as we can see from satellite imagery. So all connections are still verified by our editors. For the last case of “barriers that prevent automobile access” you described, we admit that we can't address that with our process. We can only do as well as remote mappers and need to rely on local community to fix those cases. How do you decide the highway tag? As mentioned part of our process is studying the structure and tagging across the country we are mapping in this case, Thailand. We have been talking to local community in Thailand and plan to do this more through the talk list as we go forward. We have tagged this area mostly based on what we have seen in other remote areas of Thailand. Also, as noted above, we use the population density data to refine our road tags for residential areas. Please note the difference in imagery, so we can see buildings and roads in our DG imagery that are not seen in Bing. We are of course always happy to take feedback on tagging and can change based on community direction. Why are there are no relations in those files? Yes, currently we skip relations as we map in more rural areas. Our enhanced iD currently skips updates/deletion to relations, and we have done a lot of testing against OSM devserver and verified that not including relations in the .osm files will not cause deletion/updates to the relations or their membership. We are aware that when splitting any way that is part of a relation, the new segment may not be part of the relation. Our principle is to have the least amount of changes to existing roads so we don't split existing ways. Our iD also checks for split of existing roads, so editors will not be able to save until checked and resolved. We do make minor modifications when necessary by adding nodes or connections to a way in a relation which shouldn't cause membership issues for the relation. All relations in the area will be checked for integrity after changes, just to make sure nothing broke. What do you mark as modified? We can definitely change this. Currently we only mark objects as modified in the following cases. · When we add new roads. (We could probably not add the tag to all new roads) · When we change pre-existing OSM roads by adding new nodes. · When we connect existing roads to our generated roads. Look forward to your feedback. Best, Drishtie Patel on behalf of the OSM at Facebook Team OSM Profile<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.openstreetmap.org_user_DrishT&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=NlZNy7PJhbzX87SFZnKl7g&m=n5VgVFlDrOENxjwIgtsgoEfSYch5UpHHLNQ7Vyu626I&s=s2Lmw5MrnsH05vk-IKaj7V5j0Of9Cu1UKWT7Ba2pfQE&e=>
_______________________________________________ Imports mailing list [email protected] https://lists.openstreetmap.org/listinfo/imports
