Cadastre tutorial: JS client tries to load from 127.0.0.1 instead of remote server

[fnicollet]

Hello, After this step:

vts /var/vts/store/stage.melown2015 --add --tileset http://127.0.0.1:8070/mapproxy/melown2015/surface/cadastre/srtm --top

The JS viewer tried to request the tiles from 127.0.0.1 and fails (the server is a different machine)

I get errors like:

?pos=obj,14.608985,50.152277,fix,0.00,-66.28,-86.64,0.00,226.97,45.00:1 XMLHttpRequest cannot load http://127.0.0.1:8070/mapproxy/melown2015/surface/cadastre/srtm/0-0-0.meta?0. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://10.1.21.210:8070' is therefore not allowed access. The response had HTTP status code 502.

When I try to add it again, I get an error message:

vts@BG-test-soft-3D-FN:~/store/map-config$  vts /var/vts/store/stage.melown2015 --add --tileset http://10.1.21.210:8070/mapproxy/melown2015/surface/cadastre/srtm --top
2017-07-24 19:05:37 I3 [3636(main)]: Requested to add remote tileset pointing to "http://10.1.21.210:8070/mapproxy/melown2015/surface/cadastre/srtm". Generating temporary remote tileset. {vts.cpp:add():1674}
vts: Tileset <cadastre-srtm> already present in storage "/var/vts/store/stage.melown2015". Use version bumping to introduce new version. @{change.cpp:addTileset():840}

It seems like I can't just remove it and I need to publish a new version. How do you achieve that?

Thanks, Fabien

[vaclavblazek]

Hello,

there are 3 options how to change URL of remote tileset:

1. Use relocation support. Recommended.

   $ vts /var/vts/store/stage.melown2015 --relocate --rule http://127.0.0.1:=http://10.1.21.210:

   Explanation: Relocate traverses tree of tileset inside storage and tries to apply provided rules to references in them. In your case it hits remote tileset cadastre-srtm and sees its URL matching the prefix http://127.0.0.1: which replaces with http://10.1.21.210: as instructed.

   Relocate doesn't check the URL validity. You can add parameter --dryRun to see what it would do without making any permanent changes.

2. Remove offending tileset and replace it with another one. Not ideal, since it must reregenerate glues again. It is OK for small tilesets like yours but a showstopper for complex data that take long time to glue together. To remove, run:

   $ vts /var/vts/store/stage.melown2015 --remote --tileset cadastre-srtm

   where cadastre-srtm is tileset's identifier (do not use its URL). If you used an invalid identifier you did not get an error because remove operation is tolerant. You can query content of storage by

   $ vts /var/vts/store/stage.melown2015

   After successful removal of offending tileset add it again, using right IP address this time.

3. Manually update URL in tileset's tileset.conf. Hackish. This is manual version what rellocate does however we do no recommend it since it is not a clean way.

This tutorial was meant for running on localhost therefore there is no information about how to reflect different IP/host/port in remote tileset URL. Ladislav is going to include such information in the tutorial soon.

The important rule is that remote tileset's URL must be in the form to be presented to users from outside since the URL is used verbatim in generate mapConfig.json. There are ways how to rewrite addresses during operations like glue generation for optimization purposes but is is out of scope of this tutorial.

[fnicollet]

Thanks!

I tried option number 1, and it seems to have worked. When I do "vts --map-config cadastre", I can see that the URLs have changed. But I tried stopping and restarting the "vts-backend-mapproxy", but the browser still tries to load 127.0.0.1 And indeed, this URL still returns 127.0.0.1:

http://10.1.21.210:8070/store/map-config/cadastre/mapConfig.json

Is there a "cache" on the stores? How to get it updated?

Thanks, Fabien

[ladislavhorky]

Hi, if the result of vts --map-config cadastre looks fine, you should only need to touch the storage view.

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

That way, when you access the mapConfig.json again, the vtsd will find out that something has changes and will reload the configuration. Now you may be still getting the old mapConfig.json.

[fnicollet]

ok, I executed the touch but then I had to restart the server for it to understand that it changed. Sould --relocate not "touch" automatically the storage to indicate that it changed something (if it did)? Might be a nice thing to add as it's not really obvious that you need to manually tell the stores that it changed

[ladislavhorky]

Yes, the --relocate will probably touch the storage.conf within the storage which has the same effect.

The restart after the touch should not be necessary - I'll check with @vaclavblazek on that - but if you are in a browser, you may need harder reload (e.g. CTRL + SHIFT + R) to get through browser caches.

[fnicollet]

I'm already using the Disable Cache option the Chrome Dev Tools, so browser cache shouldn't be the source of the issue

Le 25 juil. 2017 12:53, "Ladislav Horký" notifications@github.com a écrit :

Yes, the --relocate will probably touch the storage.conf within the storage which has the same effect.

The restart after the touch should not be necessary - I'll check with @vaclavblazek https://github.com/vaclavblazek on that - but if you are in a browser, you may need harder reload (e.g. CTRL + SHIFT + R) to get through browser caches.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Melown/workshop/issues/9#issuecomment-317702175, or mute the thread https://github.com/notifications/unsubscribe-auth/ABLtoez-N5Uo5aFRvA6rQgn8O0m5k4oXks5sRcksgaJpZM4OheLK .

[fnicollet]

Closed as solved (tutorial clarified and relocate option)