| |
ZL3AI > APRDIG 09.02.04 15:03l 214 Lines 7800 Bytes #999 (0) @ WW
BID : 2807-ZL3AI
Read: GUEST
Subj: TAPR Digest, Feb 06, 9/9
Path: DB0FHN<DB0THA<DB0ERF<DB0FBB<DB0GOS<ON0AR<ON0AR<LZ3NP<7M3TJZ<IK6PYS<
ZL2TZE<ZL3VML
Sent: 040209/1247Z @:ZL3VML.#80.NZL.OC #:18740 [Chch-NZ] FBB7.00i $:2807-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: Mapping plans
From: James Jefferson <jj@aprsworld.net>
Date: Fri, 6 Feb 2004 17:30:47 -0600
X-Message-Number: 52
I said:
>>from the TIGER county land polygons and everything would "mesh"
>>perfectly. It would be slightly slower because there is more data to read
>>off of disk.
Steve said:
>So will you be creating a parameter for this or switching automatically
>when you get near the coast?
Probably what I'll do it have it always use the better TIGER data at more
detailed scales. It will slow down rendering but I might be able to
accomplish some more tuning to make up for it.
>Instead of the image map.php now returns, a new program perhaps called
>geo.php would write the image to a temporary directory on your hard drive
>and return a geo file in response to the web request. If you were to do
>this, then your server would instantly become usable by findU with a
>request like this:
>
>http://www.findu.com/cgi-bin/plot.cgi?call=*&geo=http://maps.aprsworld.net/
>mapserver/geo.php?(map params here)
Yeah, I like this! Could work.
There is a problem that may be big or small. Mapserver won't create a
distorted map. So if you specify you want 90 degrees of longitude and 4
degrees of latitude returned in a square image, it won't do it. In other
words, it always maintains the correct aspect ratio.
However if an application actually looks at the GEO file to see what bounding
box was (instead of assuming it got what it requested) then it should work
fine.
>Writing geo.php would take less than an hour, inf.php a couple more minutes
>to support UI-View users.
It might not be quite that simple but I think I can accomplish it this
weekend.
Can you or somebody point me at references to GEO and INF format?
>>Addition zoom levels have always been supported (and even documented!).
>
>Cool, didn't know this, when I wrote find-us.cgi for you you only told me
>about the textual scales. Not etirely clear from the docs, you specify the
>bounding box in place of the lat/lon and scale parames, is that correct?
Yes. My fault that I didn't provide this originally.
-Jim
----------------------------------------------------------------------
Subject: Re: Mapping plans
From: "Curt, WE7U" <archer@eskimo.com>
Date: Fri, 6 Feb 2004 15:35:10 -0800 (PST)
X-Message-Number: 53
On Fri, 6 Feb 2004, James Jefferson wrote:
>Can you or somebody point me at references to GEO and INF format?
GEO's: Xastir's Help->Index, which points you at the
help-English.sys file.
INF: You could look at the inf2geo.pl file in the Xastir scripts
directory.
--
Curt, WE7U archer at eskimo dot com
Arlington, WA, USA http://www.eskimo.com/~archer
"Lotto: A tax on people who are bad at math." -- unknown
"Windows: Microsoft's tax on computer illiterates." -- WE7U
"The world DOES revolve around me: I picked the coordinate system!"
----------------------------------------------------------------------
Subject: Fw: Mapping plans
From: "Peter Devanney" <pdevanney@sympatico.ca>
Date: Fri, 6 Feb 2004 18:34:31 -0500
X-Message-Number: 54
I have been wishing for this sort of capability for APRS clients (in my
case UI-View) for some time. Getting good at making maps for UI-View from
just about anything.
Also appreciate that you defend the need for a capability beyond the US.
Peter
VA3YOW
----------------------------------------------------------------------
Subject: Re: Fw: Mapping plans
From: Jeff King <jeff@aerodata.net>
Date: Fri, 06 Feb 2004 18:31:52 -0600 (CST)
X-Message-Number: 55
Quoting Peter Devanney <pdevanney@sympatico.ca>:
>I have been wishing for this sort of capability for APRS clients (in my
>case UI-View) for some time. Getting good at making maps for UI-View
>from just about anything.
>Also appreciate that you defend the need for a capability beyond the
>US.
No issue with this, but it really has to be put in perspective of the "free
lunch".
In the U.S, the census bureau makes these mapping databases (TIGER) at the
taxpayer's expense, then releases them into the public domain. And it
should, since the taxpayer benefits from this data (and paid the goverment
to collect it!).
So, if you really want to defend mapping capability beyond the U.S. for
APRS, it really depends on cheap/'free' mapping data. So, while I'm not
sure in your case, if your respective goverment is taxing you to make
maps, make sure they also release the data into the public domain.
See:
http://www.census.gov/geo/www/tiger/overview.html
-Jeff
----------------------------------------------------------------------
Subject: Re: No more RELAY,WIDE defaults for fixed stns
From: James Smith <k9apr@sbcglobal.net>
Date: Fri, 06 Feb 2004 19:42:54 -0500
X-Message-Number: 56
Hi Bob,
Yes this message came from me several months back, I never got one response
from any of the other authors. I did however mis-quote something though,
UI-View doesn't default to any unprotos or paths... Sorry for the mis-quote
Roger.. Bob, it is nice to see your actively updating APRSDos now days
thanks for the late response, but at least you did... :-)
--
73, James, K9APR
Chairman \ Coordinator
Tri-State APRS Working Group
http://www.tawg.org
mailto:k9apr@tawg.org
Run a APRS Website? Why not join the APRS Webring. http://www.tawg.org/join.htm
----------------------------------------------------------------------
Subject: Re: IGate WEB page.
From: "Dick Stanich" <dick@kb7zva.com>
Date: Fri, 6 Feb 2004 21:4:41
X-Message-Number: 57
On 02/06/04, "Steve Dimse <k4hg@tapr.org>" wrote:
>I maintain the one to two hops (depending on nearby IGate coverage), which
>matches the UNPROTO on the TNC will provide better coverage, and be far sim=
>pler
>to implement.
>
>Steve K4HG
Yes, that is what I was saying and it is the best method. Currently my
Ui-View Igate 'listens' for direct stations, not digipeated. Those are
considered local for Igate purposes. The unproto path of the IGate can only
reach those direct stations. Nearby Igate coverage dictates that we should
reduce our coverage areas. I know this might sound like a commercial for
Ui-View, but the program allows me to rebroadcast anything I want to
different unproto paths. Area wx warnings are sent to RF from the NWS
beyond my direct stations (WIDE2-2). All message traffic from the Igate to
direct stations on RF would use no hops, or a path of APRS.
If I'm only servicing direct heard stations, I don't need a circle to
determine my Igate coverage area. ALL heard stations using long paths make
it to the server I'm connect to, if the TNC hears them.
I asked the question, what's considered 'local' for an Igate? The response
produced several different theories. I can say as more and more Igates pop
up, we should consider 'direct heard' as local for an Igate. This generally
prevents Igates from over-lapping each others' coverage areas and
unnecessary QRM. Even in high density areas with lots of Igates 'direct
heard' is the best way to go. It works very well for the 6 Igates within
200 miles of my location. Simply think 'direct' and service those directs.
The old standard 'heard within 3 hops on RF' is outdated. Path specific
Igates are so much better and are very friendly. I suppose coverage circles
are cool if an Igate wants to blast out beyond it's coverage area. More
Igates sending active 'IGate status reports' pretty much tells us all.
I'd like to see a database that not only shows nearby stations, but which
are heard direct in relationship to a specific IGate. Take a look at this
example:
http://206.97.61.103/allrf.html
The source would be another commercial, ah well, Ui-View has it's own built
in WebServer <g>.
Dick, kb7zva
---
END OF DIGEST
Read previous mail | Read next mail
| |
