i’m no expert — consensus sounds like putting disused only on the main tag, and when i’ve encountered this, i haven’t marked anything disused at all. i’ve only looked at the stop/platform to make sure they weren’t in any relation (transit line relations may include the passing way but shouldn’t include the disused stop/platform). and i make sure route_ref isn’t set on the stop/platform. were the stop to be used again, i figure it would have the same ref/stop id and operator, so i don’t remove them. listening for better ideas though

OSM has a lot more data inside than the website shows - in dense shopping areas you can’t zoom in far enough to see all the POIs, much less business names.

I’ve read before that using cached previews was done to stay accessible to less-powerful mobile devices, which would have smaller CPUs that would be taxed by rendering the native vector data. I view it as a branding disadvantage that OSM appears, from desktops, to have less info than alternatives. But that’s a battle that’s been had many times before, one might as well argue over paper vs plastic.

The main URL points to this:

well i feel stupid now for not doing the obvious. but…

Blocked Page

Your organization has blocked access to this page or website.

on the PPA box, this is what it showed me (meanwhile it was attempting to connect to incoming.telemetry.mozilla.org). another symptom of displaying respect for enterprise policies but in fact ignoring them. (as i had mentioned, on this box all of the settings look locked down as they should be, but it’s still attempting to send telemetry.)

thanks, i’ll look again. it’s not that i love the idea of being fingerprinted; i just think that five mylar bags, four tin hats and a partridge in a pear tree won’t save me from that. i need my password manager, and once that’s in, enforcing a generic screen is silly - cow’s out of the barn. but not having the arms race against pocket and telemetry would be a big bonus.

i did try that but the never-dark mode blinded me. i understand the reasoning, but absolute anonymity isn’t my own threat model; i’d like to be able to use themes and resize the window

an interesting oddity: on my non-rooted xperia, signal thinks that i don’t have play services and so it falls back to… polling. every five minutes. killing my battery and my logs.

i had to put signal into the restricted battery group, which means no notifications. i anxiously await the new molly, as i already have a unified push environment. it looks like the migration will be a bit delicate.

neo store refuses to run if you don’t grant it the right to send notifications and bypass battery optimizations. if an app demands a permission and doesn’t have a plausible explanation why it needs it, i don’t keep it :/

imo magic earth is a navigation app, full stop. it does that amazingly well, including live traffic, but i wouldn’t use it for anything else. organic maps is a better general-purpose map but isn’t a patch on magic earth for nav.

It exists, it’s called a robots.txt file that the developers can put into place, and then bots like the webarchive crawler will ignore the content.

the internet archive doesn’t respect robots.txt:

Over time we have observed that the robots.txt files that are geared toward search engine crawlers do not necessarily serve our archival purposes.

the only way to stay out of the internet archive is to follow the process they created and hope they agree to remove you. or firewall them.

https://blog.archive.org/2017/04/17/robots-txt-meant-for-search-engines-dont-work-well-for-web-archives/

i am not sure it’s a flaw at all. the conditional tag syntax is based on opening_hours, which should be able to express ‘closed at these times until that date’. there are ways to finesse this. but as long as the published guideline is ‘don’t do this’, there’s little point pondering practical solutions.

Our map data is often downloaded and used offline on various devices for several weeks or months. For offline data to be useful, it should at least be expected to remain unchanged in the next few weeks when you map it.

yes, by this blurb, concession for offline users does supersede safety.

i’m an editor active enough to have been granted foundation membership but hadn’t known this rule; it indicates a view of osm as analogous to a paper map rather than for real-time navigation. if a change of less than weeks’ length is discouraged, i can’t in good conscience steer my friends away from google maps, as navigation is not a primary use case.

it is common practice in the u.s., at least, to use two nodes for big chain drugstores, where the shop, marked chemist, often has wildly different hours from the pharmacy. they have the same name and much of the same info

i made the same migration from markor (files in a folder) to logseq. there’s a lot to be gained - always-preview alone is a game changer - but on mobile the visibility of the keyboard can be fiddly. once in a while you’ll feel like you’re in vi, it has such a mind of its own. but i’m not planning to go back

looks great! the catch for me is that my current host doesn’t have docker support. your dependencies don’t look crazy so in theory i could burst it and install directly to the host environment, but at that point i’m giving myself grocy-level headaches.

reading about docker-capable hosts, i was surprised to see them starting at 1GB RAM - i couldn’t run pac-man in that. what would be a reasonable expectation for kitchenowl?

i haven’t tried the docker route - it seems fairly new. it also doesn’t seem like it would fix the issues i ran into. containerization is great for insulating the app from external dependency hell and environmental variation. but the problems i’ve had involve its own code and logic, and corruption of a sqlite database within its own filesystem; wrapping issues like that in a docker container only makes them harder to solve

osmand has great map support. real-time nav for transit isn’t an osm strength - i haven’t seen an osm app that integrates live traffic or transit

appimages just got less easy…

i don’t know which update did it - i think it must have been os-level (i run pop_os, derived from ubuntu) - but appimages silently stopped working. double-click, nothing. finally i looked in the log out of desparation, which said ‘appimages require fuse’.

more accurately, appimages require fuse 2 and the os had just upgraded to fuse 3. the fix is to heat-seek libfuse2, and don’t mess with any other fuse-related package as things can start wrecking themselves:

sudo apt install libfuse2

originally seen on an omgubuntu post