[Xastir] Announcing tile support for OSM

[Brian Webster]

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: xastir-bounces at lists.xastir.org
[mailto:xastir-bounces at lists.xastir.org] 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
Xastir at lists.xastir.org
http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir