The exported data is of very bad quality. I would dare
to say of extremely bad quality, since even roads
sometimes do not reflect reality.

In this particular area curve of Comstock Mill Rd
didn't follow real road. Robinridge Lane didn't even
had a single point matching reality, it was going
to the north-east of Comstock, crossing several
private lots, while in reality it goes south of Comstock.
I fixed that 6 months ago.

The polygon data is also shit. The county data (at
least the data they give to you) do not reflect reality.
A wood where in reality there is a meadow - multiple
examples. Vice versa - multiple examples. Soquel
Demo Forest going over private property. I know it
is incorrect, I can give you names of people whose
land was mapped as SDF.

Finally, even most official not outdated cadestral/parcel
data is incorrect. Let me explain why. It is data of the
last land survey that was converted to Lon/Lat in a
very rough manner. The actual borders of lots
are defined not by lat/lon but in a text manner, e.g.
"600 feet from junction", "300 feet along canyon".
When county does surveys they encounter lots of
problems - streams changed their curve, a road has
moved due to mudslide, etc.
After survey is done, new data enters the database.
I believe for surveys made in last 10 years it has a very
good precision. But for some lots last survey was
performed in 19th century! Until survey is done, the
actual border is where neighbors agree it to be.
Where a fence is, or where a road or stream is now.
Which means TRUTH ON THE GROUND. Not in the
county database, sorry.

We already discussed quality of data at database
level: adjacent polygons overlap, are not connected
to each other. An attempt to improve forest borderline
pulls a ton of problems. This all just blocks editing of
data by inexperienced mappers.

So what is our goal: to fill the map with something
so that map looks nice when zoomed out? Or may be
to maintain a copy of county cadestral/parcel db? I believe
our goal is to have the best damn map in the world,
which is true and precise at any zoom level! In some
regions of the world OSM is already damn best. In the
SC county we are like stuck in a clinch, we are in a limbo.
New mappers open data in JOSM, see the mess and run
away. Those who are willing to resolve the mess are being
asked to stay away. But still edits are coming in, so your
endeavors to do continuous exports become more and more
difficult. May be it is time to stop exporting? Exporting
was a good thing 10 years ago, when OSM was all virgin
and white. Now it does more evil than good.

I really wish we escalate this disagreement to a larger level,
so that more people can participate.

This gate already was on the map. It is on the fire road itself, not on Comstock Mill. I already removed the extra gate.

Hi! The natural=peak,ele=602 point here is completely wrong. The whole area is around 400 meters high.

Hi! There is no gate there. The road is marked private, but there is no gate and never been there. Down to the south there is a gate towards the forest.

Any objections if I revert this changeset?

Thanks!

Hi! I'm pretty sure that osm.org/way/193310452 doesn't exist. At least it doesn't reach that treacherous path that both of us hiked. Do you mind if I delete it, or at least shorten it, so that it doesn't reach the path?

Hi!

Just saw your old comment: "Glebius, why on earth you saw the need to add motorcar=no to a highway=path is totally beyond me. How superfluous! I have actually hiked this treacherous path, and added sac_scale=demanding_mountain_hiking, a much more appropriate and helpful tag."

Back when I marked it this way, I approached the trail on a bicycle from the south. I turned back at a point where I could no longer ride. At that point that was a good track, driveable by a 4x4 car. However, since track belongs to Demo Forest, I've put motorcar=no. Today I have hiked it from north, connecting the point where you gave up hiking and put "fixme" and point where I gave up on riding. Ha-ha, now I understand your comment! On my way back I have lost the trail. :) Now, that I have clearly marked the point where it stops to be a highway=track, I will split it into two parts: track and path with sac_scale. The path has ribbon marks saying it is "skid trail", and some sections of the path are clearly excavated in the slope, so looks like many years ago it was driveable by forestry equipment?

In Russia we are using reltoolbox since 2011. I don't remember when I last seen a piece of map in Russia with doubled nodes. Of course this hurts Potlach users and is an obstacle for newcomers, but for experienced JOSM ninjas it is definitely a winner approach. I believe consensus in Russia is that advanced multipolygons is the way to go.
I was somewhat disconnected from OSM for last years, just touching it occasionally, and I wasn't following any US mailing lists or forums. So, I had a feeling (now I see it wrong) that advanced multipolygons became a world wide consensus. I even assumed reltoolbox to be not a plugin any more! :)

I quickly searched on this question and looks like in reality there is no consensus yet:

osm.wiki/Relation:multipolygon#Mapping_Style.2C_best_practice

I really encourage you to try it out. There are video lessons on reltoolbox, unfortunately in
Russian. But looks like Youtube now can provide machine translated subtitles, that are usable:

https://www.youtube.com/watch?v=jfKfjxK7dYk

P.S. Of course it doesn't make sense to use advanced multipologyons for micromapping, e.g. buildings. But it is very handy for landuse=* and nature=*. In Monterey I multipolygonised a few buildings, since they are really adjacent to coastline, I'd say this is an exclusion.

Hi! Many people have found out that maintaining multipolygons is easier and less error prone than maintaining adjacent areas with doubled nodes. Of course this requires the "reltoolbox" plugin. Btw, I'm very surprised that it still isn't part of base JOSM. I supposed it was, but just checked and it still is a plugin.
Also as I was going through the coastline I wasn't only killing doubled nodes. There were a lot of exported data from various sources, where polygons either intersect or do not reach each other, when they should be adjacent. I must admit quality of OSM data in USA is much worse than in other countries, I've used to work with. :(

Thanks!

Didn't understand what your comment mean. That was a huge import. If you know name of a particular street, just make a correction.

I don't remember that I did that intentionally. More likely these are leftovers from previous editors.

Hi!

You added oneway=yes to a road that looks very much like a roundabout. But the direction seems wrong to me. Can you please check?

6) You also set highway=tertiary on a line that I explicitly marked as "there is no road here".

5) There are roads not connected to anything.

4) There are overlapping polygons.

Hi!

I got bunch of comments on this change.

1) Assigning every possible track a "tertiary" value is absolutely incorrect.
2) building=айл is definitely incorrect tagging.
3) What is the source for some roads? There is no GPS trace neither highres Bing in some areas.

Убедил. Я поменял тэггинг на всех недавно добавленных столовых.

O> Здравствуйте. Напишите, пожалуйста, действительно ли отель, добавленный в этом пакете правок, называется «s»?

Это конечно опечатка. s означало переход в режим добавления точек :)
Исправил.

O> Почему слово «Столовая» указано в названии кафе?
O> Почему столовая не обозначена как столовая (amenity=fast_food + fast_food=cafeteria)?

А мы где-то договорились, что столовые нужно обозначать именно так? Я сейчас немного выпал из русского OSM, не читаю форум и новые предложения в wiki. Как по мне американское понятие "fast food" категорически не отражает русское понятие "столовая", и ничего лучше я пока не придумал как давать такое название. Если оно на фасаде написано большими буквами, то оно и действительно является названием.

You actually have drawn bridge over Hovd, not over small river. 2 years ago it didn't exist, that was ford. Are you sure?