

Your reply implies the article is critical of this, but it isn’t


Your reply implies the article is critical of this, but it isn’t
For your first (long) journeys, definitely plan in advance. And don’t rely on searching at a certain SOC without scoping out the frequency of chargers on your route. Where I am, this would never be a disaster, but it may end up with having to take a long detour, or being stuck on a very slow charger to be able to make progress. I guess you’re in Germany, where I don’t know the situation - probably decent. But there will be less densely populated areas which may still cause issues. In North America there are major routes with no chargers for more than a hundred miles which then requires a lot of care.
What I’m just getting it is that this level of care is often not necessary once you’re familiar with an area. And then perhaps the impetus for OSS solutions is lowered.
sorry I was talking imprecisely; I meant “extra steps” in the code, rather than as a practical workflow to follow.
For now I just use ABRP. It may be different for you, but I find that most journeys I do I only really need consider a subset of chargers - we are aiming to stop approximately every 2h to change drivers as my partner starts gnawing on the steering wheel before then. Those stops suggest a rough geographic area in which to look for chargers, and very often there are chargers exactly where we are stopping anyway. So I no longer feel like I need a really solid route-planner.
A model for energy usage at various speeds that you can apply across a route would still be really useful - I still use ABRP to tell me whether I can make a certain distance from a given state of charge. This will then probably not be as good on open data, as I don’tthink there are good open datasets for average traffic speeds (given time of day). The car’s own model of this is somewhat opaque so I don’t trust it too much.
I don’t know of one, but it sounds like something that could make use of the route-planning ability of Osmand with extra steps…
The administrative overhead and the overhead of engineering everything to with multiple vendors is what is massive
Dividing between providers is not what people would be doing if the resilience of cloud services were as is being memed about.
Doing so is phenomenally expensive.


I don’t believe it’s easier than rsync.
Was there a known issue there?
Are you really going to get defensively patronising over this? I think I’mma bounce, lol.
Yeah you might be right.
I should clarify I use GIMP. A lot! But this is one way it sucks. By this point I don’t know what other similar programs even have over it - it finally got adjustment layers after some decades. So if I can recognise this shortcoming anyone should be able to ;)
The other major thing was switching to single window mode. Floating windows for everything was absolutely batshit.
The first two sets of instructions are for drawing a disc, rather than a circle (a disc being a filled-in circle) and don’t extend to drawing a circle easily. The last method does, but it is about 10x as long. The traditional method for drawing a circle was to select the inner circle, save the selection to a channel, grow the selection by the pixel width of the stroke you want, subtract the saved selection, then fill. Wonderful /s
GIMP does not (unless I missed it in a ~recent update) have a shape tool like most image editors. The GIMP documentation in any case suggests using Inkscape for the purpose.
I thought this article was complaining about something that no-one used, but here you are recommending alternatives… alternatives that are not curl