I managed to extract all data from the corrupted database, except for the weather history data from a single weather station (MMUN in Mexico), so I didn't need to use old backups. The weather history is currently being loaded in the running database. I started the load just after midnight (after getting home from the Kent concert), it's now 2 PM and 74970000 of 106248685 rows have been loaded already, so the load should be completed this evening. That's right, there are currently 106 million weather reports stored from 8728 weather stations.
Then database load is a bit slow, since I made the loading script sleep most of the time - it loads the reports of a single weather station, and then sleeps three times the time it took to perform the previous load. This prevents it from slowing down the database too much, and interfering the normal operation of the aprs.fi site. Once it's finished, the restore process is completed.
The news of https://aprs.fi/ - new features and interesting attractions found in the APRS and AIS worlds.
5 comments:
Thanks for all your work on the aprs.fi website. It's a slick tool.
One question: Is there a way to filter packets so that it shows all packets that a single station has digipeated? (If I don't care who originated the various packets.)
Sometimes I'm curious to find out over the course of a day how much activity my home digi has helped repeat other people's traffic on RF, and which direction/distance their packets came from.
It might be of use for determining how well (or how poorly) a digi receives traffic from certain directions because of terrain or other local factors.
Just a thought... (and I'm not sure how well I've worked that question through my own mind).
- Mark Rice, N4CMB
Sorry, currently you cannot filter the raw packets out. You can, however, look at the "Stations heard by" list on the info page for the digipeater (http://aprs.fi/info/digipeatercall) to get some idea.
It is quite bogus and misleading though, since some packets might have been digipeated by another digipeater which hasn't put it's own callsign in the packet, or marked it as digipeated. Some igates also loose the 'has been digipeated' bits from the packets. So it is currently not possible, with APRS-IS, to reliably do this kind of analysis, with any software at all. So take the statistics with a grain of salt!
The folks at db0anf have some more advanced stats (see the "Digipeater Users" and "Digi-User Map" views), but they have the same shortcomings. Interesting and pretty statistics, but not completely true.
Reloading of the weather history data was completed last night. Please let me know if something is still broken.
There's a... misfeature in the code that checks for stations that are moving too fast. If you look at K6DBG-7 today (9 Nov), you'll see what I mean. The tracker is a D7, which often sends out bad posits before it gets a good GPS fix (I wish I could set things up so it wouldn't send a posit w/o a fix). In this case, the (0,0) posits were ignored, but the next posit had a bogus location ... which is the one that sticks. I would suggest that the code should be checking the last posit, not the last "good" posit, for the "moving too fast" condition.
Thanks for a great site!
VY 73 de chris K6DBG
Yeah, I suppose it'd be wiser to look at the previous transmitted position instead of the previous accepted position, would speed things up after a bad transmitted packet. It'll permit speeding between two positions by transmitting two sequential packets from each location. The duplicate packet filter should catch those, though, for the duplicate callsign usage cases (multiple fixed stations having the same callsign).
I'll look into it, thanks for the note.
Post a Comment