|
The Schuylkill River near and surrounding 40°13'27.0"N 75°36'24.2"W has a "fix me" associated with a messy rendering of one [or more] "river area" polygons trying to show a nominal coastline. Depending on how one pans/zooms, the shading that accompanies the polygon can be on the proper side of that line, the opposite side of the same line, or even on both sides of the line. Worse, with different pan/zooms, you can see that the rendering algorithm gets confused by which vertices to consider, including connecting radically distant vertices for the purposes of shading. I'm no expert, but I seem to remember from decades ago something about an even-odd winding rule that has something to do with the graphics algorithm and these phenomena. Is there an accepted way to craft such "river area" polygons to avoid this rendering problem? It appears the creator might have tried to do a fairly large distance of the river along its flow in a single polygon, which would be easy to believe makes the problem worse. For the specific URI: https://www.openstreetmap.org/edit?editor=id#map=16/40.2201/-75.6082 the attached screen grab shows two shadings angling down from upper left toward lower right - these are representative of the fill problem described and likely representative of the original "fix me". Clearing my browser (Edge) cache had no discernable effect. I tried Chrome, which had never visited any part of OSM site before now, and observe the same exact result. Also note that the upper (northern) shore of the river does not appear to be shaded while the southern shore has its shading on the "land side".
|
|
I've seen this same effect in JOSM as well when only some of the relation members are loaded into JOSM. Loading all relation members, (and sometimes neighboring relations, (all members)) usually rectifies the problem. I don't know if all members can be loaded into the iD editor to rectify the problem there. As mentioned there's nothing wrong with the relation. |
|
I checked both visually and with automated tools (JOSM Validator and Relation Analyzer), and I can't find any errors in the data. The OSM Standard rendering looks just like I would expect, with no spilling outside of the riverbanks. If you're seeing something different, you may want to clear your browser cache to make sure you aren't still seeing tiles from before someone made a fix about 3 weeks ago. For those interested, the relation in question is here. I updated my original inquiry with an example, but responded to your @alester's browser recommendation at the same time. Again, I'm not certain the data is necessarily in error - I think the probability lies in the rendering algorithm's determination of which vertices are visible within the pan/zoom viewport.
(11 Mar '22, 17:42)
R J H
1
I initially thought you were talking about the final OSM Standard rendering, not the rendering inside the editor. This appears to just be a visual artifact in the iD editor because not all of the necessary data has been loaded in order to properly shade the water area. I see similar effects in other editors like JOSM when working with incomplete relations. Since only some of the relation is downloaded, the in-editor renderer has to make some guesses and sometimes guesses wrong. This isn't really an error, since the editor is doing the best it can with the partial information. If you browse around enough such that iD downloads the rest of the data for that relation, the rendering should display correctly.
(11 Mar '22, 18:33)
alester
@alester - add your observation about this being a phenomena of the ID editor as an 'answer', and I'll up vote it as the correct answer. I do, however, continue to wonder if there isn't a recommendation to be had about how many tiles should be spanned by huge polygons to minimize this happening. Rivers will be popular instigators, but things like large military bases should theoretically tickle the same vulnerability.
(11 Mar '22, 21:17)
R J H
|
|
This isn't a rendering, but an editor problem. fixme tags shouldn't be used in this situation, a ticket raised on github instead (good luck with that). Similar happens in Potlatch. |
