[DEV] unittests: compare map files with osmium in Windows, park static files, have static geofabrik .json

[treee111]

This PR…

• a long awaitet change parking static files
• might be an enabler for using osmium-tool in Windows for file processing as well and maybe not needing osmium-tool to be installed via brew in macOS ?!

Considerations and implementations

compare map files with osmium in Windows

comparing on Windows was handled solely with filecmp.cmp:

wahooMapsCreator/tests/test_generated_files.py

Lines 182 to 186 in 90b8657

	# some file extensions can not be comapared using osmium
	if given_file.split('.')[-1] in no_osmosis_file_extensions or \
	platform.system() == "Windows":
	self.assertTrue(filecmp.cmp(given_file, calculated_file,
	shallow=False), f'not equal: {calculated_file}. Using filecmp.cmp.')

After implementing geofabrik-only processing, the boundaries of the bounding boxes are calculated instead of taken from the static tile .json files in the repo.
The calculation via num2deg in geofabrik.py is not rounded and thus this is the result:

wahooMapsCreator/tests/test_geofabrik.py

Lines 59 to 62 in 90b8657

	item_1 = {'x': 138, 'y': 100, 'left': 14.0625, 'top': 36.59788913307021,
	'right': 15.46875, 'bottom': 35.4606699514953, 'countries': ['italy', 'malta'],
	'urls': ['https://download.geofabrik.de/europe/italy-latest.osm.pbf',
	'https://download.geofabrik.de/europe/malta-latest.osm.pbf']}

using static .json files, this would be the values for top: 36.597889 and bottom 35.46067. Because of this difference, the split-malta.osm.pbf and split-malta-names.osm.pbf were not equal in Windows because of the comparison using filecmp.cmp. I'll keep it not rounded and compare via osmium as doing in macOS some time already

have static geofabrik .json

equal to the other prepared files before running test_generated_files.py, geofabrik.json is also handled now.

park static files

Unittests run with older map, land polygons and geofabrik files. After running test_generated_files.py, map files and land polygons need to be downloaded again if having max. days e.g. 100 or 24. With this PR, the actual productive files are parked, then the unittests prepared, run and afterwards the parked files are copied back into productive location ;-)

How to test

1. run unittests. Create updated gdal-dev environment first.

Pull Request Checklist

• Reviewed the Contributing Guidelines
  • Especially the Pull-Requests section
• Commits (and commit-messages) are understandable
• Tested with macOS / Linux
• Tested with Windows