OSM Inspector reported that this school building: Way: Our Lady's Primary School (closed) (1356901405) | OpenStreetMap has problematic geometry. This is correct. I imagine when the ‘square’ button was pressed that it went a little too far and some of the concave parts of the building collapsed to zero width.
Interestingly, the school building is not showing on Standard view, Cycle Map or Shortbread.
It is showing on Transport Map and MapTilerOMT.
Tracetrack Topo is showing part of the name, but not the building.
Humanitarian was showing it partially, but now it is completely gone.
CyclOSM is having problems loading. [EDIT] It doesn’t show it.
The school building across the street seems to be rendering OK and the group home (Dunowen Court) that I added today is showing on Standard view. So the only issue seems to be that the problematic geometry is preventing some map styles from rendering it. However, other map styles don’t seem to have that problem.
Loading the object in JOSM and moving one of the nodes slightly then trying to upload, I get a warning about “Self crossing ways” and it highlights one of the corners:
Moving the node in the middle of the highlighted “T” slightly to west resolves the warning, and might make the building render.
I would suggest generally improving the geometry. The building as mapped currently has a 4 cm wide, 2.5 m deep slot in it on the south side, which seems improbable. Is it rather something like this?
That’s not unusual - different rendering stacks will take their own approaches to dealing with problematic geometries. As the maintainer of one such (tilemaker), invalid geometries are perhaps my biggest heartache when dealing with OSM data, although to be fair a single building is less of an issue than an entire lake system…
I’d ascribe the problem to the iD’s “square” option, which sometimes produces invalid geometries when applied to complex polylines. (I didn’t delve too deep, but the first version of the school was created by iD, the second was edited by JOSM.) Guess it can be reproduced relatively easily.
Interestingly enough, iD has mechanisms to prevent you from creating self-intersecting ways when you draw them manually. However, you can easily create invalid geometries using iD’s own built-in tools, such as sQuaring or Following (see 9154 for a funny example). And commit-time validations for those are missing.
So, I have added this node: Node: 14243100586 | OpenStreetMap thereby removing the overlap. I have not touched the “Two points in Our Lady’s Primary School (closed) are very close together” issues. Let’s see what happens.
Hi, I suspect that whether it is showing or not is down to whether the tiles have been updated or not for each map style, based on the changes I made to Dunowen Court across the street.
They all have their own update frequency , But I am seeing it on the standard (carto) map now. Are you also gone update the other spike just to the left.
P.S. The youth club has a very strange part on the top NE corner.
… and in many cases their own way of determining Geometry! The raster ones will tend to use osm2pgsql and will tend to work the same way. Of the vector ones, I linked to a Tilemaker-created map to show that it was able to salvage a useful geometry from something clearly not valid. OSMF’s vector tiles use Tilekiln I believe.
All map styles are now showing the adjustment that I made yesterday, except Transport Map (showing old version of building) and Tracetrack Topo (no building shown) - those two haven’t updated in several days. Humanitarian is very slow to load.
I’ve fixed up the buildings and a few other things on the street. The geometry isn’t precise, but it is OK. Neither OSM Inspector not Osmose are reporting issues.
I use OSM Inspector most days to check for geometry issues and tend to see a few per week. However, I think this is the first time in 12 years that I’ve seen a building not render like this. Has anything changed recently?
[EDIT] It doesn’t show it.
, But I am seeing it on the standard (carto) map now. Are you also gone update the other spike just to the left.