Changeset: 45793071
Revert 45709783
Closed by wwhide
Tags
created_by | reverter;JOSM/1.5 (11526 en) |
---|
Discussion
-
Comment from mueschel
Hi,
why did you remove all the good tags again and re-added many tags that don't seem to belong to OSM?Cheers, Jan
-
Comment from wwhide
The border on the portion of the Winema National Forest in this region http://www.openstreetmap.org/edit?#map=16/43.0869/-121.8861 appears to be backwards, it shows landuse forest on the basemap but when editing, the border is on the land around the forest. I reverted to make sure it wasn't something I had done to cause that. I'll fix up the tags when I get a chance. Or I might delete the whole thing, it's a bit complicated for me with all the overlapping multipolygons.
-
Comment from mueschel
JOSM shows the marker on the wrong side, because there is no way to decide which is the right one by looking at one outer way only. As soon as you download the whole multi-polygon, it switches to the correct side.
There is no "backwards" with respect to the direction of outer ways of multipolygons. -
Comment from wwhide
I saw that just now in JOSM, I was obviously editing on the web application. When you look at it on the web application it indeed looks backwards whether there is a backwards or not.
-
Comment from mueschel
The problem is the same for both editors, they just can't decide what is inner and outer without loading the full relation - in case of iD I don't know if this is even possible. When handling huge multi-polygons like this, JOSM is a much better choice. E.g. because you can selectively load the forests on a large area without data you're not interested in.
Let me know if you need help here,
Jan -
Comment from wwhide
I could use help, changing all the tags is easy enough but I just took a closer look at the overlapping areas and it's pretty complex. First, large areas of the Gilchrist and Deschutes overlap, then the borders should probably be fixed up so the nodes align to ways or other nodes (that's easy enough too) I feel like the newer changeset achieved most of this, but I hadn't looked at the areas of overlap close enough. I'd also have to properly figure out all the inner and outer relationships.
I'm going to visit the USFS shapefile site and see if there's better information there on the overlaps, but it's almost to the point for me where it might be easier to delete the Gilchrist completely as it's better to have correct data than incorrect data.
I don't know if you have the ability to make the newer changeset live again but that might be a start then I can manually adjust the borders based on the USFS shapefiles
-
Comment from wwhide
As it turns out, much has changed in that region since a land purchase just a few years ago. I'm going to delete the Gilchrist and start anew with new shapefiles.
Ways (20)
- 86292717, v4
- 86292775, v3
- 86292858, v3
- 86292948, v3
- 86293022, v3
- 86293035, v3
- 86293093, v3
- Gilchrist State Forest (444362076), v3
- Gilchrist State Forest (444362077), v3
- Gilchrist State Forest (444362078), v3
- Gilchrist State Forest (444362079), v3
- Gilchrist State Forest (444362080), v3
- Gilchrist State Forest (444362082), v3
- Gilchrist State Forest (444362083), v3
- Gilchrist State Forest (444362084), v3
- Gilchrist State Forest (444362085), v3
- Gilchrist State Forest (444362086), v3
- Gilchrist State Forest (444362087), v3
- Gilchrist State Forest (444362089), v3
- Gilchrist State Forest (444362090), v3
Relations (2)
Nodes (20)
Welcome to OpenStreetMap!
OpenStreetMap is a map of the world, created by people like you and free to use under an open license.
Hosting is supported by Fastly, OSMF corporate members, and other partners.
https://openstreetmap.org/copyright | https://openstreetmap.org |
Copyright OpenStreetMap and contributors, under an open license |