[PATCH] MVT Tiles are not loaded in non-Mercator projections

[Polarbear-j]

JOSM/1.5 (18173 en_GB) Mac OS X 10.14.6, Java version: 1.8.0_291-b10, Oracle

v2.0.0-alpha.32 shows "Error: Could not load image from tile server", does not show any tracks,
and the console output shows a 404 error followed by a number of tile loads, when I turn on the mapillary layer:

2021-08-27 19:07:47.144 INFO: GET https://tiles.mapillary.com/maps/vtp/mly1_computed_public/2/{z}/{x}/{y}?access_token=MLY|4223665974375089|d62822dd792b6a823d0794ef26450398 -> HTTP/1.1 404 (546 ms)
2021-08-27 19:07:47.255 INFO: AbstractTileSourceLayer: estimated visible tiles: 54, estimated cache size: 466
2021-08-27 19:07:47.276 INFO: AbstractTileSourceLayer: estimated visible tiles: 54, estimated cache size: 466
2021-08-27 19:07:47.277 INFO: AbstractTileSourceLayer: estimated visible tiles: 54, estimated cache size: 466
2021-08-27 19:07:47.278 INFO: Allocate for tile source layer: 116 MB of memory. Available: 3,591 MB.
2021-08-27 19:07:47.550 INFO: GET https://josm.openstreetmap.de/tested -> HTTP/1.1 200 (120 ms)
2021-08-27 19:07:47.710 INFO: GET https://tiles.mapillary.com/maps/vtp/mly1_computed_public/2/14/8816/5388?access_token=MLY|4223665974375089|d62822dd792b6a823d0794ef26450398 -> HTTP/1.1 200 (422 ms)
(similar GETs follow)

When I click "info" in the layers window, it says:
Mapillary layer: 0 sequences, each containing 0 and 0 images...

(also reported as ​https://github.com/JOSM/Mapillary/issues/189 )

[taylor.smock]

Would you mind pasting the 404?

[Polarbear-j]

Sorry, the github code block required a newline after the backticks, and I sloppily copied only what github displayed.
Now visible here and there, the first log line with GET verbatim {z}/{x}/{y} placeholders.

[taylor.smock]

2021-08-27 19:07:47.144 INFO: GET https://tiles.mapillary.com/maps/vtp/mly1_computed_public/2/{z}/{x}/{y}?access_token=MLY|4223665974375089|d62822dd792b6a823d0794ef26450398 -> HTTP/1.1 404 (546 ms)

This is actually JOSM checking to see if the URL returns a json file (i.e., if it has styling). This is not the root cause.

I took a look at the area in both the Mapillary plugin and the Mapillary website:

• ​https://www.mapillary.com/app/?lat=52.316078574972096&lng=13.719683684608185&z=15.540691298997581

(This came from the tile in a url in the report, ​14/8816/5388)

The reason why nothing is showing up is that the vector tiles don't currently have anything in them. If you have recently uploaded something, please wait a few days after seeing that they have been processed before getting worried over the images not appearing. Based off of past experience on this, it seems that there are two steps:
1) Image injestion finishes on Mapillary's servers (this is when the email was sent out, or at least it was a month or two ago)
2) Regeneration of vector tiles. This seems to happen a few days after (1) finishes. I don't know what the exact schedule on this is, but a week should be more than enough time.

[Polarbear-j]

Hi Taylor,
when the 404 error is unrelated, fine.
But the problem is not that the plugin would not show things in this location,
I do not see any mapillary track nor image anywhere, in particular not even old images in places
where a lot of old tracks exist. It is not about imagery recently uploaded.
And the console log does not show any hint, it shows a large bunch of tiles.mapillary.com requests which are successful (200).

Thus I cannot use any mapillary in my JOSM currently, as the old 'stable' plugin from April frequently freezes JOSM completely
(and does not show recent images, as far as i understood the API change) , and the automatically loaded 'alpha' plugin shows the world empty.

For your example tile ​https://www.mapillary.com/app/?lat=52.316078574972096&lng=13.719683684608185&z=15.540691298997581
move a bit north, it was the A10/A12 motorway junction I was looking at, with tons of old traces.

[taylor.smock]

Replying to Polarbear-j:

Hi Taylor,
Thus I cannot use any mapillary in my JOSM currently, as the old 'stable' plugin from April frequently freezes JOSM completely
(and does not show recent images, as far as i understood the API change) , and the automatically loaded 'alpha' plugin shows the world empty.

The old version from April no longer works because Mapillary shut down the v3 API.

For your example tile ​https://www.mapillary.com/app/?lat=52.316078574972096&lng=13.719683684608185&z=15.540691298997581
move a bit north, it was the A10/A12 motorway junction I was looking at, with tons of old traces.

It worked when I was testing. I'll attach a screenshot.

Can you try resetting the Mapillary filters (please click on the "Reset" button)?

EDIT: Screenshot

[Polarbear-j]

Filter dialogue

[taylor.smock]

Polarbear-j: Some of the filters have been able take an empty input in the past, which is why the Reset button exists. But you should be able to see stuff. Can you paste a screenshot of the intersection with everything up?

EDIT: The full JOSM window please.

[Polarbear-j]

Filter reset does not help. See attached before/after "reset".
Expert filter is empty as well.
I went to Advanced Preferences and selected mapill* which was a lot, and defaulted all of them. No effect.

Full window coming.

[Polarbear-j]

full JOSM window

[taylor.smock]

OK. Can you open the Layers window (Windows -> Layers). If the Mapillary layer is underneath a non-overlay layer, that may be the issue.

[Polarbear-j]

Not a layer issue.
Reprojection issue.

When I right-clicked on the tile with the "could not load" error, I got the tile info showing it is reprojected.
I normally work in EPSG 25833 which is the native projection for imagery here.
Once I changed to Mercator, the tracks did appear.

So we have a workaround, but the tiles should work in other projections as well.

[Polarbear-j]

reprojection

[taylor.smock]

OK. This is probably an MVT issue then. This is going to be a bit more involved, since the MVT spec specifies ​EPSG:3857. I'll probably have to do a deep dive into why it isn't getting reprojected by JOSM. I'll try to get it fixed in September -- I don't think it will make it into the September release (probably out in the next 5 days or so, and probably tomorrow).

[taylor.smock]

CI run: ​https://gitlab.com/smocktaylor/josm/-/merge_requests/11
Patch: ​https://gitlab.com/smocktaylor/josm/-/merge_requests/11.patch

[taylor.smock]

Add tests

[Don-vip]

In 18187/josm:

fix #21260 - fix reprojection of MVT tiles (patch by taylor.smock)

[Don-vip]

MVTLayerTest is failing:
https://josm.openstreetmap.de/jenkins/job/JOSM/jdk=JDK11/lastCompletedBuild/testReport/
Condition with lambda expression in org.openstreetmap.josm.gui.layer.imagery.MVTLayerTest was not fulfilled within 1 seconds.

[taylor.smock]

It looks like this is failing in the CI.

• Jenkins: https://josm.openstreetmap.de/jenkins/job/JOSM/jdk=JDK8/lastCompletedBuild/testReport/
• GitHub: ​https://github.com/JOSM/josm/runs/3477786168
• GitLab: ​https://gitlab.com/smocktaylor/josm/-/pipelines/363564384

But it didn't fail locally. :(

Best guess, something is going wrong with the finishedLoading. Just as a sanity check, I'm increasing the timeout for the Awaitility call (1s -> 5s).

See ​https://gitlab.com/smocktaylor/josm/-/merge_requests/12

[taylor.smock]

Replying to Don-vip:

MVTLayerTest is failing:
https://josm.openstreetmap.de/jenkins/job/JOSM/jdk=JDK11/lastCompletedBuild/testReport/
Condition with lambda expression in org.openstreetmap.josm.gui.layer.imagery.MVTLayerTest was not fulfilled within 1 seconds.

Sorry, I missed your post -- I was already looking into it. It is going to be ~30 minutes before whether or not I know if the tests are passing/failing.

[Don-vip]

OK, perfect :)

[taylor.smock]

Well, I made a mistake.

It doesn't look like it was the awaitility stuff. It helps to actually have the files in source control.

[taylor.smock]

Use tiles in source control

[Don-vip]

Confirmed in local: fails without patch, works with.

[Don-vip]

In 18189/josm:

fix #21260 - fix unit test (patch by taylor.smock)

[Don-vip]

In 18191/josm:

fix #21260 - increase timeout in unit test, seems to cause random failures in CI

[Polarbear-j]

josm 18191 / alpha 33 works for me now regarding this issue, thanks