Gracefully handle 404 on VectorTile

[ahokinson]

When using a VectorTileFactory, it should be expected that some tiles do not have vector tile data and thus return a 404 error. This happens a lot in my own use.

Would it be possible to add an enum to the VectorTileFactory that could get passed to the TileErrorHandler which could control the debug level of exceptions?

The argument I can make in favor of this is that WebGL builds could end up with lots of errors in the JS console which looks bad to anyone looking.

[apavani]

Good suggestion!

[wilhelmberg]

@ahokinson a quick fix for you might be to check for 404s here:

mapbox-unity-sdk/sdkproject/Assets/Mapbox/Unity/Map/TileErrorHandler.cs

Lines 47 to 63 in 8852890

	// 1. aborted is always the first exception
	// additional exceptions are always caused by the request being aborted
	// show all of them as warnings
	// 2. 'Unable to write data' is another exception associated
	// with aborted requests: request finshed successfully but
	// was aborted during filling of local buffer, also show as warning
	if (
	e.Exceptions[0].Message.Contains("Request aborted")
	|| e.Exceptions[0].Message.Equals("Unable to write data")
	)
	{
	Debug.LogWarning(printMessage(e.Exceptions, e));
	}
	else
	{
	Debug.LogError(printMessage(e.Exceptions, e));
	}

and either log them as warnings (like we do with aborted requests) or shallow them (if 404 return;).

Would it be possible to add an enum to the VectorTileFactory that could get passed to the TileErrorHandler which could control the debug level of exceptions?

That's a good idea and I think verbosity levels should be implemented throughout the whole SDK not just tile requests, but that would be a big lift as we would have to go through the entire SDK and attach the verbosity level to all the places where errors/warnings could occur.

But we could start with the TileErrorHandler.

---

@apavani do you have resources to take a stab at that?

I'm thinking about exposing a dropdown setting in the config dialog like this:

• Log tile request errors:
  • None
  • As Information
  • As Warning
  • As Error

With the default set to Warning.

We still might have to have additional checks/dedicated handling of aborted requests as they happen quite frequently during rapid panning or fast changing of zoom levels.

[MiroMuse]

Closing this for now, let us know if you need anything else.

[ahokinson]

@MiroMuse, I don't understand why this issue was closed. While I could make the changes to my code locally, as @BergWerkGIS suggested, the issue persists in the SDK. I wouldn't mind doing another PR for this as long as someone agrees with my proposal.

[apavani]

@ahokinson That was perhaps by accident. @BergWerkGIS and I agree with you suggestion.
Can you please submit a PR so that we can work on this issue? Thanks!

[MiroMuse]

@ahokinson sorry about that! @apavani is right, closed in error. Looking forward to your PR!