| Age | Commit message (Collapse) | Author |
|---|
|
I don't like interweaving the HTML code into the business logic, so now
we can have that in the Jinja template.
Ideally, the list of definitions would be generated automatically from
the model attributes.
|
|
|
|
|
|
|
|
|
|
|
|
Those prefixes mainly exist to help browsers with their per-domain
connection limit [1]:
> Subdomains are used to help with browser parallel requests per domain
limitation
For us, we don't care about that limit, because we do not implement it
(server side at least). It's even better to not have those domains, as
otherwise our new connection limitation will get confused.
We might think about adding them back if the tile proxy is disabled,
but for now they seem to serve no purpose for us.
[1]: https://wiki.openstreetmap.org/wiki/Raster_tile_providers
|
|
This allows us to
1. Get better performance by re-using Keep-Alive connections instead of
re-opening one for each single tile
and
2. Better honor the usage policies of the tile servers by not hammering
them with many concurrent connections
|
|
|
|
|
|
|
|
|
|
|
|
|
|
So far it doesn't really do much yet, but it does have the machinery to
list the available transformers and run them. It also memorizes if the
transformers even need to be run at all, to save time if the current
configuration already matches.
The parameter UI still needs some work. This is fine because the first
transformer will not have any parameters (it's just the elevation fix).
We probably don't want to have a method that returns Markup, as that
makes it hard to implement localization in there, and the method would
need to be aware of bootstrap.
Another point to think about is documentation. I'd like some information
for the user what the "transformers" are, so we'll probably add a small
tagline and later extend the documentation with some more information (I
want a user chapter in there at some point anyway).
|
|
We don't need (and probably shouldn't have) all those executable bits
set.
|
|
|
|
|
|
If we install playwright without specifying a version, we'll get the
latest one, which might not be what the virtual env expects.
|
|
3.7 will reach EOL in June of 2023, so it doesn't really make too much
sense to forcefully stick with it for much longer - especially since
upgrading gives us a few nice things (walrus, type subscription on
builtins).
3.9 is shipped by Debian 11 (stable), so everything should be good.
|
|
We always use UTF-8, and this way we won't run into funky OS-dependent
encoding magic.
See also https://peps.python.org/pep-0686/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Note that those are not documented, but based on trial-and-error.
Terrain and Watercolor return 404 at the next zoom level, indicating
that this is the max that they support.
Toner does serve some tiles at level 18, but a lot of them return a 503.
|
|
Since we aliased the field layer_type to layer, we would need to use
type=... to set it. However, it is a bit confusing if we access it as
TileLayerConfig.layer_type, but set it with type=..., therefore let's
just turn on allow_population_by_field_name. This option lets us use
layer_type=... to set the field when initializing the object.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
We have so many nice docstrings, but they aren't really rendered
anywhere (expect locally in your IDE), as we did not include the API
docs anywhere.
This change uses sphinx-apidoc to generate autodoc stubs for Sphinx, so
that the docstrings are actually rendered to HTML. This is not perfect
yet (I'm not too happy about the default modules.rst simply listing one
package), but it is good enough for the start and makes it possible to
actually browse the docstrings in a browser.
|
|
|
|
|
|
This is code that needs to be repeated in possibly several places
(website, API, tests), so it makes sense to have those "high level
actions" a bit abstracted. edit.edit_images was already doing that to a
certain degree, but the code shouldn't have stayed in the view.
|
|
|
