Hm, ono je to asi jedno. Mně to přijde mírně přetagováno,ale asi na tom nesejde. Dle wiki by backcountry mělo být v divočině, nedostupné autem. Není úplně jasn, jak daleko to musí být od nejbližší cesty, mě přijde že v našich podmínkách takovou divočinu nemáme. Impromptu je takový divný tag pro overlandery. Co mi tak přijde, tak v praxi je tag, který je nejdůležitější, camp_site=basic, tak to asi nechám být. Dělal jsem úklid hodnot backcountry=yes a zjistil jsem později, že v USA to na shelter taky používají, tak asi ok, wiki jsem podle toho upravil.

Hello, there is access tags and also camp_site=basic to indicate that there is nothing there. I changed it accordingly here: changeset/180013586

But I would also be quite happy for the node to go away altogether.

In any case, it is not in backcountry, it is too close to a road.

I have other concerns. First, I think impromptu is more for RVs and I have doubts if we have any real backcountry in Czechia, a lot of these are next to some kind of a road anyway. For some, these tags are also applied to "amenity=shelter", which is not very appropriate either. Also the note "Anyone can access this camp and legally sleep there, BUT no fire and no tents are allowed." is visible only to mappers, should that not be in the description if it is meant to be displayed?

Hello, I am going through backcountry=yes that do not have a tourism=camp_site. I changed the tags here: changeset/180012144

I think either it should be deleted or it should be properly tagged. Inteligent renderers should catch camp_site=basic and backcountry to indicate it is nothing official and access clearly specifies this is not legal. I am ignoring the fact that it is probably an imaginary feature so it should not be in the OSM in the first place :-D.

yeah, I was actually not aware of the JOSM function "Upload selection" until now, will use it for similar things from now on.

So I reverted this manual import with these changesets:

changeset/179149404
changeset/179149569
changeset/179149848

In case of objections, it would be best to discuss here: https://community.openstreetmap.org/t/suspected-semi-automated-import-of-mountain-passes-in-nepal/141725

Sorry for the completely nonsensical comment on teh changeset - I hit enter in JOSM by mistake and a previous changeset comment from the other side of the world applied. I had a reminder to revisit this area, because when I was there two years ago the satellite imagery with then newly constructed tracks was not yet online. Now it is, so I am adding new tracks.

So, this node: node/12564723124#map=17/28.083707/84.881456
is based on this map: https://pahar.in/pahar/Maps--Primary/Nepal%20Maps/Nepal%20Topo%20Maps/2884%2016%20Arughat.jpg from the trail just under Mansire? where it sort of crosses a pass sideways? And for some reason, this is not made on a node of the unclassified highway that runs there?

Anyway, these maps are copyrighted at 1997. I do not thinkg they are out of copyright :-(.

Ok, first, what is the license of the source data?

Did you do this manually or programatically?

But I think I now understand where the problem lies. A lot of the trails follow a ridge (they are in parallel to it) and do not cross it (they are not perpendicular). The wiki definition does not specify it, but I would argue it implicitly assumes it (OSM being West-centric, ridge roads are not very common here at all).

Hello, I can see you added a lot of passes to Nepal’s map: https://ultrajourneys.org/mapping-nepal/

For example in this changeset, I think most or all of the 11 nodes marked as passes are not really passes. They mostly map to (minor) peaks or sidepeaks. This seems like an automated edit but I cannot find it in the logs: osm.wiki/Category:Automated_edits_log

Did you follow the automated log policy: osm.wiki/Automated_Edits_code_of_conduct

How did you determine they are passes?

I spent a month in the area and noticed the passes data there are just wrong, I think this particular changeset decreases quality of OSM - I have not reviewed all of Nepal but what I have seen, the data just felt wrong (either very minor passes marked where bigger passes were unmarked, or more often peaks marked as passes). Maybe I am missing something?

I also started a discussion here: https://community.openstreetmap.org/t/suspected-semi-automated-import-of-mountain-passes-in-nepal/141725

Ok, I have the GPX route of HA on hand, I tried to fix that stage base d on it, it did differ at places a bit. Anyway, the change is here, and your MTB relation si there too: changeset/159634131

I hope that is what you wanted me to do. 

so given the description, it should route=mtb no? Do you think it makes sense putting one way property on the relation?

From reading that description, this is the only part of HA also possible for bicycles ( I walked or crossed more stages but not all and some were passable on a MTB, I guess, but it would have been rather demanding).

Hello, what is the name of the cycling route? (I f I noticed correctly, no other part of Huella Andina is marked as cycling route, so I would suspect the cycling route is not Huella Andina - no sources nor anything onthe ground on the parts  walked suggested it is a cycling route also ).

There is a signpost for the route at the bottom of the valley accordign to map. So there is something on the ground.

that should have been "please note"

I see, I would have reverted it then but you have done it already. Sorry.

Since there seems to be a representative of the German national park, please not the sign indicating the kern zone coming from inside Czechia is badly placed: it does not face the border, but is sideways, leaving impressin kernzone is only to the west of this road.

Hello,
1) on several paths I applied the "simplify path" tool of josm, I think with either 0.5m or 1m parameter. Is that not good practice? They seemed like GPS imports. Sometimes I adjust them by hand based on strava or based on my own GPS recordings. In nature, when you have a lot of strava marks somewhere with no way asssociated to them and nearby you have a way with no strava marks on it, I usually conclude the way is misplaced (which is usually supported by my own gps recordings), but I correct these things also when I see them nearby to places I walked through. In my understanding, when you originally have a way that originated as a GPS record of a single hiker, it will be imprecise at times.

Which concrete ways do you have in mind?

El Arco <--> Lago Vidal is not from me, that was already there. I was mainly adjusting the sac_scale and trail visibility so that it better fits the wiki standards (but these are sujective, anyway especially around Cochamo the difficulties were by far too hard, indicating using your hands when that is not the case) but I was mostly not changing the names. The only exception that I recall is the Laguna trail in Cochamo - this name was used on a guidepost there.

I know about fords. For some reason iD complains about that but JOSM does not. I tend to add those when it is an actual ford where you need to wade into the water (which depends on season anyway), but when it is a jumping or stepping over thing, I personally think they are a bit superfluous (in ideal world width=1 or something like that would apply to the stream). I do correct JOSM complaining about water and highway not sharing a node.

(where I changed bridge to ford or the opposite, that is because that is what is there in place, or at least was six months ago)

I will check out the plugin and ask you about it if I struggle with it. Might be a nice things, I use only a subset of what JOSM has to offer.

No offense taken, I think it is good you look over the changes.

There is one thing I am worried about this edit myself - JOSM was complaining about the same geometries overlapping each other (mainly wood). I tried to fix that, but I think I changed the way these large landuse polygons are made. They tend to use method A as described here: osm.wiki/Relation:multipolygon#Mapping_style,_best_practice
and I was switching them to method B before I realized that was not the best idea.

And also the relation: route=via_ferrata

feel free to edit both. But as there seems to be some form of consensus, it should be in the wiki in my opinion.

Ok, I documented via_ferrata=start

Ok, I put the individual ways into the parent relations and kept the subrelations for the three individual sections.

frankly, I still think this is osm.wiki/Tagging_for_the_renderer

and xctrails (and also openstreetmap.org) should be fixed to support superrelations. There is a segment that the purple and red section share, so colour cannot be applied correctly to that way. The main change was actually breaking the purple way into its constituents accroding to the schematic map on-site (picture is linked above) plus aligning everything in the area to a more proper spot.