If ID removed tags, then it would be worth reporting to its developers as a bug, because usage of shop= tags on instances of amenity=fuel is standard tagging and has been documented at the OSM Wiki for many years. But what I want to ascertain is whether ID did, in fact, delete those tags on its own, and your defensive attitude and failure to explain exactly what happened is unhelpful.

You are mistaken if you think that JOSM is some kind of buggy editor inferior to ID. Both editors have different use cases and are widely used by the OSM community.

"Its the first time I got message from you."

I complained to you about this in October of last year under changeset/173558142:

changeset/173558142

"Except if the ID editor got your edit as mistake and I just applied the correction."

If ID said that (did it?), then it is a false positive.

"If you want to enter a shop on the fuel station, better make a new pin beside the fuel station."

shop= tags on amenity=fuel are a standard tagging (under the principle “One feature, one OSM element”).

"Don't threaten me again."

Telling you that I will escalate to DWG if your edits continue to remove surveyed data is not a threat, it is the standard working procedure here. OSM is a community, we all monitor each other’s edits. Please stop being hostile to changeset comments.

The History view is reliable and it shows that you, user ViewStreet, removed that tag. If you think that you have not been making such edits intentionally, then you may be using your editor software incorrectly and I ask you to be more careful in future.

Here is the history of the node where you can see that you did, in fact, change it:

node/9164494129/history

Also, when another user points out that you are making (repeated) tagging errors, it is not appropriate for you to respond with "Watch your mouth". On OSM one should expect criticism of one’s edits once in a while.

Stop removing shop=yes tags from instances of amenity=fuel. This is a common tagging on these POIs, and lets e.g. cyclists know that they can enjoy a cold drink. If you are using software that flags these as a bug, it is a false positive.

I have already warned you about this before. Do I need to escalate to the DWG?

You added the post_office =post_partner tag to an amenity=post_office node. According to the OSM wiki, this tag is meant to be used on instances of osm.wiki/Tag:shop=, not amenity=post_office:

post%20office=post%20partner?uselang=en

Several 3D renderers I am familiar with already display building height by approximating from the number of levels. So, adding an approximation to OSM itself doesn’t really provide anything new for map users, it only introduces possible inaccuracies into the database. I urge you to start a post at community.openstreetmap.org and explain clearly what you have been doing. It may be that the prevailing opinion will be that all these changesets must be reverted.

I must admit, I’m uncomfortable with such guesswork. Have you received community approval for such a large number of edits?

What is the source for these building heights you have been adding?

Sorry, I mean tourism=camp_site. I can also see from your other changesets that you are adding arbitrary English-names to POIs (like “Abandoned gas station” in Turkey). Please do not do this, name= tags should be in the local language and only if they are the actual name of the POI.

Please do not add wild-camping spots to OpenStreetMap. The leisure=camp_site tag is for something regarded as official for camping, not just one traveler's subjective opinion.

In this changeset, you added a wild-camping site “Open gate to cell tower”, but this area is a sensitive border zone and no one is supposed to enter those gates even if they are open.

OK, I see what you mean. I am currently traveling Oman by bicycle and unable to review those changes from my tent, but next time I am staying somewhere stable I will look at those roads again to ensure that link-road tagging is motivated.

This changeset has been reverted by changeset/175793701.

Please respond to changeset comments in order to remain a good-faith member of the community.

My changes were made very deliberately. According to the OSM Wiki, link ways should take the classification of the highest-level way to which they are connected. Thus, for example, a link way joining a primary highway to a tertiary one should be tagged primary_link, etc. It is a simple rule and does not require mappers to think about the "function" of the road.

This is the standard now employed in many of the world's best-mapped countries, and I would urge you to help implement it in Oman wherever it is lacking. Neither foreign mappers nor developers of global navigation aids are likely to know of country-specific quirks.

Why are you adding highway=crossing nodes at intersections of sidewalks and driveways or other minor service ways? For example:

node/6907099584#map=19/34.135201/-118.009412

This is not standard on OSM, and this is the second time that I have seen your team do this recently. If your team cannot use standard tagging approaches, I would have to escalate this to the Data Working Group.

Why did you remove the border-control name= tags from this node?

node/2063357044

I went ahead (changeset/174842033) and deleted the separate cycleways, instead using the cycleway:both=lane and cycleway:both:buffer=yes tags on the roads themselves. This is how such cycleways in SoCal are overwhelmingly mapped.

If you want to preserve the name “North Chorro Neighborhood Greenway”, then please create a new relation with all the road segments that make it up, and add the name there. Was the creation of a relations for California Cycle Route 95 also your work? That will also need to be adjusted accordingly.

I see that you added the North Chorro Neighborhood Greenway as a separately mapped cycleway. This is not ideal IMO: areal imagery shows that generally one is sharing a the road with cars, and the California shared-lane marking is painted one the road. You would be giving bike routers more accurate information by deleting the separate highway=cycleway way, and tagging the road as cycleway:shared lane instead. Of course, you could have the “North Chorro Neighborhood Greenway” itself mapped as a relation.

It would be good if you could go back through your previous edits and remove any crossing=tags you have added at the intersection of sidewalks and service ways. Especially if you are a part of a corporate mapper, just leaving such edits is going to create a lot of ill-will.

Why did you restore a highway=crossing tag to this node:

node/7246160566

Areal imagery shows no formal crossing here. These tags do not need to be added to intersections of sidewalks and driveways (or similar service ways) where there are no markings.