I ran the example doors given and it missed 9 swinging doors, some that were in double swing pairs, and a few that were just out on their own not clustered. Not bad overall though
Yep we're constantly improving we're currently above 0.87 for doors
we're thinking of adding a params for the ROC curve so that you can decide your own optimal thresholds depend on when false positive true positive rate is acceptable
Oh nice! I spend a good amount of time eyeballing drawings for overlooked details, so even finding most is a handy tool to me as my brain can skip the marked areas
If you're a masochist you can do it manually, just make sure you have a good grasp of whats going on first[1]
Simplistically you need a DS record at your registrar, then sign your zones before publishing. You can cheat and make the KSK not expire, which saves some aggravation. I've rolled my own by hand for 10 yrs with no dnssec related downtime
Great to see more Fuji X attention, their native software isn't great. Looking forward to trying it out with my older X-T20, which appears supported[1] surprisingly
I was about to mention the Fudge[2] app and its underlying library, but its already listed as a reference, nice!
I'd guess it also risks exposing a specific account as a crew member, making them trackable back on shore; particularly if you're uploading the same routes
I would expect that most nations are performing some kind of surveillance like this.
Finding people who serve on carriers shouldn't be difficult. That kind of information can be plastered anywhere over FB or similar. Many of their friends will also be active in similar roles.
Then find associated Strava accounts. Find more friends that way.
The information you can gather is useful on many fronts. Someone does a few runs a week on shore and then suddenly stops? Could be injury, could be that carrier has sailed. Have many of their "friends" who also serve there also stopped logging things on dry land? Do any of them accidentally log a run out in the open ocean? This kind of patchy unreliable information is the mainstay for old-school style espionage.
Strava Labs beta "Flybys" site used to be a great source for stalkers. You could upload a GPS track (which can easily be faked in terms of both location and timestamps) and see who was running/riding/etc nearby around that same time. The outcry was enough that it was switched to being opt-in (in 2020 I think) but for a while all of the data was laid bare for people to trawl and misuse.
Some areas have duplicate, or very similar street names (ie, 'ave' vs. 'street') I don't think its that much of an ask that a website lets you enter your address correctly
FWIW I have received mail from the USPS in places that had no canonical full address as well. It's not the case in reality that the USPS only delivers mail to mailboxes that have an associated entry in their canonical database here in "messy" reality.
How do you feel about Alpaca in actual use? I've been skeptical about controlling something expensive with a REST api, not that I have anything to back up that feeling, but it always raised my eyebrow
It's been great. We've been operating with it at our observatories (SPECULOOS, ESO Paranal, Chile) for the past 2 years without issues that can be attributed to Alpaca. We had to modify the Alpyca library timeout from 5 to 60s (which Astra uses) given our legacy ASCOM drivers not being as compliant as they should be, but other than that it has worked well.
In my bortle 8 city, I have been able to get some decent images of the Eastern Veil Nebula with an Optolong L-Pro pollution filter, Zenithstar 73, and about ~2hrs total exposure (color)
Just for poking around, SharpCap has a live stacking mode which helps finding the darker stuff
It is unfortunate that frameworks and the like, love to choose completely unrelated names. It certainly makes it tough to navigate the landscape when names mean absolutely nothing
reply