As - I see. But that service road had no tags, no nodes designating entry/exit into the building. Please put those in at all times - otherwise its simply intersections that just look like when new buildings are added where there were previously just roads.

Clifford,
the farmland was drawn with two closed ways that had a number of common segments in between them and were combined in a multipolygon. The OSM area checker flagged these, as such polygons are not rendered at all in some software (mostly openGL based ones).

Hey there,
sattelite imagery might not be too good of an source, as it misses out on road names and won't show very well barriers (like ditches/berms) that block access. I'm more thinking of re-importing that whole area from Tiger 2015 data, which is vastly improved if you check this (can be loaded as background in JOSM). This area would be particularly suitable for such an approach, as there are no non-road features now at all (i.e. no alignment issues) and the area has only very few connections to the "outside" world (which would have to be hooked up by hand).

I simplified the boundary to 33ft (which is grated, relatively coarse, but the staircases were 31ft on average, possibly resulting from 10m/pixel bitmaps) which took out about 90% of the nodes.
The average spacing between nodes is now about 300ft, comparable to node spacing of roads and other features in the area. My algorithm does keep in nodes at a maximum spacing of 1km/3000ft. Granted, it does not insert nodes (yet), so there are a few 4mi segments still in there that were there before.
So only if you download an area smaller than this, you might get such a problem. Thats why the JOSM recommendation is to keep segments shorter than 20km and I deliberately keep it 20x under this.
So in a urban area where one migh download areas smaller than a city block, this might be debateable, but in an rural area like this - it is IMO very unlikely that there would be a need to ever download such a small area - a its most likely be void of features, anyways.

Hi there,
could you please elaborate what you like suggest with "fixme=route" on the BIA Road 2 (way_id:5443851) that you tagged a week ago ?
And what caused you to single out the few other roads in that changeset that you marked with "fixme=fucking wrong" ? There are a lot of discrepancies between OSM data and Tiger 2012 or Tiger 2015 and the particular roads you tagged do not really stand out for me ...

I tagged the mapnik tiles within this changeset dirty and most of them re-renderd now. I see no issue with the Spokane river. Can you confirm ?

I just checked the updated slippy map tiles and they look fine. Also re-downloaded the data, which looks fine is JOSM, too. Plus I'm still the last editor of these traces, the changelog suggest no inintended edits done in that changeset to the river (just moved 3 nodes of it).
I do see when zooming in/out that some older tiles render without the riverbank.
I suspect there was another edit just before mine that caused a temporary issue.
I'll check tomorrow again when all tiles should have updated fully. But so far I think my edit is not the cause of the problem.

Around crescent city (and likely others) there are duplicate coastlines now.
And bazillions of bogous little "islands" along the cost (like every rock exposed at low tide) left behind as untagged ways.
Needs serious cleanup.

I see a lot (close to 100) errors in OSM inspector here: multipolygons with duplicated segments, land use conflicts.
The root cause seems to be this changeset uses round circular landuse=forest areas to depict the location of individual trees. If these tree are standing close, the ways are combined to a multipolygon without removing of inner segments.

I think landuse polygons are not intended to depict individual tree's, so these should be replaced by individual nodes with natural=tree.