Please fix this Mapbox satellite bug

[anonymous]

What steps will reproduce the problem?

1. Selecting "Mapbox Satellite"
2. Zooming at z17 and high , in 35°43'01.86"N 0°36'03.94"W

What is the expected result?

Should be show pixelated satellite imagery.

What happens instead?

A black area with cross in the middle.

Please provide any additional information below. Attach a screenshot if possible.

Many area in Mapbox satellite show pixelated satellite imagery , but in this area (35°43'01.86"N 0°36'03.94"W) and its environs is show black area with cross in the middle instead , please fix this problem.

URL:http://josm.openstreetmap.de/svn/trunk
Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2016-01-06 17:30:31 +0100 (Wed, 06 Jan 2016)
Build-Date:2016-01-06 16:32:31
Revision:9329
Relative:URL: ^/trunk

Identification: JOSM/1.5 (9329 fr) Windows 7 64-Bit
Memory Usage: 212 MB / 989 MB (44 MB allocated, but free)
Java version: 1.8.0_60, Oracle Corporation, Java HotSpot(TM) Client VM
Dataset consistency test: No problems found

Plugins:
- apache-commons (31895)
- ejml (31895)
- geotools (31895)
- jts (31772)
- opendata (31937)
- reverter (31897)
- turnrestrictions (31895)
- utilsplugin2 (31895)

[anonymous]

Hi users , can you fix this problem ???

[stoecker]

Too early - the tag based mechanism seems not to work for MapBox, added a checksum based one, see [o32021].

[stoecker]

In 9610/josm:

fix #12425 - add checksum based no-tile detection

[stoecker]

See [o32022] - Fix handling of multiple identical headers with different values.

[stoecker]

In 9613/josm:

fix #12437 - see #12425 - fix handling of equal no tile headers with different values - hope the related josm config change does not break anything

[bastiK]

Replying to stoecker:

Too early - the tag based mechanism seems not to work for MapBox, added a checksum based one, see [o32021].

No, works fine. Have you checked the http headers returned by the server?

Replying to stoecker:

In 9613/josm:

fix #12437 - see #12425 - fix handling of equal no tile headers with different values - hope the related josm config change does not break anything

Please check if it properly saved to the preferences and to a session file. (probably not)

[Don-vip]

it doesn't work at all on my setup, even with Dirk's changes:

I get complete black tiles starting from z18 (no cross icon):

​http://b.tiles.mapbox.com/v4/openstreetmap.map-inh7ifmo/18/130634/103193.png?access_token=pk.eyJ1Ijoib3BlbnN0cmVldG1hcCIsImEiOiJncjlmd0t3In0.DmZsIeOW-3x-C5eX-wAqTw

[bastiK]

You can verify that you have the updated entry by saving the imagery layer as a session and inspecting it in an editor.

[Don-vip]

right I forgot to purge the cache. It works fine now :)

[stoecker]

Replying to bastiK:

Replying to stoecker:

Too early - the tag based mechanism seems not to work for MapBox, added a checksum based one, see [o32021].

No, works fine. Have you checked the http headers returned by the server?

I meant as this is the third time to fix this issues, that this ETag is not reliable at all for the purpose of detecting no-tiles.

Please check if it properly saved to the preferences and to a session file. (probably not)

Seems not. But that has no real impact ATM, as the saved values aren't used anyway, but overwritten on each start. Should be fixed nevertheless.

[bastiK]

Replying to stoecker:

Replying to bastiK:

Replying to stoecker:

Too early - the tag based mechanism seems not to work for MapBox, added a checksum based one, see [o32021].

No, works fine. Have you checked the http headers returned by the server?

I meant as this is the third time to fix this issues, that this ETag is not reliable at all for the purpose of detecting no-tiles.

Okay, understood. In any case, a checksum may be useful later, when a server does not provide useful headers in the future.

Please check if it properly saved to the preferences and to a session file. (probably not)

Seems not. But that has no real impact ATM, as the saved values aren't used anyway, but overwritten on each start. Should be fixed nevertheless.

Only entries with an id are auto-updated. If the user changes the name or url, the id is dropped (otherwise this change would be reverted on next start). Layers saved to a session file aren't auto-updated either.

[stoecker]

Replying to bastiK:

Only entries with an id are auto-updated. If the user changes the name or url, the id is dropped (otherwise this change would be reverted on next start). Layers saved to a session file aren't auto-updated either.

I know. Leaving #12437 open for this - when nobody complains till release we can close it, otherwise we need to update old prefs.