Getting "500 Internal Server Error" while accessing Melown Maps...

[rushikesh-22]

The error started appearing since 4-5 days only. Previously it was working fine.

The exact error is:

Access to XMLHttpRequest at 'https://rocksim.com/mapproxy/melown2015/tms/melown/bing-world/boundlayer.json' from origin 'http://127.0.0.1:5500' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.

-> refer image_01 Image_01

Code: // create vts-browser. this.browser = vts.browser('visualizer_mapDiv', { map: 'https://rocksim.com/store/map-config/bing-terrain/mapConfig.json', minViewExtent:GlobalData.CloseViewZoomExtent //allow camera little bit closer });

We even tried it from the examples given on the source website. https://github.com/melowntech/vts-browser-js/wiki/Examples But it is also not working. Refer to following image for error:

Let me know if need any other information as well. Any help would be appreciated. Thank you...

[jrjdavidson]

Access to XMLHttpRequest at 'https://rocksim.com/mapproxy/melown2015/tms/melown/bing-world/boundlayer.json' from origin 'http://127.0.0.1:5500' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.

Sounds like a server configuration issue. I think there is a line to prevent issues like this in the original nginx sites-enabled configuration?

We even tried it from the examples given on the source website. https://github.com/melowntech/vts-browser-js/wiki/Examples But it is also not working. Refer to following image for error:

Unfortunately, the melown SSL certificate has not been renewed for some time now. You could try running an official example by using your own server mapconfig.json file.

[VrushalNCT]

Hello @jrjdavidson ,

It doesn't seem to be an SSL certificate or Nginx configuration issue. Because it works on the same server with other remote tiling services like maptiler or Mapbox. It doesn't work only with Bing maps.

I'm attaching two configurations that we've done (one is bing maps and one is maptiler). bing maps don't work but maptiler works just fine. You may give it a try on the following links where we can try to load these maps.

maptiler.json bingMap.json

Maptiler - https://rocksim.com/mapproxy/melown2015/tms/melown/maptiler/ Bing Maps - https://rocksim.com/mapproxy/melown2015/tms/melown/bing-world/

We're also trying to integrate these maps on top of our terrain DEM data. so our map configs are as follows. with the same terrain surface, the bing maps don't work, and Maptiler works.

bingMapConfig.json malptilerMapConfig.json

Maptiler - https://rocksim.com/store/map-config/terrain/ Bing Maps - https://rocksim.com/store/map-config/bing-terrain/

The thing is it was working all good so far but suddenly it stopped working.

Could you please help us resolve the issue? Let us know you need more information.

P.S. - we observed that it intermittently works but, is completely random, and that too it works just once in 100 reloads. We also noticed following error with bing maps.

[jrjdavidson]

have you created and added a bing maps API key toy your configuration?

[VrushalNCT]

Yes, we did, I just made it ***** before posting it here.

[jrjdavidson]

Sorry, I really don't know what the issue could be. Here are some ideas that might or might not help.

You might be able to get some information from the mapproxy or nginx logs that you can find on the server machine. According to the tutorials, the mapproxy logs can be found at /var/log/vts/mapproxy.log. The same tutorial also recommends testing your config by running using the vts tools e.g.:

cd /var/vts/store/map-config
vts --map-config cadastre

From the original error, it looks like there is something going from http to https scheme internally?

It also looks like you are running ubuntu 1.14, I can tell you that on our 1.18 and 1.20 servers bing maps still works fine.

Is it possible that you have exceeded your bing maps api quota?

hope this helps

[rushikesh-22]

I tried the running this command:

cd /var/vts/store/map-config
vts --map-config cadastre

But I got this error: ubuntu@ip:;#####: /var/vts/store/map-config$ vts --map-config cadastre Path "cadastre" cannot produce any mapConfig.

[jrjdavidson]

In your case, you would have to replace the variable 'cadastre' with the name of your map in your store. Was it 'bing-terrain' in your case?

In any case, have you check whether you exceed your bing-maps quota? That seems to be the most likely cause to a sudden change in functionality.

[rushikesh-22]

I ran this command and I got this: /var/vts/store/map-config$ vts --map-config bing-terrain { "bodies" : { "Earth" : { "atmosphere" : { "colorHorizon" : [ 158, 206, 255, 255 ], "colorZenith" : [ 62, 120, 229, 255 ], "thickness" : 100000, "visibility" : 100000 }, "class" : "planet", "comment" : "Earth, Sol III, M-class planet.", "defaultGeoidGrid" : "egm96_15.gtx", "parent" : "Sun" }, "Sun" : { "class" : "star", "comment" : "Sol, G2V main-sequence star." } }, "boundLayers" : { "melown-bing-world" : "https://rocksim.com/mapproxy/melown2015/tms/melown/bing-world/boundlayer.json" }, "credits" : { "auto-http-www-viewfinderpanoramas-org" : { "copyrighted" : false, "id" : 32769, "notice" : "http://www.viewfinderpanoramas.org/" } }, "freeLayers" : {}, "glue" : [], "namedViews" : {}, "params" : {}, "position" : [ "obj", 0.00019900000000000001, -0.52512099999999995, "fixed", 111.77, 0, -90, 0, 16581825.43, 45 ], "referenceFrame" : { "body" : "Earth", "description" : "Earth, global geographic reference frame (Melown 2015)", "division" : { "extents" : { "ll" : [ -7500000, -7500000, -7500000 ], "ur" : [ 7500000, 7500000, 7500000 ] }, "heightRange" : [ -12000, 9500 ], "nodes" : [ { "extents" : { "ll" : [ -20037508.342789002, -10018754.171394 ], "ur" : [ 20037508.342789002, 10018754.171394 ] }, "id" : { "lod" : 0, "position" : [ 0, 0 ] }, "partitioning" : { "00" : { "ll" : [ -20037508.342799999, -9467848.3472000007 ], "ur" : [ 20037508.342799999, 9467848.3472000007 ] }, "01" : { "ll" : [ -20037508.342799999, 9467848.3471611794 ], "ur" : [ 20037508.342799999, 10018754.171399999 ] }, "10" : { "ll" : [ -20037508.342799999, -10018754.171399999 ], "ur" : [ 20037508.342799999, -9467848.3471611794 ] } }, "srs" : "eqc-wgs84" }, { "extents" : { "ll" : [ -20037508.342789002, -20037508.342789002 ], "ur" : [ 20037508.342789002, 20037508.342789002 ] }, "externalTexture" : true, "id" : { "lod" : 1, "position" : [ 0, 0 ] }, "partitioning" : "bisection", "srs" : "pseudomerc" }, { "extents" : { "ll" : [ 278600, 278600 ], "ur" : [ 3721400, 3721400 ] }, "externalTexture" : true, "id" : { "lod" : 1, "position" : [ 0, 1 ] }, "partitioning" : "bisection", "srs" : "steren-wgs84" }, { "extents" : { "ll" : [ 278600, 278600 ], "ur" : [ 3721400, 3721400 ] }, "externalTexture" : true, "id" : { "lod" : 1, "position" : [ 1, 0 ] }, "partitioning" : "bisection", "srs" : "steres-wgs84" } ] }, "extensions" : { "wmts" : { "content" : "pseudomerc", "projection" : "urn:ogc:def:crs:EPSG::3857", "wellKnownScaleSet" : "urn:ogc:def:wkss:OGC:1.0:GoogleMapsCompatible" } }, "id" : "melown2015", "model" : { "navigationSrs" : "geographic-wgs84", "physicalSrs" : "geocentric-wgs84", "publicSrs" : "geographic-wgs84-egm96" }, "parameters" : { "metaBinaryOrder" : 5 }, "version" : 1 }, "rois" : [], "srses" : { "eqc-wgs84" : { "comment" : "Projected, wgs84 equidistant cylindrical (epsg:4087)", "srsDef" : "+proj=eqc +lat_ts=0 +lat_0=0 +lon_0=0 +x_0=0 +y_0=0 +ellps=WGS84 +datum=WGS84 +units=m +no_defs", "type" : "projected" }, "geocentric-wgs84" : { "comment" : "Geocentric, WGS84 (epsg:4978)", "srsDef" : "+proj=geocent +datum=WGS84 +units=m +no_defs", "type" : "cartesian" }, "geographic-wgs84" : { "comment" : "Geographic, WGS84 (epsg:4326)", "srsDef" : "+proj=longlat +datum=WGS84 +no_defs", "type" : "geographic" }, "geographic-wgs84-egm96" : { "comment" : "Geographic, WGS84 with EGM96 vertical (epsg:4326+5773)", "geoidGrid" : { "definition" : "geographic-wgs84-egm96-geoidgrid.jpg", "extents" : { "ll" : [ -180, -90 ], "ur" : [ 180, 90 ] }, "srsDefEllps" : "+proj=longlat +datum=WGS84 +no_defs", "valueRange" : [ -107, 85.400000000000006 ] }, "srsDef" : "+proj=longlat +datum=WGS84 +geoidgrids=egm96_15.gtx +vunits=m +no_defs", "type" : "geographic" }, "pseudomerc" : { "comment" : "Projected, Web/Pseudo Mecator (epsg:3857)", "periodicity" : { "period" : 40075016.685578004, "type" : "X" }, "srsDef" : "+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=@null +wktext +no_defs", "type" : "projected" }, "steren-wgs84" : { "comment" : "Projected, UPS north (epsg:32661)", "srsDef" : "+proj=stere +lat_0=90 +lat_ts=90 +lon_0=0 +k=0.994 +x_0=2000000 +y_0=2000000 +datum=WGS84 +units=m +no_defs", "type" : "projected" }, "steres-wgs84" : { "comment" : "Projected, UPS south (epsg:32761)", "srsDef" : "+proj=stere +lat_0=-90 +lat_ts=-90 +lon_0=0 +k=0.994 +x_0=2000000 +y_0=2000000 +datum=WGS84 +units=m +no_defs", "type" : "projected" } }, "surfaces" : [ { "2d" : { "creditsUrl" : "https://rocksim.com/mapproxy/melown2015/surface/melown/world_dem/{lod}-{x}-{y}.credits?0", "maskUrl" : "https://rocksim.com/mapproxy/melown2015/surface/melown/world_dem/{lod}-{x}-{y}.mask?0", "metaUrl" : "https://rocksim.com/mapproxy/melown2015/surface/melown/world_dem/{lod}-{x}-{y}.2dmeta?0", "orthoUrl" : "https://rocksim.com/mapproxy/melown2015/surface/melown/world_dem/{lod}-{x}-{y}-{sub}.ortho?0" }, "id" : "world_dem", "lodRange" : [ 1, 21 ], "meshUrl" : "https://rocksim.com/mapproxy/melown2015/surface/melown/world_dem/{lod}-{x}-{y}.bin?0", "metaUrl" : "https://rocksim.com/mapproxy/melown2015/surface/melown/world_dem/{lod}-{x}-{y}.meta?0", "navUrl" : "https://rocksim.com/mapproxy/melown2015/surface/melown/world_dem/{lod}-{x}-{y}.nav?0", "textureUrl" : "https://rocksim.com/mapproxy/melown2015/surface/melown/world_dem/{lod}-{x}-{y}-{sub}.jpg?0", "tileRange" : [ [ 0, 0 ], [ 1, 0 ] ] } ], "textureAtlasReady" : false, "version" : 1, "view" : { "description" : "", "freeLayers" : {}, "surfaces" : { "world_dem" : [ "melown-bing-world" ] } }, "virtualSurfaces" : [] }

[rushikesh-22]

Hi there,

As per our discussion, we've recently set up a new VTS server with VTS version using the link "melown-focal.list", running on UBUNTU 20.04.6 LTS. We've also added Bing Maps along with other maps. While all other maps are functioning smoothly, we're encountering an error specifically with Bing Maps.

The current error message reads: "Uncaught error: No value provided for variable {culture}." We've attempted solutions such as restarting VTS and reviewing logs. In the logs, we've identified an error related to reading a resource file:

2024-04-17 01:09:24 E2 [73660(updater)]: Unable to read resource from file "/var/vts/mapproxy/store/melown2015/melown/bing-world/resource.json": <* Line 36, Column 2
  Missing ',' or '}' in object declaration

Our map configuration is as follows: Please notice that we have also tried adding parameter for culture = en-US

{
   "comment": "Microsoft Bing Maps orthophoto",
   "credits": ["microsoft"],
   "definition": {
      "metadataUrl": "http://dev.virtualearth.net/REST/v1/Imagery/Metadata/AerialWithLabels?culture=en-US&key=########"
   },
   "driver": "tms-bing",
   "group": "melown",
   "id": "bing-world",
   "referenceFrames": {
      "melown2015": {
         "lodRange": [2, 21],
         "tileRange": [[0, 0], [1, 1]]
      },
      "webmerc-projected": {
         "lodRange": [0, 21],
         "tileRange": [[0, 0], [1, 1]]
      }
   },
   "registry": {
      "credits": {
         "microsoft": {"id": 5, "notice": "{copy}{Y} Microsoft Corporation"}
      }
   },
   "type": "tms"
}

We're committed to resolving this issue without switching to another viewer service, as we've invested significant effort and time into building the application, which was functioning well until recently.

Additionally, we've learned that VTS has been archived and is no longer supported by Melown tech. We're concerned about other services and repositories. For instance, are the installer repositories, like the one we used for setting up VTS viewer using the command:

wget http://cdn.melown.com/packages/conf/melown-bionic.list

If these services are being discontinued, do we need to download them at our end as well ?

Kindly guide us on resolving the issue and also the necessary steps to ensure continuity. Your assistance is greatly appreciated.

[jrjdavidson]

the log error is for a malformed json file. Even if you fixed your mistake after mapproxy read the config file, the config files get frozen, so you might not be able to fix the resource with the same id. If I was you, I would try changing the id to 'bing-world2' and remove the culture key in your metadataUrl and see if that works.

As for the packages getting discontinued- I'm worried about the same thing, but there isn't much to do apart from preparing yourself, as you mentioned.

[rushikesh-22]

I made the changes in id, removed the culture in metaURL BUT still getting the same error. No value provided for variable {culture}.

[jrjdavidson]

You might have to remove the previous offending configuration? From the troubleshooting page

I fixed my resource definition but I see no change When mapproxy initializes resource for the first time, it freezes its configuration in store located at /var/vts/mapproxy/store. This is important in production environment and prevents accidental corruption or deletion of live resources but may it be counter-intuitive for beginners.

The resource is uniquely defined by its group and id combination. The easiest way to work around this configuration freezing is just to define a new (fixed) resource with slightly different id. An alternative is to stop mapproxy, e.g. by

sudo /etc/init.d/vts-backend-mapproxy stop then delete particular resource’s directory in /var/vts/mapproxy/store (or the whole /var/vts/mapproxy/store) and start mapproxy again.

[rushikesh-22]

We have tried this thing but it didn't work. Even we have freshly setup the Linux machine and then Bingmaps config with the URL NOT having culture variable. But it is not working. Is it working at your end ?

[jrjdavidson]

I have a Ubuntu 18 machine, last I checked the bing maps layer is still working fine

On Wed, 17 Apr 2024 at 20:39, rushikesh-22 @.***> wrote:

We have tried this thing but it didn't work. Even we have freshly setup the Linux machine and then Bingmaps config with the URL NOT having culture variable. But it is not working. Is it working at your end ?

— Reply to this email directly, view it on GitHub https://github.com/melowntech/vts-browser-js/issues/220#issuecomment-2060716199, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALFBMN4KNGYHUC3JBQNQ5CLY5YYLVAVCNFSM6AAAAABCUKWFL6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANRQG4YTMMJZHE . You are receiving this because you were mentioned.Message ID: @.***>

[rushikesh-22]

Okay, I am working on 20.04.6 LTS. I will downgrade it and retry. Maybe it will work.

[rushikesh-22]

Hi, while installing backend I am not able to get a package for 18.0 version. Do they have archived it ? If yes where to get one for installation ? I tried on this link http://cdn.melown.com/packages/conf/

[rushikesh-22]

ncircle@ncircletech:/etc/apt/sources.list.d$ sudo apt-get update 0% [Working] Hit:1 http://security.ubuntu.com/ubuntu bionic-security InRelease
Hit:2 http://in.archive.ubuntu.com/ubuntu bionic InRelease
Ign:3 https://cdn.melown.com/packages/repos melown-buster/ InRelease
Hit:4 http://in.archive.ubuntu.com/ubuntu bionic-updates InRelease
Err:5 https://cdn.melown.com/packages/repos melown-buster/ Release
404 Not Found [IP: 172.104.130.178 443] Hit:6 http://in.archive.ubuntu.com/ubuntu bionic-backports InRelease
Reading package lists... Done E: The repository ' https://cdn.melown.com/packages/repos melown-buster/ Release' does not have a Release file. N: Updating from such a repository can't be done securely, and is therefore disabled by default. N: See apt-secure(8) manpage for repository creation and user configuration details.

[jrjdavidson]

Not sure how to help with the ubuntu 18 install.

On your Ubuntu 20 server, did you try just the Aerial data without Labels? Now that I read your message again, it seems that vts just doesn't read and pass the culture queries which seem to be required. http://dev.virtualearth.net/REST/v1/Imagery/Metadata/Aerial?key=