| Age | Commit message (Collapse) | Author |
|---|
|
With fietsboek.ini, those commands become very ergonomic to use (as long
as the user has the configuration at the default place)
|
|
|
|
|
|
This makes it easy to use the scripts without always having to specify
-c.
The error message could be a bit better if fietsboek.ini is not found
and -c is not given, maybe we can fix that later.
|
|
|
|
|
|
Turns out you need to supply an actual empty array.
While we're playing with the CI configuration, we also move the
deprecated global image/cache/before_script sections into the "default"
section.
|
|
|
|
|
|
Yay, types! (And a lot of escape hatches)
|
|
This makes it consistent with the other scripts (fietsupdate,
fietscron), and makes the argument parsing setup a bit nicer to read.
|
|
|
|
|
|
I'm not the biggest fan of combining many package managers, but the
JavaScript libraries (Bootstrap, Bootstrap-Icons, later the @types
modules and Leaflet) are easy to get via npm, so maybe we can use that
to our advantage and have npm at least download them.
|
|
|
|
|
|
|
|
|
|
Currently, the test seems flaky on CI due to
playwright._impl._api_types.Error: Clicking the checkbox did not
change its state
Maybe this is the change that will fix it?
|
|
This gets the intent across clearer
|
|
|
|
|
|
|
|
|
|
While it shouldn't change the outcome of the test, it might make the
test less flaky, as the expect call will wait until the page is loaded -
which also indicates that the data is updated. Without this, the test
depends on the backend being "fast enough" with applying the
transformation.
|
|
|
|
|
|
|
|
This helps if the upload/editing process fails, so that we don't end up
with orphan data directories (probably the most important change!), or
superfluous image files.
|
|
Getting ready for SQLAlchemy 2.0!
|
|
|
|
|
|
For some reason, I have GPX tracks that have the first two points be
~100 meters apart in elevation, but only ~20 meters apart in distance.
This is quite unrealistic and produces pretty bad height plots (almost
as bad as the zero elevation).
Since the issue is very related, and the fix is pretty much the same, I
thought it would be a good idea to adapt the FixNullElevation
transformer to handle this case as well. For reference, "the internet"
says that the maximum slope for a MTB is ~15% to ~35%, depending on the
conditions - with 35% being pretty steep. I think it's fair to throw
away elevations that exceed 100% (basically a 45° angle upwards),
especially since we only discard them at the start and end.
|
|
|
|
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.
|
