Hi Stephan,

This is a task edge inconsistency we will definitely cleanup.

-Jeff

Hi Stephan,

For these issues, we just hadn't published the task to the north of this one yet. I just added the data myself and these should be resolved. Due to the gridded nature of our data these issues will happen from time to time in the short term but we will eventually fill in the neighboring squares.

Thanks for the feedback,
Jeff

Hi Stephan,

These were all along a task boundary where one side kept data and the other deleted it. The editor should have cleaned these up as part of publishing the data to OSM and I have talked to them and reiterated this point to the team.

However, I want to assure you that we would have caught this during our final validation step where we look at a project as a whole and blend the data to fix issues like this where one editor may have deleted data while another kept it or to resolve tagging inconsistencies. In the end we want our task grids to be completely invisible along with any lingering validation issues of course.

This project was only recently finished and there is a bit of lag time between that and the final check as that work takes some time and not every editor is trained to do it.

Thanks for the feedback,
Jeff

Hi Tom,

I assume this refers to way/434684710?

Not sure what happened here but I've fixed the bad nodes on the road. Sorry about that.

-Jeff

Hi Tom,

I assume you are referring to way/290748046?

I added the layer tag and deleted the extra node but this wasn't our data. It was created and tagged by Russ.

-Jeff

Hi Tom,

I updated the road alignment. Thanks for the feedback.

-Jeff

Hi Tom,

I reduced the amount of nodes, but for the tagging track seems more appropriate based on the surrounding data. The adjacent ways 319206290, 319206294, and 319206299 were marked as track by Russ and are identical in appearance.

Hi Tom,

Thanks for the feedback. Since this is a short road leading directly to a house we would typically tag it service to denote a driveway. Is there something specific that rules that out in this scenario?

-Jeff

Hi Stephan,

I agree. I think this editor was being overly cautious about making a false connection but the imagery makes it quite clear that the road continues. I will let the team know about this example.

As always, thanks for the feedback!
-Jeff

Hi Beddhist,

Thanks for the in depth feedback. This is very helpful to us for improving the quality of our work.

I've responded to a few specific examples here.

way/629622890: Agreed. This should have been noticed and attached to.

way/629622938: Stephan mentioned this already, but this was a result of realigning the data.

way/629622905: For this one, there is a car turning in premium so we can confirm there is not a barrier but if not it would be very difficult to tell how far the barrier actually extends on this road. In situations when it isn't clear but the split is close to our attaching road do you recommend that we adjust it or leave it attached to the one way?

Thanks again for your feedback!
-Jeff

Hi Russ,

This is a case where DG premium and standard showed a different situation on the ground. Presumably, the area was developed sometime after the premium imagery was taken. I've adjusted the road to fit standard better.

-Jeff

Hi Tom,

It looks like our user was attempting to realign the data in the area to fit premium better. Unfortunately, this caused the final node of way/508041154 to get pushed out of alignment and the user did not notice.

See https://overpass-api.de/achavi/?changeset=59059782 for a visualization

Sorry about that, I've fixed the node and I'll have our validators be on the look out for that.

Hi Russ,

This seems to be the result of a bug in our old version of iD. This road was correctly split to add the bridge in changeset/63363327. However, a following import changeset reverted the geometry of the split road. The user fixed most of the duplicated geometry but missed the bridge it seems. Our newer version of iD has better safeguards to ensure this does not happen any more.

-Jeff

Hi GerdP,

Thanks for the heads up. I've fixed the highway type.

-Jeff

Hi Stephan,

We agree. The connection was clear so we added it and upgraded the road to unclassified.
Thank you for your feedback.

-Jeff

Hi Stephan,

I completely agree. The road is definitely paved and the connection is quite clear. Adrian is no longer with us but I have corrected this mistake. As always, thank you for your feedback.

-Jeff

Hi Garok Tour,

I noticed that you had tagged some ways as highway=cycleway that appear to be drivable roads. In these instances it might be better to tag the road as highway=* (typically unclassified, residential, or track) with an additional cycleway=* tag (likely shared_lane). I've added links to the wiki below if you want to read more. Please let me know if you need any clarification. :)

-Jeff

cycleway=*
highway=*

Thank you for your comment and pointing me to this. It seems as though these are misspellings from the editors, meant for us to double check some of the decisions. I will fix these right away and make sure to clarify this with the team.

Thanks again
-Jeff

Hi EndlessRoundabout,

I noticed that this changeset duplicated some roads that you had already digitized in changeset/40113030.

Hi stephankn,
Thank you for your comment! We very rarely change existing tags because we are not on the ground to verify them and are conscious not to undo the hard work of local mappers who maybe adding these tags. We hope that mappers with a better context for Thailand like yourself can help in these cases. Thank you for all your time and feedback.
Best,
Jeff