This still makes me think that for standalone operations (that might also include a local lan of users) the idea of using the vector files (and or shape files) on a separate application that then acts as an open GIS WMS server might be a good solution. Vector data responds much faster and requires a lot less storage. If the WMS server makes it pretty and then serves the tiles of the pretty maps to the other clients like Xastir and Opentickets then that process might be worth the effort. Having a tool to render the vector based files would give the hams the independence needed in times of emergencies. Vector file formats like from OSM would be an awesome base and could be added to with other data, especially if data is created with GIS programs during emergencies.
Again just thinking out loud. I know my favorite GIS program www.manifold.net can act as an open GIS WMS server which could serve tiles (but it's only windows based). There are other open source programs that can function in the same way. I assume most municipal GIS organizations can do the same and they are proficient in their programs (ESRI and MapInfo for the most part). You would just link to them and pull the tiles as needed. Brian N2KGC -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Arnie Shore Sent: Thursday, July 29, 2010 11:58 AM To: Xastir - APRS client software discussion Subject: Re: [Xastir] Announcing tile support for OSM Folks, a bit of overlap between what I'm doing OSM-wise, so I thought I'd intrude with an undirected ramble and share some experience. I'm the lead programmer on a free open source computer-aided-dispatch package that's based on GMaps, and I've started looking at what it wd take to get off GMaps in favor of OSM. Rationale is pretty obvious: The RACES community and others have been beating on me (gently!) for operation sans an internet connection. So, since the application is browser-based the plan is for tile storage at the local server, with OpenLayers JS also stored locally. Question #1 for me was re the hd storage requirements for a typical county-sized area. And, related, what's the zoom impact on storage needed. Most of the users I'm aware of seem to run about four tiles on-screen. To answer that, I picked my local AA County, Md as a test case, wrote a PHP script to download and store the tiles into a directory structure that OL works naturally with, and started the download. (I used zooms 9 through 17 as the range, with a 1-second sleep between files. Anyone interested in the script let me know.) Mebbe 60 hours later, I had me a directory with over 150k files and a storage requirement of over 800MB. With a fairly simple OL/PHP script and directory structure created by the download script, I now have me a PHP demo slippy-map application. (I've promised myself to avoid using 'proof-of-concept' terminology, but it applies.) A number of thoughts fall out: 1. That 1-second sleep is a major contributor to download time, given the surprising - to me - number of files. (Predictable, but ... .) 2. Zoom as tight as 17 is prbly too much of a good thing. Prbly 14/15 cd work OK, but I see it as a user choice. 3. Can prbly use every other zoom between the extremes. Mebbe worthwhile, mebbe not. FYI, Arnie Shore Annapolis, MD _______________________________________________ Xastir mailing list [email protected] http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir _______________________________________________ Xastir mailing list [email protected] http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir
