Mapping and improving map data in cities of Thailand

[GRABOSM]

Objective: Grab team is going through the existing road geometries in the mentioned cities and will work on making improvements. We'll be reviewing and mapping the following features: missing roads, road classification, and check for intersection configurations and alignment accuracy.

Christophe95 , CC BY-SA 4.0, wikimedia commons

Regions we are reviewing/mapping: Starting with the following city [cities]:

• Bangkok, TH
• Ayutthaya
• Chachoengsao
• Samui
• Nakhon Nayok
• Chumphon
• Chaiyaphum
• Chiang Mai
• Kalasin
• Phitsanulok
• Ubon Ratchathani
• Hat Yai
• Udon Thani
• Krabi
• Hua Hin
• Trang
• Chonburi
• Chiangrai
• Buri Ram
• Lampang
• Surat Thani
• Chanthaburi
• Surin
• Tak
• Lamphun
• Yala
• Uttaradit
• Pattaya
• Phetchaburi
• Maha Sarakham
• Rayong
• Nakhon Phanom
• Ratchaburi
• Nakhon Pathom
• Nakhon Ratchasima
• Nakhon Sawan
• Nakhon Si Thammarat
• Phayao
• Nong Khai
• Kanchanaburi
• Roi Et
• Phuket
• Phrae
• Prachinburi
• Loei
• Pattani
• Phichit

Workflow: We'll be following the same workflow as mentioned in our wiki - https://github.com/GRABOSM/Grab-Data/blob/master/Data%20Improvement%20Projects and https://wiki.openstreetmap.org/wiki/Grab#Process_Flow

Validation: We'll be following the validation guidelines mentioned in our wiki: https://wiki.openstreetmap.org/wiki/Grab#Quality_Process

Changeset Comment: Mapping and improving road attributes: https://github.com/GRABOSM/Grab-Data/issues/49 #grabosm

Source: MAXAR -- we would refer to others if need be.

Filter: None

Plugins: None

Edge cases: None at the moment, we'll post it as a subsequent comment if need be.

Team involved: The Grab Data team

OSM Forum Link: https://forum.openstreetmap.org/viewtopic.php?id=70525

Do reach out to us if you have any questions or suggestions on the same. Happy Mapping!

cc: @jinalfoflia @poornibadrinath

[mishari]

Are you using any hash tag for this effort which we can use to follow your progress on osmcha?

[GRABOSM]

Are you using any hash tag for this effort which we can use to follow your progress on osmcha?

@mishari we aren't using a hashtag as such but we do have a common changeset comment that will enable us you to get all the edits on OSMCha - Mapping and improving road attributes: https://github.com/GRABOSM/Grab-Data/issues/49

---

While reviewing and verifying map data in Bangkok we came across some edits and sharing the questions or doubts related to the same. We are forwarding the concerns here so we can discuss and reach a consensus on how to approach these cases and do we need editing here or not. Please do let us know what you think and how best we can improve the data around these data points. Below are some of the questions:

Case 1: Wrong classification Way id: 175552847

In this case, the road classification of the highlighted road has been changed from service to residential, but by the looks of it from the satellite imagery and the surrounding areas, this building is a commercial complex which means the highway needs to be service, due to which there is now a classification gap. Any particular reason why this was changed to residential, and could we change it back to service to keep it in lieu with the current on-ground scenario?

Case 2: Wrong classification Way id: 158636233; 158636235; 707451397; 808257173 This area looks residential but the highways highlighted are tagged as service. According to the road classification policy of OSM, the roads within a residential area have to be residential and service roads are for commercial areas. Is this okay to be changed to residential or is there any particular reason why this is retained as service. Understanding this would help us update our mapping policies and make sure our team is aware of this as well.

Case 3: Unconnected roads Way id: https://www.openstreetmap.org/way/348357841

As per the imagery (Maxar), we can clearly see another entrance into the parking lot here. But that road has not connected on the map. We are adding the road to the map as we have OSC imagery that helps us identify the road and gate but it's not clear enough for us to understand if this is one-way or not. Could someone please help up update this information? Here's the link to the imagery - https://openstreetcam.org/details/1525725/23/track-info

Case 4: Duplicated highways Way id: https://www.openstreetmap.org/way/178872835; https://www.openstreetmap.org/way/658015527

In this case, we can see the highways highlighted are duplicate ways. While one of them is associated with a route relation, the other one is not associated with any relations, however, both the highways do have a number of tags. We do want to remove the duplicated highway but not mess the route relation.

We think it would be good to copy the tags from the highway not associated with the relation to the highway which is a part of the relation and remove the duplicated highway. If there is any other approach, please do let us know.

Case 5: Unverified access tag Way id: https://www.openstreetmap.org/way/58964583; https://www.openstreetmap.org/way/98438563; https://www.openstreetmap.org/way/156672762 The ways highlighted have the tags access=no added in 2016, however, the current imagery lets us know it might be a temporary restriction. Please do confirm whether it is a permanent restriction or not and if there is any particular approach in which we can map/verify the tags on these roads.

Case 6: Confusing classification Way id: https://www.openstreetmap.org/way/152836835; https://www.openstreetmap.org/way/220686747; https://www.openstreetmap.org/way/230328212 The ways highlighted, their classification recently was changed to residential. We have retained the existing classification, however we do need some clarity on understanding the change as the neighbourhood seems to be a commercial one. If there's a specific reason to it, we'd want to reflect the same in our policy.

Case 7: Unverified access tag Way id: https://www.openstreetmap.org/way/70565695; https://www.openstreetmap.org/way/705656956; https://www.openstreetmap.org/way/705656958 There are multiple overlapping ways and the tags of the main highways with the links are not consistent. The way to resolve these is to remove the duplicated highways and reclassify the roads according to the OSM norms. If there is any better way to understand and approach these, please do suggest.

Case 8: Wrong classification Way id: https://www.openstreetmap.org/way/156231356; https://www.openstreetmap.org/way/650912392 The highlighted part has been tagged as tertiary road while the entire stretch of road has another classification. It would be good to minimise the classification gap by either changing the entire road to tertiary or residential, based on the ground scenario. If there is any other tag that will fill better for the road than these two, please do suggest.

Case 9: Dual carriageways Way id: https://www.openstreetmap.org/way/147608607

There is a solid painted median in the middle, which means the traffic will follow the rules of dual carriageways., by adhering to not shift lanes past the double lines and treat that as close to physical barriers. Is there any country-specific policy that we can refer to, to change this bidirectional road into dual carriageways.

Also, the classification seems confusing as well. This looks like a major road but is mapped as 'unclassified', a suggestion would be to modify it as tertiary as the connecting highways are secondary on either side at node 1094103217, node 1608093732. If there is an alternative, please do suggest.

We will be sharing the questions, issues and our possible suggestions as we map and review the data, it would be great to have your local mapping experience to clarify this and lead to a better map.

[mishari]

Thank you, this is starting to give me confidence in what you're doing.

I would like to propose the following:

1. Split these up into individual issues and mention it here, for example, #40 and we will discuss and close one issue at a time.
2. When you specify the way, please do it with with way ids linking URLs i.e., way 175552847

Could you please split the above up like this?

[GRABOSM]

Thank you for the feedback @mishari.

Split these up into individual issues and mention it here, for example, #40 and we will discuss and close one issue at a time.

This is a great idea, we are working on raising the tickets for each of the cases mentioned above. These can be filtered by using the tag - Community Review

When you specify the way, please do it with way ids linking URLs i.e., way 175552847

👍

[mishari]

I've gone through the issues and made comments. Great work so far.

[GRABOSM]

@mishari, thank you so much for the feedback :)

[Paul012]

I've come across a few quality issues which need to be addressed. Here are some examples from changeset 90897318 by t_ramya:

Before:

After:

1,3&4: I've noticed a trend where Grab editors try to make curved corners where the actual streets are sharp right angles. (1) here is an extreme example: Instead of two right angles (which was previously accurately mapped), you unnecessarily changed them to a snaking S shape which doesn't reflect reality. I've also seen this in edits by harsh_19 such as changeset 91083483, where some street corners were curved and cut into people's houses.

2: What's up with modifying streets like this, which were previously properly mapped as straight parallel lines, and leaving kinked angles instead?

4&5: It seems you're filtering the data to work on just the streets, but please also check that you're not making edits that cause streets to cross through walls or into buildings, especially like here where things were previously fine.

4&5&6: This is clearly the result of trying to re-align objects to imagery without properly accounting for the offset, causing misalignment. You appear to be working mainly on Maxar imagery. Though it's usually the most updated, the current Maxar layers are considerably misaligned in some areas of Bangkok, with offset of up to 10 metres. As such, the edits introduced widespread inaccuracies to the position of the streets. Remember to always check alignment of imagery with GPS traces, and if everything currently mapped doesn't match the imagery, double and triple check before making such widespread changes.

[Paul012]

In changeset 92548212, the edits seem to indicate that mani_v was adjusting the position of the elevated expressway without accounting for parallax errors (in addition to not accounting for image offset). Parallax is a very basic principle which everyone engaged in imagery-based mapping should be familiar with.

[Paul012]

Going through areas around northern Bangkok, I'm seeing more and more problematic edits by t_ramya, e.g. 91030853, which messed up all the streets in Kasetsart University. A thorough review of these edits seems to be in order.

I had hoped that I wouldn't need to say this, but this is an example of sloppy work that simply cannot be accepted.

[GRABOSM]

Hello Paul, Thank you for letting us know of the issues and also resolving them. We have also made changes accordingly. We have been referring to Maxar in most of the places and sometimes due to major misalignment, we lookout for GPX traces and change the offset to align the data to the imagery.

Sometimes it's a miss as a lot of places do not have GPS traces coverage.

Do let us know what might be the good sources for us to use for the mapping and feel free to suggest any changes to the existing workflow and we will make sure that the team is aware and incorporate the policies into their mapping practices. We have acknowledged your comments on the changesets and made the necessary changes to all of them. Do let us know if there is anything else required from our end. Thank you!

cc: @Paul012 @mishari @jinalfoflia @poornibadrinath

[GRABOSM]

1,3&4: I've noticed a trend where Grab editors try to make curved corners where the actual streets are sharp right angles. (1) here is an extreme example: Instead of two right angles (which was previously accurately mapped), you unnecessarily changed them to a snaking S shape which doesn't reflect reality. I've also seen this in edits by harsh_19 such as changeset 91083483, where some street corners were curved and cut into people's houses.

Hello Paul, Thank you for letting us know of the issues and also resolving them. Concerning the above-highlighted comment, there is a reason as to why we generally curve the roads, it is to make the roads appear smoother and turns to not look sharp. This has been a common practice with a lot of community mappers as well. We agree that the cutting of the roads into houses and buildings are wrong, and we will make sure the mappers will follow that.

However, is there a reason as to why the general curving of the roads are not preferred? We would like to understand if there is any specific mapping policy regards new road creation and road editing that we can add back into our policy as well. Please do let us know the preferred way of mapping. Thank you!

cc: @Paul012

[Paul012]

Regarding sources for GPS traces, if there's a company that has access to plenty of such information I imagine it would be Grab. Have you checked whether it would be possible for your team to acquire permission and access for its use?

Regarding curved corners, my opinion is that they become a problem when they misrepresent reality. If a road is straight I would want it to be straight on the map instead of bent to accommodate such curves. If I'm using the map data for navigation I wouldn't want to be given instructions to follow curves when in reality I'm making sharp right corners, which would surely be confusing.

[stephankn]

@GRABOSM there is no "community adoption" of curving roads where there isn't. A sharp turn is a sharp turn. There are many cases where the Facebook KI did this. This is a good example of why algorithms should not map. If such a road was later touched by a mapper (even for other reasons, like tagging or adding further nodes), it will show a different name as last editor. Still the original problem was created by Facebook. It might also be that some inexperienced mappers start following the bad style presented by that KI. Still it is not at all common practice. As your team is doing a much larger volumes of edits than the average sporadic mapper we expect a significantly higher level of quality from you.

[mishari]

@GRABOSM please make note of this as there are more cases discovered: https://forum.openstreetmap.org/viewtopic.php?pid=824023#p824023

There are other ways such as https://www.openstreetmap.org/way/628709410 which needs to be rectified.

Could your team do a sweep and look through these and other similar cases? cc @jinalfoflia @poornibadrinath

[GRABOSM]

@mishari, thank you for flagging these changes to us. We have checked the edits and rectified the errors where necessary. Although, we do have some clarifications.

https://forum.openstreetmap.org/viewtopic.php?pid=824023#p824023

Regarding this issue, certain places where the roads are curved are wrong and the cleanup edits are being made to fix them. However, we do follow the curving of the roads as it is cleaner and smoother and doesn’t appear jagged on the map.

This was one of the best practices of mapping from OSM policies. It would be great to understand whether the TH community doesn’t prefer curving of the roads at all? Or is it okay to smoothen the roads that are not perfectly sharp? Any particular policy on this would help us let the regional mapping teams know and also incorporate it into our policies

There are other ways such as https://www.openstreetmap.org/way/628709410 which needs to be rectified.

This has now been fixed, thank you for bringing this changeset to our notice. We do want one clarification on which imagery can we depend on here. This edit was done two years ago, seemingly the roads were added according to the imagery. However, looking at the latest imagery, they do not match.

It would be great if you could confirm which imagery is preferred by the community so we can use them and switch accordingly to make sure our edits are according to the latest imagery without having to set an offset or do any other edit.

cc: @Paul012 @jinalfoflia @poornibadrinath

[cmoffroad]

Referring to this OSM change: https://www.openstreetmap.org/way/901847039 and many similar.

Background: Many outdoor applications assume the surface is dirt or unpaved when highway=track and use this for rendering purposes. On the other way, to be rendered properly surface tag must be provided for general roads (e.g. highway=residential) that are not paved.

Problem: The way above (and it seems many others at least in San Sai, Chiang Mai) was changed recently from Unmaintained Track Road to Residential. In the process, the surface information was not added (surface=unpaved) so there is no way to know anymore if the way is paved or not, and many applications relying on these attributes will show those roads wrongly as paved.

Solution: how can this be prevented further? I am happy to add surface=unpaved manually to new added ways in the future but they are thousands of existing roads marked with the only tag highway=track

[stephankn]

highway=track describes the purpose of the highway, not the surface.

https://wiki.openstreetmap.org/wiki/Tag:highway%3Dtrack "This tag represents roads for mostly agricultural use, forest tracks etc.; often unpaved (unsealed)"

If the highway in question is no agricultural track but an unpaved residential, then the change was fully justified, as it is simply no agricultural track.

In case something was tagged as "track" before this might hint that the initial mapper actually wanted to describe the road surface. Fixing this initial mapping could include adding surface=unpaved if all speaks for a still unpaved road.

[cmoffroad]

@stephankn these OSM rules make sense but they were clearly rarely respected. Why? OSM editors do not provide a clear recommendation to fill in the surface. This problem would be easily avoided if the surface was a mandatory tag like highway and automatically filled with a suggestion when switching feature type.

In Chiang Mai province alone, they are 13190 ways with highway=track of which roughly 70% (9155 ways) do not have any surface specified. For Chiang Rai province it's 75%, and Mae Hong Son 80%. And I doubt this a Thailand-specific quality issue ( source: http://overpass-turbo.eu/ ). PS: The same issue can be found, though in smaller numbers, with highway=path|footpath.

I am aware all of those tracks locally minus maybe a few exceptions are unpaved (dirt mostly) as contributors have marked the few rare paved agriculture/forestry roads with highway=services. There are obviously too many of them to be changed manually, so what is the solution to prevent the issue I raised above with past and future edits including those from GrabOSM?

Should I write a program that adds surface=unpaved to all highway=track with no surface specified?

[stephankn]

@intuiquest please DO NOT do a mechanical edit.

OpenStreetMap does not work as you expect. There is no "mandatory catalog" of what to map. There is nothing like the Navteq Street Data Reference Manual you might have in mind.

All mappers are free of what they map and into what detail level they map. The majority of highway=track was added as part of a highly controversial import made by Facebook. This import did not base on survey on the ground.

So for the majority of highway=track (or residential) the exact surface on the ground is not known. You have to rely on assumptions of what the surface could be. For residential as well as for tracks.

In Thailand it is very likely (likely, not certain) that agricultural tracks are unpaved. Still we do not want to have automated edits to add tags. If you had been on the ground, adding the tags helps to be certain. Even within larger cities like Chiang Mai you will find unpaved residentials. (See http://overpass-turbo.eu/s/16if). In any case, assuming a surface from another tag is always this: An assumption. You have to live with it being wrong sometimes.

As this discussion is about edits by Grab: @GRABOSM can you please check the surface on the ground and add the relevant tags? Especially when converting a highway=track into a highway=residential, it would help to rule out uncertainties.

[GRABOSM]

@stephankn @intuiquest thank you for sharing your points and perspectives. Our team has looked into your suggestions and we are reviewing the roads that we have changed classification and if there's no surface tag present, then the team will add one if needed i.e. if the surface of the road from the satellite imagery seems to be unpaved. We shall retain any previously added surface tags as is and make changes accordingly. Here's the link to the Maproulette challenge: https://maproulette.org/browse/challenges/17918 please do join us if you like to. Happy Mapping!

[mishari]

@mishari, thank you for flagging these changes to us. We have checked the edits and rectified the errors where necessary. Although, we do have some clarifications.

https://forum.openstreetmap.org/viewtopic.php?pid=824023#p824023

Regarding this issue, certain places where the roads are curved are wrong and the cleanup edits are being made to fix them. However, we do follow the curving of the roads as it is cleaner and smoother and doesn’t appear jagged on the map.

This was one of the best practices of mapping from OSM policies. It would be great to understand whether the TH community doesn’t prefer curving of the roads at all? Or is it okay to smoothen the roads that are not perfectly sharp? Any particular policy on this would help us let the regional mapping teams know and also incorporate it into our policies

Could you show which policy you're referring to?

I don't think it's the curve in the corners which are the problem, but more so the entire road that looks curved because they're not parallel as they should be, as well as L shape ending to a straight road.

There are other ways such as https://www.openstreetmap.org/way/628709410 which needs to be rectified.

This has now been fixed, thank you for bringing this changeset to our notice. We do want one clarification on which imagery can we depend on here. This edit was done two years ago, seemingly the roads were added according to the imagery. However, looking at the latest imagery, they do not match.

It would be great if you could confirm which imagery is preferred by the community so we can use them and switch accordingly to make sure our edits are according to the latest imagery without having to set an offset or do any other edit.

cc: @Paul012 @jinalfoflia @poornibadrinath

I think that the answer is basically: latest imagery :-( sorry, there's no correct answer here for you. For offset, if there's no GPS, you can query an area to see who are some of the more established mappers and use their offsets as a guide.

[cmoffroad]

Among roads added by @GRABOSM, I am finding many of them, some a few km long, marked as residential while clearly on satellite view there is only a small residential area at the beginning or often there is even none. The map looks strange as you can find long residential roads popping up deep into farming/mountain areas.

My understanding was that only a residential area (high density of houses) could justify a highway=residential segment, some sparse houses along a few km of farms would not justify this, hence the road should be split into at least 2 segments. On the other hand, a road linking 2 villages should be marked as unclassified from beginning to end.

@stephankn @mishari could you please kindly clarify this?

Random samples found while mapping within a small area: https://www.openstreetmap.org/way/839618836 https://www.openstreetmap.org/way/964820115 https://www.openstreetmap.org/way/964499402 https://www.openstreetmap.org/way/227188534

[cmoffroad]

Some of my changes from yesterday got tagged as bad and reverted by a @GRABOSM team member... https://osmcha.org/changesets/108199956/

In the occurrence, I marked a road servicing a temple from track to service and added a new road leading to another temple as service. Both were reverted to track.

Most road servicing temples in Northern Thailand are marked as service, and tracks are used primarily for farming and forestry. What I am missing here??

[cmoffroad]

@GRABOSM Could you please kindly share any internal guidelines you have provided to your mappers? I am interested specifically in any recommendations you may have given regarding minor roads classification.

I personally see a lot of recent changesets with poor quality and inconsistencies:

• source tag is missing. This helps other mappers understand the context of your contributions.
• missing road segmentation. Kilometers long minor roads are marked as residential while only the first 100 meter is within a residential area.
• agricultural tracks marked as residential (a farm hut is not a permanent residence)
• ...

There are currently no country-specific guidelines for minor road classification, and I understand they may be different interpretations. My goal however is to come up with a proper set of rules and recommendations to improve the overall map quality specifically in rural areas.

[cmoffroad]

It would be great if you could confirm which imagery is preferred by the community so we can use them and switch accordingly to make sure our edits are according to the latest imagery without having to set an offset or do any other edit.

@GRABOSM I would personally recommend avoiding Bing and use more recent imagery like Maxar or ESRI. I do a lot of imagery surveys and I found out that at least for northern Thailand, Bing imagery is very outdated. I often run into conflicting Bing additions, here is a clear example: https://www.openstreetmap.org/edit?way=927059104#map=19/18.92189/99.03998

I did a little research and found a Microsoft API that tells the approximate date of Bing imagery for a specific location. From my tests, most imagery date back from 2017, here is the metadata for Chiang Mai city center:

https://dev.virtualearth.net/REST/V1/Imagery/Metadata/Aerial/18.7871861,98.9849548?zl=15&o=xml&key=Am_Iln3EWEST1KZcA-S-glStVM8wMMoHDqr0_xq3HJmzC-k1nGmeL_D7Go-qX-Im&fbclid=IwAR2bgHJOV9LSXQ64J6naWo7J0usECi9h8YVdJ2lEo_6ZcenmuAuVSM91iBI

[GRABOSM]

Most road servicing temples in Northern Thailand are marked as service, and tracks are used primarily for farming and forestry. What I am missing here??

@intuiquest, thank you for bringing this to our notice. The reason why some of these edits were made was because of the presence of muddy roads and the fact that there were many fields surrounding these areas, which according to the OSM wiki is to be considered tracks. Also, the roads connecting the service were mapped track as well. To maintain uniformity we edited it back to the previous classification. We were not aware of the reason why this was mapped and hence reverted back to track based on what we saw on the imagery.

Also, we have observed that you use google satellite as the source of imagery. As far as OSM policies go, we do not use licensed sources for mapping. You can learn more from the wiki: https://wiki.openstreetmap.org/wiki/Legal_FAQ#Can_I_trace_data_from_Google_Maps.2FNokia_Maps.2F....3F. Just wanted to verify whether Google is viable source to be used for mapping on OSM.

We are following the existing OSM policies for mapping. If there is any alternate suggestion from the community, we will be happy to include that in our mapping policies.

My understanding was that only a residential area (high density of houses) could justify a highway=residential segment, some sparse houses along a few km of farms would not justify this, hence the road should be split into at least 2 segments. On the other hand, a road linking 2 villages should be marked as unclassified from beginning to end.

We agree with this and will communicate the same to the team. Thank you for sharing the change sets. We are in the process of revisiting these edits and will correct any errors from our end and ensure that this is added as a written policy for TH.

There are currently no country-specific guidelines for minor road classification, and I understand they may be different interpretations. My goal however is to come up with a proper set of rules and recommendations to improve the overall map quality specifically in rural areas.

That would be very helpful and yes, currently minor roads do not have that set documentation. We are following the same as OSM polices on case by case basis, and map on several instances based on what we see in the imagery - satellite and available street level images. However, due to our limited sources of information, there are some edits that might not completely match with the country policy or the way the local mappers map and we would love to get any insight on better sources or just the correct tagging mechanism that will help us make our existing policies better.

We are here to improve the map, and the suggestions from the community members will help us improve the current processes we have.

@GRABOSM I would personally recommend avoiding Bing and use more recent imagery like Maxar or ESRI. I do a lot of imagery surveys and I found out that at least for northern Thailand, Bing imagery is very outdated. I often run into conflicting Bing additions, here is a clear example: https://www.openstreetmap.org/edit?way=927059104#map=19/18.92189/99.03998

Thank you for reiterating this. We do not use Bing imagery for mapping as it is outdated. Our major sources for mapping are Esri/Maxar and recent street level images that are available.

@GRABOSM Could you please kindly share any internal guidelines you have provided to your mappers? I am interested specifically in any recommendations you may have given regarding minor roads classification.

Yes, absolutely. We are working on making our written polices public on Github. We will update as soon as it is live.

Thank you!

[cmoffroad]

Also, we have observed that you use google satellite as the source of imagery. As far as OSM policies go, we do not use licensed sources for mapping. You can learn more from the wiki: https://wiki.openstreetmap.org/wiki/Legal_FAQ#Can_I_trace_data_from_Google_Maps.2FNokia_Maps.2F....3F. Just wanted to verify whether Google is viable source to be used for mapping on OSM.

I am really not sure how Google shows up as my source, it's not technically possible to use it due to legal constraints that I am aware of. I did a coding experiment at some point with some Chrome Extension, so I will need to check what is going on. I also primarily use Maxar/Esri and local knowledge from areas I am familiar with.

Thank you for reiterating this. We do not use Bing imagery for mapping as it is outdated. Our major sources for mapping are Esri/Maxar and recent street level images that are available.

Sounds good. The road added in the link above was 4 months old, so I suspect the imagery was only then updated recently.

Edit: it was indeed an old failed Chrome Extension experiment that modified metadata and showed Google wrongfully as a source. I removed it and my change sets are now showing the correct source.

[cmoffroad]

@mishari @GRABOSM

I don't think it's the curve in the corners which are the problem, but more so the entire road that looks curved because they're not parallel as they should be, as well as L shape ending to a straight road.

Why should curved corners be even allowed when they are in fact sharp turns?

• it could be dangerous for drivers using navigation, underestimating the need to slow down
• it makes editing/extensions very painful:

Please have a look at this recent addition using satellite imagery: https://www.openstreetmap.org/edit#map=19/18.92494/99.01323

Besides being the wrong classification, the corners are in fact four-way intersections. Now, the curvy corners are made of 4 nodes instead of 1, so in order to add the missing road network, I must delete 3 nodes, manually reposition the segments, this is very painful and should be simply unnecessary...

Could you show which policy you're referring to?

Also interested in this answer. I do not see any curved corners in Munich, New York, or Stockholm. Yet they seem everywhere now in Thailand. As far as I can see, Facebook digitalglobe imports were previously done with mostly sharp geometries.

For comparison, Bing and Google Vectors Maps use very slightly curved corners, however, intersection and entire segments are straight and follow strictly GPS shape.

[cmoffroad]

@GRABOSM Over the past weeks, I have left dozens of comments on changesets from your mappers including requests to correct wrong minor road classifications. Only one person has responded so far, no changes were made.

I would like to remind you that it is the responsibility of the mapper to respond to changeset discussions and correct if necessary previous edits.

[cmoffroad]

@GRABOSM Is this user part of your team? His changeset comment signature differs from other mappers, and his recent changes are borderline vandalism (deleting existing road segment, adding gates in the middle of a public road).

https://www.openstreetmap.org/user/KulMay

Please respond asap, so we can address the issue.

[GRABOSM]

@cmoffroad, thank you for bringing this issue to our notice. We verify that the mapper belongs to our team, and is relatively new to all the mapping policies. We are verifying this and will get back with an update and correct the incorrect edits, as soon as possible.

[cmoffroad]

@GRABOSM As per the new note to companies in the Thailand OSM wiki, I have asked you previously to contact the forum before starting a new mapping campaign to discuss your plans with the local community.

Since you haven't responded and started a new campaign anyway, I have created a warning thread in the Thailand OSM forum and I would like you to get in touch asap with the community to discuss your new campaign changes and how to prevent issues we encountered during your past campaigns:

https://forum.openstreetmap.org/viewtopic.php?pid=850100#p850100

[GRABOSM]

@cmoffroad thank you for the feedback and starting off the thread, we have responded on the same: https://forum.openstreetmap.org/viewtopic.php?pid=851153#p851153

There was some confusion on our side as the existing campaign was an old one and was on hold for a bit as there were other cities that the team was working on, so we didn't create a forum thread for the same (thought it was only when we start a new campaign), but rest assured, we will ensure that any query or concern we encounter while mapping, we will create a forum thread for the community's reference and also document them on Github.