| |
ZL3AI > APRDIG 09.02.04 15:04l 301 Lines 11829 Bytes #999 (0) @ WW
BID : 2806-ZL3AI
Read: GUEST
Subj: TAPR Digest, Feb 06, 8/9
Path: DB0FHN<DB0THA<DB0ERF<DB0FBB<DB0GOS<ON0AR<ON0AR<7M3TJZ<IK6PYS<ZL2TZE<
ZL3VML
Sent: 040209/1242Z @:ZL3VML.#80.NZL.OC #:18739 [Chch-NZ] FBB7.00i $:2806-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: Mapping plans
From: Adi Linden <adil@adis.on.ca>
Date: Fri, 6 Feb 2004 16:21:55 -0600 (CST)
X-Message-Number: 46
>The solution I'm pursuing leverages the maps people have made for UIview,
>PocketAPRS, WinAPRS, etc. to cover those areas where we cannot get free
>shapefiles.
This would also provide a repository for all freely available unencumbered
maps available for APRS. It would be great to have access to this resource
to either bulk download the maps and/or load them on demand into
applications such as Xastir and UI-View.
I am just starting to play around with Xastir and would like to have
topographical maps for North America (USA and Canada) on my HD. While I
have gif's for Canada, I cannot seem to find any single place that has it
all for US data. Any suggestions?
Adi
--
Adi Linden | va3adi | va3adi@adis.ca | http://adis.ca
+-----------------------------------------------------------------+
IRLP Node 2590 in Sioux Lookout, Ontario
----------------------------------------------------------------------
Subject: Re: Mapping plans
From: James Jefferson <jj@aprsworld.net>
Date: Fri, 6 Feb 2004 16:25:15 -0600
X-Message-Number: 47
Since a couple of people have asked here is the very minimal code that does
the aprsworld maps. It needs to have Mapserver's shp2img for it to work.
http://maps.aprsworld.net/mapserver/map.phps
(these are all links to the source code, note that they end in phps not just
php)
This takes a template mapfile and loads it with the parameters that the user
wants. It handles the caching of the maps.
http://maps.aprsworld.net/mapserver/lastposition.phps
This accepts a callsign and retrieves the last position of that station then
calls the map script above.
http://maps.aprsworld.net/mapserver/blank.map
Template map used above. This is a Mapserver Mapfile. Variables that need to
be replaced are demarcated with ##NAME## type syntax.
-Jim
----------------------------------------------------------------------
Subject: No more RELAY,WIDE defaults for fixed stns
From: Bob Bruninga <bruninga@usna.edu>
Date: Fri, 6 Feb 2004 17:27:13 -0500 (EST)
X-Message-Number: 48
Cleaning out old mail. But someone posted this only 4 months ago:
>APRS Default's by program, or least the ones I have.
>
>APRSDos = Wide
>WinAPRS = Relay,Wide
>APRS+SA = Relay,Wide
>APRSPoint = Relay,Wide
>PocketAPRS = Relay,Wide This one is okay cuz ur probably mobile.
>UI-View = Relay,Wide
The topic was WHATS Causing all the DUPES. And the answer is that one of
the #1 things that all authors can do is to eliminate the default of
RELAY in their software which is NORMALLY Used at a FIXED location. The
above data is surely out of date. Anyone want to update it?
Yes, 10 years ago, the above were recommend. That is NO MORE. If there
is any program (mostly used by home stations) that is still defaulting to
RELAY,... lets get it fixed. now..
Thanks
Bob, WB4APR
----------------------------------------------------------------------
Subject: Re: Wi-Sys All-in-One APRS system (except radio)
From: "Brian Riley (maillist)" <n1bq_list@wulfden.org>
Date: Fri, 06 Feb 2004 17:34:02 -0500
X-Message-Number: 49
Their prices start to drop an quantity five(5) and its not bad. I recently
priced out a 4 by 6 panel with five or six cutouts and it came in around
$18-19, quantity one (1) and dropped $6 bucks per unit , quantity five (5).
I am going to order from them in a week or two, I will let you know how it
comes out.
cheers ... 73 de brian, n1bq
On 2/5/04 7:08 PM, "Scott Miller" <scott@opentrac.org> wrote:
>Speaking of fancy cases, has anyone here use
>http://www.frontpanelexpress.com? Their CAD program looks pretty easy. I
>looked up the specs on a standard Hammond extruded aluminum case and used
>that as a template to build a quick mock-up of a front panel for a tracker,
>with appropriate holes and lettering and such. The build-in price
>calculator put it at about $18. Seems fairly reasonable for a one-off
>thing, but I don't think I'd want to do that for any large production
>quantity!
>
>Scott
>N1VG
----------------------------------------------------------------------
Subject: Re: No more RELAY,WIDE defaults for fixed stns
From: "Curt, WE7U" <archer@eskimo.com>
Date: Fri, 6 Feb 2004 14:44:55 -0800 (PST)
X-Message-Number: 50
On Fri, 6 Feb 2004, Bob Bruninga wrote:
>Cleaning out old mail. But someone posted this only 4 months ago:
>
>>APRS Default's by program, or least the ones I have.
>>
>>APRSDos = Wide
>>WinAPRS = Relay,Wide
>>APRS+SA = Relay,Wide
>>APRSPoint = Relay,Wide
>>PocketAPRS = Relay,Wide This one is okay cuz ur probably mobile.
>>UI-View = Relay,Wide
Xastir was defaulting to "RELAY,WIDE" for outgoing transmissions.
New versions (today or later) will default to "WIDE".
--
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: Re: Mapping plans
From: Steve Dimse <k4hg@tapr.org>
Date: Fri, 6 Feb 2004 18:07:57 -0500
X-Message-Number: 51
On 2/6/04 at 4:16 PM James Jefferson <jj@aprsworld.net> sent:
>>First, how do you deal with multiple maps covering the same area? If I
>>understand your statement correctly, you already have an issue with
>>coastlines and streets. What happens if two people submit overlapping maps
>>of areas? Will everything get drawn creating a mash of stuff?
>
>Layers can be specified and logic can be developed to deal with this. If it
>can be developed in a new system it can be developed in an existing system.
Does that mean you are going to do this?
>>How do you plan to incorportate images into this, like satellite, weather,
>>and aerial photos?
>
>Raster graphics can easily be included. I used to have weather radar with
>overlays of aprs stations, boundaries, ect. Putting that together involved
>adding the following to my standard map file:
>
>LAYER
> TYPE RASTER
> DATA "nexrad/n0r_0.png"
> NAME "nexrad_base"
> STATUS OFF
> METADATA
> "DESCRIPTION" "USA NEXRAD base"
> "WITHRADAR" "YES"
> "ISRADAR" "YES"
> END
>END
>
>(this is directly out of existing working code)
OK, I wasn't aware you had this capability. How does one specify a radar
image to map.php? What you have shown seems to be your code to do it, but
no one else has access to that...
How do users submit other images to you for use, such as is done with this
URL in findU:
http://www.findu.com/cgi-bin/track.cgi?call=k4hg-8&geo=http://www2.findu.com/
maps/usa.geo&start=99999
>>How you plan on getting the registration info (lat/lon/scale) back to the
>>client programs, or will only your code be able to draw on the maps?
>
>So send a GEO file or whatever you want back. Get the image bounds is
>something like:
>
>$GLOBALS["goMap"]->extent->miny,
>$GLOBALS["goMap"]->extent->maxy,
>$GLOBALS["goMap"]->extent->minx,
>$GLOBALS["goMap"]->extent->maxx
>
>(this is directly out of existing working code)
Cool, are you going to implement this on your server?
>>Could you elaborate more? What is the root of the coast/street issue, and
>>is it solvable with your code? What is the problem with Miami maps, and is
>>that solvable?
>
>You identified it earlier. The right data (1:25k scale) is available but it
>takes longer to rasterize. In all of the inland parts of the world this isn't
>an issue because lakes sit on top of land and all is good.
>
>Along the ocean is different the way I have things. (now, before we go too
>far, nothing is set in stone ... we're talking about changing a few worlds in
>a config file to change this) The continents are comming from the 1:1M scale
>political map of the world. I could change it so the US is drawn 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.
So will you be creating a parameter for this or switching automatically
when you get near the coast?
>>This way, ANY application that can use a geo file could use the new
>>server...and any application that added the ability to handle geo files
>>would gain access to the full range of APRS maps. Mobile users could get
>>the maps they wanted and save them to their local disk for use when not
>>connected to the internet. What I'm aiming for is something useful to all
>>of APRS, not just findU or APRSworld.
>
>Well, go ahead and re-invent the wheel and write it. I wrote aprsworld because
>I didn't like that findu was closed source and I couldn't do the research
>that I needed to with it. Sounds like you can't do what you need with an
>existing solution, so it makes sense.
Nothing would please me more than to rely on you for this, but again, I'd
need assurances that you are going to provide georegistration information,
help others get servers running, ensure that the necessary conversion
programs get written, and allow everyone to send in maps so that foreign
users get support. As I said at the outset, this is a monsterous job. You
have a start, and you say that you can expand your software to serve APRS's
needs. I need to know that you are going to take this on, not just say it
could be done.
I've lost a lot of sleep worrying about supporting my users (the price of
success), nothing would make me happier than to know someone else was
undertaking the mapping responsibility.
>>From what I'm hearing, your 2 man/day solution results in you being able to
>>draw on these files, but no one else. Is that correct?
>
>Adding a method of sending back geo referencing data isn't much of a
>challenge. They could be embedded using EXIF information the same way digital
>cameras encode the f-stop and shutter speed on the image.
This could be done, but it would require much modification on the part of
every APRS client program to read the data. On the other hand, APRS has a
system already in place for this, many APRS programs already support it by
geo files (besides findU, there is Xastir, WinAPRS, and MacAPRS for sure,
there may be others, and UI-View uses a similar INF file format).
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)
Users of the other programs supporting geo files could use geo.php to get
the map they want and then download it to their local disks. With very
little additional work the programmers of those programs could have their
code take care of this automatically.
Writing geo.php would take less than an hour, inf.php a couple more minutes
to support UI-View users.
I hope you will consider doing this soon, in place of the much more
difficult (on both our ends) embedding of parameters within the image.
>>Are you are willing to provide geospacial registration of the images, and
>>provide addition control beyond the three zoom levels presently supported?
>
>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?
Steve K4HG
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
