Conversation
Don't use "full", say the actual zoom range.
| # Cities-only static database | ||
| # maps_search_static_db = "pop-1k-cities" | ||
| pop-1k-cities: "static-search.{{ maps_data_date }}.pop-1k-cities" | ||
| pop-1k-cities: "static-search.{{ maps_slow_data_date }}.pop-1k-cities" |
There was a problem hiding this comment.
Per the above comments this was supposed to be the "slow" date anyway. But I'll change it to the new "search data date" when I update search.
|
|
||
| ``` | ||
| maps_vector_quality: osm-full | ||
| maps_vector_quality: osm-z14 |
There was a problem hiding this comment.
Don't want to update z9->z11 in the README until I we try downloading it and get the file size as reported locally.
| def get_paths(base): | ||
| VECTOR_ZOOM_RANGE = "z00-z{{ '%02d' % maps_vector_max_zoom }}" | ||
| SATELLITE_ZOOM_RANGE = "z00-z{{ '%02d' % maps_satellite_max_zoom }}" | ||
| TERRAIN_ZOOM_RANGE = "z00-z{{ '%02d' % maps_terrain_max_zoom }}" |
There was a problem hiding this comment.
I know that we don't need zero-padding for any of the existing numbers but I want to future-proof it.
|
https://github.com/orblivion/iiab/actions/runs/24413611959/job/71316798194 At the end of Build Image: Any idea @chapmanjacobd ? I don't see any obvious actual cause. I looked for "error" above in the logs and found this, along with a few other thing that fail the same way. I'm guessing unrelated, since it didn't stop the installation right away: |
|
Ah I think you'll need to merge main back into this branch? although the tests are passing now? ah yes it's only on your branch-- So you don't need to do anything really... the tests pass in here which test the changes in your branch applied on top of master. If you want the error in your branch to go away you can merge master back in |
|
I converted this PR to draft, as @orblivion is reworking FQR (full quality region) aspects, which need to fit in with our new filename scheme! |
|
I think that covers it. I did a fair amount of Python and JS now for the FQR stuff so @chapmanjacobd your review would be valuable. |
| # date designations down the line. I just want one "slow" date to set all of | ||
| # these items *for now*. | ||
| # | ||
| maps_data_date: "2025-12-10" |
There was a problem hiding this comment.
no lingering references to maps_data_date anywhere, right?
There was a problem hiding this comment.
Double checked, nothing in the whole repo.
|
looks good |
|
Some followups I can do:
|
|
Testing with a couple different quality levels for world map. Not very high quality for time sake. Though I did test adding FQRs. I also tested deleting FQRs. Anything else I should try before we merge? |
Description of changes proposed in this pull request:
zoom_0-07toz00-07fullto (in the case of OSM)z00-z14. i.e. explicitly name the zoom levels.osm-z11option.So now the way this works:
As we add a new vector file and update the
vector_data_date, Ansible will download the new file and update the symlink that index.html looks for.FQRs are managed via the file
extracts.jsonwhichindex.htmlreads to know which FQR files exist. This PR changes the format ofextracts.jsonto include the date, whichindex.htmlnow needs to find the file, because it can no longer assume the date based onvector_data_date. There's no telling how old the FQRs are. The FQR managing script now will add the dates toextracts.jsonwhen it updates it. It is also a bit more careful about deleting them, in case stray files with different dates are somehow sitting around.Smoke-tested on which OS or OS's:
RasPi OS Trixie
Mention a team member @username e.g. to help with code review:
@holta