Recently, taking community input into consideration, TomTom refined its approach to identify potential map improvements by making several enhancements listed below:
Re-engineered the logic to generate tasks
Added more details to the MapRoulette challenge descriptions and work instructions
Performed an additional round of task validation
So, with that background, we present to you the following MapRoulette challenges:
This will bring in working with relations. This is quite an advanced topic. To properly solve it you would need to check the history of the multipolygon so see whether some other edits did break it.
You might restrict the challenge to relations in version 1 which are obviously not damaged by later edits. Also pay attention to not consider ones which had been created just (few hours) before the extraction date of the dump you are using, as it might be some unfinished work.
Relations with higher versions might be detected not because it should be a simple area, but because parts of the relations got damaged and should be restored.
I have no statistic on how many of these polygons are broken due to which case. You could try to get some statistics by looking at random 100 findings and deeply analyzing them.
Thank you for your valuable input @stephankn, I will hide the challenge related to Multipolygon to be sure your feedback is well understood by our operations team.
Hello everyone, I’m Iko from Perkumpulan OpenStreetMap Indonesia (POI). I’m not open to new topics because there are already topics about MapRoulette here.
Currently, we’re under sub-contract for Meta (Facebook) to improve the data quality in OSM. We’ll be working in Thailand at MapRoulette with the theme “Line Crossing WaterBody” starting today and continuing for a few days. unfortunately, the challenge is not for the public, but this challenge was generated from this
To ensure we’re on the right track, sometimes we add discussion comments to learn more about the real situation.
please let us know if there is anything we should improve in the future
thank you
Can you maybe share a random sample of 20 reports of that challenge for review?
Most of the issues I saw had been because either the geometry was traces too rough or because people did not split ways to insert bridges or map tunnels.
How will you detect whether a specific violation is a bridge missing or a tunnel for the waterway missing? While for larger waterways you are frequently able to identify bridges from aerial imagery, this is not always possible for smaller ones.
Does this mean that every road crossing a waterway will be a bridge after your edit? This might lead to many cases where water is passed through a larger section of pipe under a road which would be a tunnel then incorrectly be tagged as bridge.
it’s around 1400 tasks in this challenge, but I realize there’re not only highway/building crossing with waterways. but also highways/buildings above water counted in this challenge. Therefore, we left some discussion just to make sure what the object looks like
to solve the warnings/errors in this theme we already have a guideline. in a short guideline like this:
left discussion comment if we need an explanation from previous mappers. For example such as giving or changing ford, changing road classification, changing road segments (because that’s all needed local knowledge)
but If there are Warnings/errors that can be solved only by looking at the imagery, we can change it. For example, there is a crossroad with a waterbody that has no bridge and is “clearly visible” in the imagery, cases like this can be changed immediately. However, if the imagery cannot provide the answers (Ex: the bridge is too narrow) we use Mapilary or Kartaview, if the Street view cannot provide answers too the last option we can do is we will use Fixme + description tag and left discussion comment
One small request from my side: could you please ensure that all changesets are kept as small as possible in terms of geographical area? Ideally, each changeset should cover only the local issue you are resolving.
Right now, some of your changes include multiple fixes across the country in one changeset and it makes it very difficult to visualize changes in OSM history and osmcha.org. e.g.
Thank you @julcnx for bringing this to my attention. I read your suggestion in a discussion comment about it as well, and as a follow-up, we agreed to split our work by country starting two weeks ago. Is it all right?
because dividing by city would be difficult for us because we were working on a random task at MapRoulette and didn’t know the specific city boundaries in Thailand
Correct, I appreciate you made the initial change, and I thought this would be sufficient since there was typically only 1 change per country.
=> As per wiki, please note that the country split guideline is purely based on the factor that country may have different guidelines, while it’s recommended to go for smaller/localized changes:
In the example below (changeset 130236908), you have 3 clear localized changes across the country spread by hundreds of kilometers (near Chiang Rai, Chiang Mai and Bangkok) There is no need to know the exact city or province boundaries, the distance separating the changes would be a sufficient factor here.
The entire bounding box of these 3 changes will be used in search results and history visualization, so someone watching changes in the middle of Thailand (e.g. Phitsanulok) will see your bounding box and will only understand your unrelated changes after loading and analyzing the specific changeset in osmcha, which is very unproductive.
Oh, i get your point. So we can validate a small amount of data in the same area, regardless of the city or province. Perhaps I should discuss it with my team. Thank you for bringing it to us
@ikopanjirukmana I am re-raising this issue since my historical feed in Chiang Mai is full of large boxes like the one below making it impossible to get a proper overview of changes without having to click on each large changeset.
I have no problem with new mappers doing this unintentionally, but you are an organized editing team with most likely remunerated mappers, so I am sure the community would expect higher-quality contributions from organizations like yours.
You may save a little bit of time (and money) by combining multiple changesets together, but please consider you may be wasting others’ time who are also participating in reviewing changes in OpenStreetMap. I am aware that at least Grab, which contributes to clear individual changes, uses tools like osmcha.org to monitor changes in cities of interest.
Hi @cmoffroad, sorry if it’s still quite large, we try to keep it as small as possible. You can check in the changesets that we focused on a short segment and it was spread out not in a contiguous area. And we think (from your picture) it’s still within one province (correct me if I’m wrong) not hundreds of kilometers.
We don’t intend to make it difficult for active mappers in Thailand, and we are very open to feedback and criticism from the local community in each country, and try to change our workflow. I’m also concerned about using OSMCha to check the quality of the data, based on my experience (which you’re welcome to add to), the size of the changeset will be very influential if you want to revert the data but to check the quality of the datas we can know the details of each segment in each changeset outside whether it is a large or small changeset. No need to download one big or small box area. we can choose a segment that feels it is not right to make changes and then choose to open it in JOSM or Id Editor (but I recommend using JOSM) because we can add other validation indicators. Later, only one segment will be downloaded in JOSM, then we just need to download along selected feature (alt+ shift+d) on that segment and fix it.
i suggest for check quality data you can try to use OSM Inspector | Geofabrik Tools or Osmose or keep right!. I’ve tried using it, and it will be very helpful because we can focus on selecting only what we want to fix such as tagging, geometry, areas, coastline, etc.
Thank you for reminding us about this, we will try to fix it. We are also very open to more technical discussions on tagging or anything else you find from what we have done to improve data in Thailand.
@ikopanjirukmana I understand your concerns, and I also wish OSM reviewing tools like osmcha.org could prevent this large box issue.
The data quality tools you brought up are useful for identifying and solving basic problems, but they won’t show who is mapping, what kind of changes are made, and what possible more complex issues can arise from these.
For instance, I can see now from your recent changesets that you are re-aligning and smoothing major highways across the country. This can raise questions like:
what imagery/GPS traces are you using for this process?
have you considered other mappers including other organizations may do the same with different processes, hence resulting in conflicting changes?
@julcnx By clicking on the icon that I captured in Geofabrik, we can get a look at the deep history of a specific issue. we can see who is mapping this feature and the history of changes made by mappers. I usually use this extensive history to identify mappers who frequently make mistakes, examine the history of their changesets, send their discussions, and prevent more complex issues.
We always check previous imagery used by mappers before smoothing so that we know what imagery to use. We check the original imagery when creating these data sets; if the imagery does not have an offset with the data sets, we use it; if it does, we use imagery offset. GPS is not always available in the area where we work, but when it is, we use it for interpretation.
Yes, we considered other mappers; therefore, we always look at history and send discussions when we encounter cases that require additional information.
there is no technical way to check the imagery which was used by mappers in the past.
If some element was created 5 years ago, then you have no way of getting the imagery of that day. Even if you would know the source, eg “Bing”.
Then you just know that the user was using Bing imagery which was there 5 years ago.
All imagery providers are doing regular updates to their data set.
The only public service I am aware of which makes this history available is google earth, which we are not using.
Bing has at least some meta-data which sometimes give a hint about the age of the imagery. For other sources such metadata does not exist.
So you can’t know what the situation was in the past.
And what would be the benefit of knowing? Roads geometry could change. There is construction work ongoing all the time. Or the initial way was not created by the user, but was the product of another change. Many, many possible reasons. For what benefit?
If geometry is not in line with the geometry ON THE GROUND and TODAY, then it justifies a fix.
Things will start to be tricky, if you are sitting thousands of kilometers away in an office and have no clue about the real situation on the ground.
If something is very obviously wrong, then it is fine to fix it. If there are doubts, then it might be better to not touch it to not make it worse.
I am not going to tell you what to map and what not, but IMHO there are problems in the Thailand data set much worse than sharp angels. At least for me it would come with a quite low priority.
What you’re saying makes sense to me. There appear to be limitations to verifying previous mapping imagery, and the benefit of knowing may not always outweigh the effort required to obtain the information. It’s also important to consider the current state of the area being mapped and to be cautious when making changes. Thank you @stephankn for sharing your thoughts on this.
I need your advice.
someone creates a multypolygon relation In every forest or wood. Some are correct, but the majority are not. this pattern of work was repeated Between 2013 and 2015,
For example, in the picture below, they creates a relation in the yellow box, but not in the green box. After looking closer, I see no landuse or object inside natural wood in the yellow box, so I believe it is inappropriate to assign a relation to that. Is it okay if I remove the relation in yellow box?
it appears invalid multipolygon relations, references:
these forest polygons were added many years ago when Bing was the only available imagery.
rural and village farming extends every year into forest boundaries making it hard to maintain.
Relations are the recommended way to map forest boundaries because they often contain gaps (farmlands, villages) that need to be rendered with an inner role. However, it’s ok to not use a relation on small forest bounds that contain no visible gaps.
My general suggestions when dealing with forest polygons:
it’s ok to delete part or entire forest boundaries if they do not reflect anymore the latest imagery
it’s better to have rough boundaries than very accurate ones since landscapes may change every year
review potential issues with Geofabrik OSM Inspector (section Areas)
Important things to watch to avoid breaking forest rendering (a very common issue)
use the appropriate inner vs outer role inside relations
never overlap/touch boundaries from different inner/outer objects
ensure inner/outer roles are applied to the correct relation and not an adjacent one
I agree that these huge relations are hard to maintain and are quite fragile, so frequently broken.
I try to remember what the rationale was to have them. I think it all boils down to rendering orders. If you have a “hole” in the forest, then it is hard to have that rendered accordingly. So adding it as inner polygon enabled this.
As mentioned above: If these areas are just areas by themselves, then there is no requirement to have a relation around them. Make sure individual areas have the right tagging and remove the relation.
For double-checking: It might also be that the inner relation representing the “hole” got lost. So you might want to check whether there are some left around.
I refrained from these discussions a bit, as there are multiple conflicting opinions on the tagging, at least it was in the past.
It all is around: Is the road passing through the forest part of the forest or not? If the road is not, how about a hiking path? A lake in the forest, is it part of it, or not? Marking it as “inner” declares it to be not part of forest, but resulted in a correct rendering order.
i hope that this is meanwhile all resolved, but I have never checked this aspect in detail.
