Is anyone else finding JOSM has bugs with handling current, up to date, valid wmts feeds?
In USA Massachusetts there is a great deal of information provided by the state under “MassGIS”. This information is authoritative, so much so that JOSM Wiki has for some time included MassGIS tile servers as entries in the menus. However it seems like there is a JOSM bug with displaying current services? The Wiki entry for 2019 Orthos still works, but newer entries like 2023 and 2025 return HTTP error 200 on-screen, and the JOSM debug info says “Image not returned for tile”.
I thought perhaps the JOSM Wiki entries were out of date - maybe MassGIS changed the links -however the issue totally replicates if you manually create a new wmts imagery source with the current correct link.
To further test this I loaded same exact links into QGIS and they work to perfection so it doesn’t seem to be MassGIS’s fault.
So: Wondering if anybody else is finding similar for other tile services? I’ve filed a JOSM bug report but thought I’d ask here too.
Just for info 200 is not an error, but it should normally not be shown. 200 is the http response code that means OK request succeeded ( MDN network: HTTP 200 OK)
Yes, there’s some problem with the MassGIS/ArcGIS servers returning the wrong Content-Type, which iD and many other systems manage to deal with anyway but JOSM complains about. On the talk-us-massachusetts mailing list, @gdt has reported a little bit of analysis and tried to contact MassGIS about it but I haven’t heard anything since then.
I did write to MassGIS and they are at some level now aware of the problem. It is less clear if they agree that it is a bug – it’s not 100% clear to me either, as while having the right Content-Type seems obvious, what does the TMS spec say?
Also, they tiles are hosted at ESRI, and my impression from afar is that trying to get ESRI to fix anything, even if you are paying them, is not likely to be successful. IDK; I have never tried.
As to what’s going on, yes it’s 200, which is ok, and the Content-Type is application/octet-stream, which is sort of not wrong as in “here are some bytes”. They are jpg, which can be determined by inspection, and apparently everything else (openlayers, qgis) do that.
My view is that ESRI ought to fix this, but that if not, and probabiy even if so, it would be good for JOSM to cope.
Thanks guys wow what comprehensive fast answer! At least I know not to beat myself silly trying to figure out if it is a config problem with my JOSM or my firewall etc. (ooops already did that for a while )
I agree both sides should probably implement fixes in the interests of best user stability, clinging to "well tecknikally its not compliant…” when the other major user software just figures it out would be kind of disappointingly pedantic….
)