OK, I admit I'm fascinated by the technology in Google Ads. For the record, even at the initial rate the ads would not pay for more than a small fraction of a new server, and they have fallen off by more than 50% from that initial rate in only 6 days. I suspect it is because Google serves largely the same ads for each user's pages, generic ads of topomaps, aerial photos, humidity devices, and so on. They do not seem to pick up on the town names present on the find page...if they did I'd add a location to the wxpage cgi. I've written them with the suggestion, but as an experiment I added a link to a page containing nothing but the nearest city's name in the title. They generally serve public service ads until they spider the page, but after a variable length of time ads do pop up and fit better than the generic ads. I could put this is a frame, but that would be a lot more invasive. I hope Google looks at the specific needs of my site and adds some sort of support for geo-names...
Also interesting to me is the number of positive responses I've gotten (and the lack of negative ones) on the ad material. The google search box seems to be especially welcome (though in 6 days it has not generated enough for dinner at MacDonalds!).
The temp, wind, baro, and rain cgi's have finally been updated to respond to the metric and nautical parameters. There are additional vertical lines at 12 hour and 6 hour increments at smaller time periods. I've also added a new cumulative wind distribution graph to wxpage.cgi. This last feature may not be permanent, let me know what you think.
Both pages are now using the new layout, let me know if there are any problems...
Also, there is a topographic geo-generating cgi analogous to the aerial photo cgi, valid scale values are 2, 8, and 32.
I've produced a new layout for the find.cgi. It provides a left link bar showing options for the callsign and external links, and zoom scales for the APRSworld and TerraServer images. Try it at
Here is a script to grab Terraserver tiles and return an image with a geo file. This works as other geo file cgi's I've done, the cgi returns the geo file, the image is placed in a temp file referenced by the geo file. And as with other geo scripts, this can be used in any cgi with a geo parameter. For example:
The center of the image (and in this case it means the point occurs in the center tile, not at the exact center of the image) is specified wither with a callsign or a lat/lon pair:
scale is meters-per-pixel, values accepted by terraserver are 1, 2, 4, 8, 16, 32, and 64.
So far this only returns a 600x600 image, I'll be expanding it to make it work at other sizes.
The tiles are cached on findU, so the first time you load a particular lat/lon and scale, it will take longer (about 8 seconds), after that it only takes a a second to render the map. At some point I'll have to start pruning the cache based on the last time a tile was used, but of course after the first reload it again will be in the cache.
Please give this a good workout and let me know how it works...
It has been a long time since I've posted, mostly because I haven't made a lot of changes. That will itself change, I'm laid up with a badly proken ankle, which will require surgery. I'm looking for fresh ideas, if you have any please share them with me.
Also it has been a while since I mentioned the server stats. October set another record (as have most months) with 14,304,641 hits and 631,472 visits. Will it ever end???
Some things to clean up in that code, quite a bit of documention, and then I'm on to the librarian interface. There is a SourceForge project now for APRS MM, need to learn how to use SourceForge and then I'll be able to post all this code. There is lots of room for optimization, and both APRSdos and PocketAPRS maps need to draw labels, I'm hoping I'll get some help once I get the stuff up on sourceforge.
For some reason Ploticus isn't installing on the new machine, the only thing it is used for is some of the telemetry cgi's, which are not extensively used. Hopefully I can get this up over the weekend.
I forgot to make sure that the direct entry positions, namely WinLink and email/web were up to date on the backup, and to copy them over to the new server. Any posits from that route in the last three weeks will be lost, at least until I get the old server back from NJ. Sorry, nothing I can do now.
Also, it appears the user database for email and web entry did not update on the backup machine, if you try it and fail, you should try to re-register.
APRS data for the 24 hours the server was down during its trip are in the process of being updated from the backup server, should be complete sometime tonight, filling in the gaps in the weather charts.
Otherwise, I think we are in good shape, let me know of any problems.
My proposal for the APRS Map Manager (a long term solution to findU's map issue, and with utility throughout APRS) is online here. Work on the prototype system is progressing, I have the code to write a dos map to a temp file and return the geo file working. For example:http://www1.findu.com/cgi-bin/dosgeo.cgi?map=flsouth.mp&range=5&lat=25&lon=-81 One thing which popped up is a syntax problem, using the dosgeo within the plot cgi doesn't work: http://www2.findu.com/cgi-bin/plot.cgi?call=k4hg*&geo=http://www1.findu.com/cgi-bin/dosgeo.cgi?map=flsouth.mp&range=5&lat=25&lon=-81 The problem is the parameters to the dosgeo cgi get sent to the plot cgi. Quoting doesn't work, so I've settled on using the vertical bar to separate the parameters in the embedded URL: http://www2.findu.com/cgi-bin/plot.cgi?call=k4hg*&geo=http://www1.findu.com/cgi-bin/dosgeo.cgi?map=flsouth.mp|range=5|lat=25|lon=-81 The database is being designed now, then will come the pages that access the database. Help is very much needed, I'd love someone to write routines that can render WinAPRS, palmAPRS, and other maps into png files.
The page now handles maplists, which may also be hosted on your server, here is the current (and final) list of maplist files on my server.
aprslive.mp fltampao.mp ilrfd5.mp mokcity.mp ohbooths.mp usaeast.mp bertha.mp ga-atl.mp ilsycam3.mp n1qkp-ctnyc.mp oh-mi-wv.mp usa.mp bummer.mp gakenmtn.mp ilwinnco.mp n1qkp-elm.mp Pahrump.mp usancen.mp Cabak_e.mp hara.mp la.mp n1qkp-hm.mp sandiego.mp usaseast.mp CABAK_LV.mp iailinmo.mp Lebanon.mp nd-sd-mn.mp sdcty.mp usaswest.mp Cabak_w.mp ilcookco.mp li.mp nelands1.mp sdgo.mp usawest.mp ca.mp ildekco.mp mdannap4.mp nelands2.mp stage1.mp wa-or.mp caribean.mp ildeklb5.mp mdbalto.mp nelands3.mp stage9.mp washdc.mp dayton.mp ildeksyc.mp mdgburn2.mp nelands4.mp txbaldos.mp world.mp europe.mp illeeco.mp mdsouth.mp nelands5.mp txballoon.mp zl2ucxni.mp flsouth1.mp ilnocnty.mp mdstate.mp nelands.mp txstate.mp zl2ucxnz.mp flsouth.mp ilogleco.mp MN-WI-MI.mp neweng.mp usacen.mp zl2ucxsi.mp
calist.txt ilno.txt master1.txt n1qkp.txt nl.txt dayton.txt mappe.txt master.txt n4neq.txt tx.txt
I'd like to replace the worldwide data, and there is a source of the file, but it is huge, and its population files are very incomplete. For example, no VK cities have population data...so the choice is to include everything, which is way, way too big and slow for geographic search, leave out entire countries, obviously not acceptable, or edit manually, which is way to time consuming. If anyone knoes of a better world city database, please let me know...
I've been watching the log of my parser for almost 4 years now (geez, is findU really that old???), it contains messages when the parser detects a packet error. I have fretted for a long time about whether to release the information. I went ahead and created a page to display it, and after due consideration (and seeing the same callsigns appearing day after day, perhaps meaning that people aren't aware of their errors), I decided to go ahead.
default is 6 hours, you can change it with the last parameter, e.g. for 24 hours:
The page does not display callsigns with a single error, as there are many of these caused by things like mangled packets and unitialized GPSs, my target is persistant errors.
I've written software for too long to ever claim anything I've written since "Hello World!" is bug-free, and after all, these error messages were included specifically so I could hunt for bugs in my code. That said, I am concerned that I will suddenly get a mailbox full of messages complaining that my parser is busted. Please treat this as a chance to learn more about the protocol.
My parser is rather strict, packets that appear fine in some programs will not parse in mine, a side effect of the Perl language and regular expressions...for example, somewhat simplified code for parsing a lat/lon/icon set is:
after this executes, $1 is lat, $2 is N or S, $3 is symbol table/overlay, $4 is lon, $5 is E or W, and $6 is the symbol. If each and every condition set for in the above regular expression is not matched, then the packet is rejected. This means, for example, using n instead of N for north will reject the packet...as it should IMHO, because the spec clearly states it is N. Other code may implement the parsing differently. For example, in javAPRS, I simply tested for 'S' in the NS position, and negated the latitude if present, which means an 'n' would parse correctly (though an 's' would not). I suspect others take similar shortcuts in their parsers, being rigorous in a language without regex's can be painful, and writing an APRS parser is already plenty painful!
So, if you see something on the page that you think is legal, please be absolutely certain before complaining to me about a bug in my program. I have included the link to the APRS spec on the page, please get the spec and go byte by byte looking for the problem, don't just look at it with another program. Like all the APRS authors, I've had to do manual decomposition hundreds of times, so I just want to spread the fun around!