First try toward a "travis-ci" continous integration

[chatelao]

I did several steps towards a "continuos integration" on www.travis-ci.com:

• https://travis-ci.com/chatelao/maposmatic-vagrant/builds/131654473

This steps already work more or less:

1. "/vagrant" independent location run (Defined as "~travis/USER/REPO")
2. Automatic download "Monaco.latest.pdf" before test run
3. Setup PostGre-PostGIS 11-2.5 database
4. Disable of "places" load (diskspace issue)
5. Run test outside "provision.sh" (travis adapted process)
6. Some more logging ...

Problem:

• Now the step calculating the bbox fails (eval b=$bbox) and I have no clue why. - If anyone could help would be great.

[hholzgra]

provision.sh was missing the "#! /bin/bash" hash bang line to enforce execution with bash. Looks as if vagrant is using bash for shell provisioning scripts by default, but when using the system default shell /bin/sh this can indeed easily break as that's usually not bash anymore on current distributions, e.g. on Ubuntu it is a symlink to /bin/dash, the Debian Almquist shell, instead.

The bounds / bbox calculation is using bash specific array syntax, so it is indeed bound to fail when executed by a different shell.

I just pushed commit ad6fa4a that should fix this.

[hholzgra]

There were also some other issues with the bbox code, e.g. "City search" did not work correctly anymore. This has been fixed over the weekend, also the bbox code has been extended to also determine simplified polygon data bounds in addition to simple bbox.

It does so by looking for the largest polygon in the imported data set, assuming that this is the true import border. This is true for all regional extracts from Geofabrik, but would not necessarily be true for other extracts like e.g. those created by the BBike site ...

See also:

https://blog.osm-baustelle.de/index.php/2019/10/13/data-area-bounds/

[chatelao]

Thanks. I will check this out. Am Mo., 14. Okt. 2019 um 12:29 Uhr schrieb Hartmut Holzgraefe < [email protected]>:

…

There were also some other issues with the bbox code, e.g. "City search" did not work correctly anymore. This has been fixed over the weekend, also the bbox code has been extended to also determine simplified polygon data bounds in addition to simple bbox. It does so by looking for the largest polygon in the imported data set, assuming that this is the true import border. This is true for all regional extracts from Geofabrik, but would not necessarily be true for other extracts like e.g. those created by the BBike site ... See also: https://blog.osm-baustelle.de/index.php/2019/10/13/data-area-bounds/ — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#17?email_source=notifications&email_token=AASY6XCQJ7QP3EZ2IZ724PDQORCYNA5CNFSM4JAM6DFKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBEC3NY#issuecomment-541601207>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AASY6XARKEQJACQRUUCZ3ETQORCYNANCNFSM4JAM6DFA> .

-- ---------------------------------------------------------- Olivier Châtelain-Gmür Blockweg 8, 3007 Bern, Switzerland Home: +41 (0) 31 371 86 69 Mobile: +41 (0) 79 726 08 60 Mailto: [email protected] ----------------------------------------------------------