Decoder URL not respected

My harp.gl app is not hosted at the root path - i.e https://mywebsite.com/. It is a few levels down with some dynamic parameters in-between. Because of this I have to manually set the decoder path to something like this:

const decoderUrl = window.location.origin + "/decoder.bundle.js"

The MapView and VectorTile's decoderUrl/concurrentDecoderScriptUrl parameters are set to use the snippet above. This works fine! But when adding a FeatureDatasource to the map it is searching for the decoder at the current route. It doesn't seem to respect the URL gave it.

A few additional notes:

I'm using React with Reach Router
My decoder is in the root of the public folder
I've upgraded to 0.21.1 from 0.14.0 where this wasn't a problem - I actually didn't have to tell harp.gl where my decoder was located.

Steps to reproduce the behavior:

Create a MapView on a route other than root
Specify the location of the decoder.bundle.js
Try adding a FeatureDataSource

Here you can see that something is searching for the decoder at the current route when it should use the snippet above.

OS: Windows 10
Browser: Chrome
Version 87.0.4280.66

I managed to fix the issue, although I don't believe it should be marked as a solution since it's quite unintuitive. I needed to set both workerTileUrl & concurrentDecoderScriptUrl when creating a new FeaturesDataSource.

new FeaturesDataSource( { gatherFeatureAttributes: true, name: this.name, styleSetName: this.id, workerTilerUrl: decoderUrl, concurrentDecoderScriptUrl: decoderUrl }
Any thoughts on this would be great!

Thanks for creating the issue @harrycollin and glad to see you still around. I take a look and see if we can improve things.

I took a look, basically they are doing different things, i.e. the workerTilerUrl points to the web worker handling the tiling of the GeoJson (which the FeaturesDataSource uses) and the concurrentDecoderScriptUrl points to to the web worker handling the decoding of tiles.

Probably in your decoder you have something like:

VectorTileDecoderService.start();
GeoJsonTilerService.start();

Some options we could look to implement:

set the workerTilerUrl to the concurrentDecoderScriptUrl, if the workerTilerUrl isn't directly configured. <-- could however cause some confusion of the GeoJsonTilerService is moved to another decoder but the workerTilerUrl is configured.
specify a root directory for the web worker (assumes that the decoder script is called decoder.bundle.js)

I will ask in the team if there is a consensus, or maybe we wait until there is more complaint from the community.

Hey @nzjony, also glad to see you're around 😂. That you for clearing this up! I do in fact have both services running in my decoder bundle. I think it would be a good idea if decoder detection could be expanded to look not only at the current route/path but also at the root of the app. Maybe this is asking too much, but it would be convenient!

@harrycollin , this passes the script url to the Worker:

harp.gl/@here/harp-mapview/lib/ConcurrentWorkerSet.ts

Line 199 in 5c22a7c

    
           const workerPromise = WorkerLoader.startWorker(this.m_options.scriptUrl, timeout).then(

Where it eventually calls: const worker = new Worker(scriptUrl);

The ConcurrentWorkerSet is used by both the ConcurrentDecoderFacade and ConcurrentTilerFacade. Possibly we could introduce some way to configure the root app directory, and this is some sort of global string that can be accessed anywhere.

Actually, I wonder if this would work:

harp.gl/@here/harp-utils/lib/UrlPlatformUtils.ts

Line 15 in 5c22a7c

export function getAppBaseUrl() {

@nzjony Maybe this should be moved somewhere else since the title of the issue wasn't relevant. What do you think?

Hi @harrycollin

As @nzjony is out of office for a couple of weeks, I wanted to follow up, to see if using "getAppBaseUrl()" as @nzjony proposed solved your issue?

Hey @FraukeF, sorry for the late reply on this. It doesn't appear to work. The only thing that works for me is this:
const decoderUrl = window.location.origin + "/decoder.bundle.js"

Perhaps I'm using it wrong?

Hi @harrycollin,

thanks for your reply, I created an internal task to look into the issue, we ´ll let you know once there is a solution in place.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.