Skip to content
This repository has been archived by the owner on Mar 8, 2023. It is now read-only.

Satellite/vector data misalignment #2019

Closed
brent-williams opened this issue Jan 1, 2021 · 7 comments
Closed

Satellite/vector data misalignment #2019

brent-williams opened this issue Jan 1, 2021 · 7 comments
Labels
HARP-13586 wontfix This will not be worked on

Comments

@brent-williams
Copy link

Overlaying HERE satellite & vector data shows a clear systematic misalignment at some zoom levels.

To reproduce, overlay Vector Tile API data over e.g. the 'datasource_satellite-tile' example by adding the code below. There is a clear bias at many zoom levels whereby the vectors are drawn several pixels above and to the left of the satellite data.

  const omvDataSourceStreets = new OmvDataSource({
    baseUrl: "https://vector.hereapi.com/v2/vectortiles/base/mc",
    apiFormat: APIFormat.HereV1,
    authenticationCode: apikey,
  });
  mapView.addDataSource(omvDataSourceStreets).then(() => {
    const styles: any = [
      {
        when: `$geometryType ^= 'poly'`,
        technique: "solid-line",
        renderOrder: 2010,
        attr: {
          color: "#ffffff",
          lineWidth: "1px"
        }
      }
    ];
    omvDataSourceStreets.setStyleSet(styles);
    mapView.update();
  });

Expected reasonable correspondence between satellite & vector data or at least no systematic bias towards the upper-left.

Attached harp.gl example + Google Earth Pro for reference. Bias is clear everywhere but especially obvious on islands, a few circled in red for clarity. Taken on macOS Catalina, latest Chrome Version 87.0.4280.88 (Official Build) (x86_64), harp.gl 0.21.1.

a
b

@FraukeF
Copy link
Contributor

FraukeF commented Jan 4, 2021

Hi @brent-williams ,

thanks for reporting this, I can actually reproduce it also with the other raster tile formats, I ll create an internal issue to investigate this issue, and let you know when there is a solution.

@nzjony
Copy link
Member

nzjony commented Jan 13, 2021

@brent-williams , I did some investigation, and it seems there is an offset in our satellite images, but, as far as I can tell, it isn't related to harp.gl. I compared also in another internal renderer and got the same issue.

I also compared with a google satellite image, and there seems to be a 1px shift south east. I will ask internally to find who is responsible for this service and ask to resolve.

Thanks from my side to for your bug report!

2021-01-13-22-29.mp4

@brent-williams
Copy link
Author

@nzjony good to know, please advise when you have some more information. One pixel when viewing tiles straight on isn't so bad, but with harp.gl globe rendering zoomed out it results in the satellite being out by 4, 5, 6 pixels even, which of course looks terrible.

@nzjony
Copy link
Member

nzjony commented Jan 14, 2021

@brent-williams , will do.

Yes, agreed. I managed to see the shift even when changing zoom levels, see:

2021-01-14-09-50.mp4

And between 3 and 4 seconds, there seems to be a shift in the texture. Note, this example uses a storageLevelOffset of -1, so it makes the problem seem a bit worse. The problem is exaggerated in some cases because the vector data is simplified, which may explain the larger gaps you see.

I have asked internally and we will contact the team responsible for the image generation.

I wanted to suggest a 'fix', but using the storageLevelOffset, which basically lets you control how the zoom level dictates which storage level to request, but this seems broken. :(.

I will make a fix for this, and you can then at least configure a larger storageLevelOffset (if it doesn't affect performance in your case drastically) so that you can mitigate the problem somewhat.

nzjony added a commit that referenced this issue Jan 14, 2021
Signed-off-by: Jonathan Stichbury <2533428+nzjony@users.noreply.github.com>
@nzjony
Copy link
Member

nzjony commented Jan 14, 2021

@brent-williams , I fixed the bug with the storageLevelOffset and tested locally, and you can now see the difference. The storageLevelOffset set to 1 provides the closest match. This could be a good "fix", until the images themselves are corrected.

Screenshot 2021-01-14 at 11 25 31

Screenshot 2021-01-14 at 11 25 09

Screenshot 2021-01-14 at 11 24 52

nzjony added a commit that referenced this issue Jan 14, 2021
Signed-off-by: Jonathan Stichbury <2533428+nzjony@users.noreply.github.com>
nzjony added a commit that referenced this issue Jan 14, 2021
Signed-off-by: Jonathan Stichbury <2533428+nzjony@users.noreply.github.com>
nzjony added a commit that referenced this issue Jan 14, 2021
Signed-off-by: Jonathan Stichbury <2533428+nzjony@users.noreply.github.com>
@brent-williams
Copy link
Author

@nzjony nice work thanks for the fast workaround! Still looking forward to corrected imagery of course to eliminate the 4x/16x oversample.

nzjony added a commit that referenced this issue Jan 14, 2021
Signed-off-by: Jonathan Stichbury <2533428+nzjony@users.noreply.github.com>
@stale
Copy link

stale bot commented Mar 19, 2021

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.

@stale stale bot added the wontfix This will not be worked on label Mar 19, 2021
@stale stale bot closed this as completed Jun 3, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
HARP-13586 wontfix This will not be worked on
Projects
None yet
Development

No branches or pull requests

3 participants