OpenBCM V1.13 (Linux)

Packet Radio Mailbox

DB0FHN

[JN59NK Nuernberg]

 Login: GUEST





  
ZL3AI  > APRDIG   09.02.04 15:07l 219 Lines 9335 Bytes #999 (0) @ WW
BID : 2805-ZL3AI
Read: GUEST
Subj: TAPR Digest, Feb 06, 7/9
Path: DB0FHN<DB0RGB<OK0PPL<DB0RES<ON0BEL<7M3TJZ<IK6PYS<ZL2TZE<ZL3VML
Sent: 040209/1234Z @:ZL3VML.#80.NZL.OC #:18738 [Chch-NZ] FBB7.00i $:2805-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To  : APRDIG@WW

Subject: Re: Mapping plans
From: Steve Dimse <k4hg@tapr.org>
Date: Fri,  6 Feb 2004 16:57:54 -0500
X-Message-Number: 43

On 2/6/04 at 3:14 PM Jeff King <jeff@aerodata.net> sent:

>I knew that APRSWORLD, as it sits, would not do what Steve needed. Yet it would
>do part of what he needed, so instead of an entirely new application, just
>extend upon what APRSWORLD is already doing.

I knew that too, and if you look at my messages you would see that from the
first, APRSworld was an integral part of the system I'm proposing. Again,
I'm looking far beyond my needs to come up with something that would be
useful to all of APRS. I feel this could be as significant for the future
of APRS as the APRS Internet System turned out to be.

I'll try to flesh out my ideas better as this develops. Right now I'm
working on a demonstration with APRSdos maps (since that is the only map
generation I have access to right now). I cannot use APRSworld as it sits
now, as there is no georegistration information, and little control over
the range of the maps.

Steve K4HG

----------------------------------------------------------------------

Subject: Re: Mapping plans
From: James Jefferson <jj@aprsworld.net>
Date: Fri, 6 Feb 2004 16:16:03 -0600
X-Message-Number: 44

>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.

>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)

>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)

>The fact that you are using proprietary data is new to me, I thought you
>were only using publicly available data. What are the sources of the data
>you cannot share, do you have rights to share images based upon that data,
>and what would it cost to equip other servers with the same data? Whatever
>we do, there must be multiple sources for the maps.

No cost. They just have licenses that make you download it directly from them.

In many cases there isn't multiple sources for the maps. You want a map of 
antarctica? It comes from one source.

>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.

>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.

>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.

>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!).

Relevant information about map.php
/**
 * Draw maps using mapserver <http://mapserver.gis.umn.edu> and custom map 
file <blank.map>
 *
 * @author James Jefferson Jarvis <jj@aprsworld.net>
 *
 * @param $lat  Latitude of point (and usually center of map)
 * @param $lon Longitude of point (and usually center of map)
 * @param $icon Name of mapserver icon to label point above
 * @param $label label for point

 * @param $scale set the scale of the map to draw
 * @param $lat_scale used when scale=='box' to set the up/down area of the
* bounding box
 * @param $lon_scale used when scale=='box' to set the left/right area of the 
* bounding box
 * @param $info_text text to display in the lower left hand corner of the map
 * @param $nocache if true then don't used the cached image
 * @param $track_shapefile data to use to show a series of unlabeled points 
* (from local disk)
 * @param $icon_size size in pixels the icons should be
 * @param $layers layers seperated by spaces to draw, overrides the defaults
* in blank.map
 *
 * if $scale is extent then bounding information comes from
 * @param $minx Minimum x coordinate (longitude) of bounding box
 * @param $maxx Maximum x coordinate (longitude) of bounding box
 * @param $miny Minimum y coordinate (latitude) of bounding box
 * @param $maxy Maximum y coordinate (latitude) of bounding box
*/

----------------------------------------------------------------------

Subject: Re: HF APRS
From: "Stephen H. Smith" <WA8LMF2@aol.com>
Date: Fri, 6 Feb 2004 14:20:14 -0800
X-Message-Number: 45

Adam Pirkle wrote on 2/6/2004, 1:41 PM:

 > (is there such a thing as a
 > crossband-capable mobile HF rig?)

Not sure what you mean here.

Any of the multi-band HF/VHF/UHF rigs can be set to split-frequency
operation such as is done on two meters for a "non-standard" repeater,
where you receive on one frequency (or band or mode) with VFO "A" and
transmit on another frequency (or band or mode) with VFO "B".  But not
simultaneously, ala repeater.   And not very advisable since you wouldn't
be monitoring the HF freq before transmitting.

If you do want to do this, however, you would still have to use a KAM or
similar device, with the radio's receiver (listening to 2M) connected to
the 1200 baud receive port,  and the radio's mic jack (transmitting on 30M)
connected to the KAM HF transmit port so that the KAM could receive a 1200
transmission on 2M, buffer it in it's memory, key up the rig on HF and then
retransmit the packet at 300 baud on 30M.

If you truly want to operate on 2 meters and an HF band simultaneously
and independently, the only rig I am aware of that can do this is the
Kenwood TS-2000 (which is big bucks and is functionally a TS870 and a
D700 stuffed into one box including the same TNC chip as the D700).

Assuming the support truck wouldn't be that far from you, another
alternative would be to beacon posits on HF originated directly from the
truck, not the bike.
       Get an inexpensive HF-only rig like a second-hand Kenwood TS-50
and connect a TinyTrak III tracker to it's mic jack.  The TinyTrak
(about $35 in kit form) is essentially a transmit-only TNC who sole
purpose is to take serial data from a GPS and convert it into standard
APRS packets for transmission.  The current TinyTrak only does 1200 baud
VHF packet; however in the next couple of weeks, the TinyTrak IIIb which
also supports 300 baud HF operation will be released.

The final setup in the truck would be:

   GPS-->TinyTrak IIIb--->TS-50 (on 30M)-->30M HF ant
        (single band HamSticks are about $25 for this band).

No crossband repeating or dual port TNCs required at all.....

Stephen H. Smith                   wa8lmf (at)  aol.com
Home Page:                                         http://wa8lmf.com
Ham Radio/Mobile SSTV page:     http://members.aol.com/wa8lmf/ham
APRS Stuff
http://members.aol.com/wa8lmf/aprs

----------------------------------------------------------------------



Read previous mail | Read next mail


 15.10.2026 16:09:37lGo back Go up