OpenBCM V1.13 (Linux)

Packet Radio Mailbox

DB0FHN

[JN59NK Nuernberg]

 Login: GUEST





  
ZL3AI  > APRDIG   09.02.04 14:27l 263 Lines 10003 Bytes #999 (0) @ WW
BID : 2802-ZL3AI
Read: GUEST
Subj: TAPR Digest, Feb 06, 4/9
Path: DB0FHN<DB0RGB<OK0PPL<DB0RES<ON0AR<7M3TJZ<KP4IG<ZL2TZE<ZL3VML
Sent: 040209/1208Z @:ZL3VML.#80.NZL.OC #:18735 [Chch-NZ] FBB7.00i $:2802-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To  : APRDIG@WW

Subject: Re: Findu and the find-us query
From: Steve Dimse <k4hg@tapr.org>
Date: Fri,  6 Feb 2004 13:06:22 -0500
X-Message-Number: 25

On 2/6/04 at 11:46 AM James Jefferson <jj@aprsworld.net> sent:

>This is exactly what will happen when 1:1M scale maps are laid on top of
>more detailed maps. NOTHING WILL LINE UP. This will probably be the case
>with WinAPRS, dosAPRS, and some of the palmAPRS maps as well.

I guess what I don't understand is why are they being overlaid? Do the more
detailed maps not have land/sea boundaries?

My plan is not to overly maps on the server, but to pick the best single
map for a given location and scale, so this will not be an issue.

Steve K4HG

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

Subject: Re: Findu and the find-us query
From: Steve Dimse <k4hg@tapr.org>
Date: Fri,  6 Feb 2004 13:11:33 -0500
X-Message-Number: 26

On 2/6/04 at 11:46 AM James Jefferson <jj@aprsworld.net> sent:

>All this is possible, just needs to be requested.
>
>For example I just added borders to the countries.

That's cool.

Steve K4HG

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

Subject: Re: Findu and the find-us query
From: "James Jefferson" <jj@aprsworld.net>
Date: Fri, 6 Feb 2004 12:25:34 -0600 (CST)
X-Message-Number: 27

That's not how vector based stuff works.

Those pretty rasterized maps that MapBlast has ... they aren't just an
image. They are vector information of different layers and they get
rasterized together into a single image. So you can select the park layer
and the street layer and the water layer.

So my street data, derived from TIGER, comes as shapefiles which contain
latitude longitude information about line segments. So if they are
specified down to seconds of a degree and a map of the US is specified
down to minutes of a degree, then where they meet you get things like
streets into the water.

-Jim

>On 2/6/04 at 11:46 AM James Jefferson <jj@aprsworld.net> sent:
>
>>This is exactly what will happen when 1:1M scale maps are laid on top
>>of more detailed maps. NOTHING WILL LINE UP. This will probably be the
>>case with WinAPRS, dosAPRS, and some of the palmAPRS maps as well.
>>
>I guess what I don't understand is why are they being overlaid? Do the
>more detailed maps not have land/sea boundaries?
>
>My plan is not to overly maps on the server, but to pick the best single
>map for a given location and scale, so this will not be an issue.
>
>Steve K4HG

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

Subject: Re: Findu and the find-us query
From: Steve Dimse <k4hg@tapr.org>
Date: Fri,  6 Feb 2004 13:35:58 -0500
X-Message-Number: 28

On 2/6/04 at 12:25 PM James Jefferson <jj@aprsworld.net> sent:

>That's not how vector based stuff works.
>
>Those pretty rasterized maps that MapBlast has ... they aren't just an
>image. They are vector information of different layers and they get
>rasterized together into a single image. So you can select the park layer
>and the street layer and the water layer.
>
>So my street data, derived from TIGER, comes as shapefiles which contain
>latitude longitude information about line segments. So if they are
>specified down to seconds of a degree and a map of the US is specified
>down to minutes of a degree, then where they meet you get things like
>streets into the water.

I am very aware of this. What I don't understand is why you are specifying
more than one map source for a given image. The USGS files also contain
land/water interface layers, why not use them rather than the cruder ones
now in use when you are drawing detailed street level maps? Of course, it
makes sense to use the cruder data in wider area maps as it will not change
the finished product and will draw faster.

Steve K4HG

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

Subject: Re: IGate WEB page.
From: Jeff King <jeff@aerodata.net>
Date: Fri, 06 Feb 2004 13:42:03 -0600 (CST)
X-Message-Number: 29

Bob:

I think I know what you mean (a PHG circle) but by implication, an ALOHA
circle would mean the circle in which another station could not hear
another station, in other words, infinity. This, derived from the term
"pure Aloha network" in which respective stations cannot hear each other.

Or did you have something else in mind? I got the impression if you can 
hear 'em, work up (i.e. direct) was what you where saying.

Regards,

Jeff

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

Subject: Re: Mapping plans
From: Jeff King <jeff@aerodata.net>
Date: Fri, 06 Feb 2004 13:48:43 -0600 (CST)
X-Message-Number: 30

This sounds alot like APRSWORLD, so why not just help James out with
APRSWORLD? That is the beauty of open source, if you don't like something
or it doesn't do something you want it to, you add it yourself. He already
has the sourceforge project set up and it would be a good start.

Quoting Steve Dimse <k4hg@tapr.org>:

>Without anyone coming forward with plans to provide a comprehensive
>mapping
>server, let me lay out my plans for accomplishing this. First, all code
>is to be
>released under the GPL. I'l like to do a sourceforge project, but do not
>have
>the time to mess with setting one up, perhaps someone else is willing to
>do
>this. Code will be in Perl with MySQL as the database.
> 
>Comments welome!
> 
>Steve K4HG

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

Subject: Re: IGate WEB page.
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Fri, 06 Feb 2004 15:23:31 -0500
X-Message-Number: 31

>>>Jeff King <jeff@aerodata.net> 2/6/04 2:42:03 PM >>>

>I think I know what you mean (a PHG circle) but by implication, an
ALOHA circle 
>would mean the circle in which another station could not hear another
station,...
>...Or did you have something else in mind?

Yes, my use of the term ALOHA circle was in the context of the APRS
ALOHA Circle which we have defined and discussed quite often here on the
APRSSIG since last September.  It means the individual circle unique to
each station that is defined as the radius that encompases his nearest
60  or so neighbors sharing the same APRS ALOHA channel on 144.39.

This radius defines an area which is a saturaded channel based on the
typical statistics of APRS users.  The beauty of it is that it is a
universal metric that applies whether you are in the middle of LA or
Montana.  In LA, the typical ALOHA circle is about 15 miles or less.  In
Montana it is over 150  or more.

I have a WEB page on the concept:

http://web.usna.navy.mil/~bruninga/aprs/fix14439.html

And it is trivial for anyone to get an instant assessment of their own
ALOHA CIRCLE.  Just do a http://map.findu.com/mycall and then click on
"nearby stations".  That list is his nearest 60 neighbors sorted by
range, so the last-line range defines that persons "ALOHA CIRCLE".  Its 
a metric everyone can use.

de WB4APR, Bob

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

Subject: Re: Mapping plans
From: Steve Dimse <k4hg@tapr.org>
Date: Fri,  6 Feb 2004 15:27:42 -0500
X-Message-Number: 32

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

>This sounds alot like APRSWORLD, so why not just help James out with APRSWORLD?
>That is the beauty of open source, if you don't like something or it doesn't do
>something you want it to, you add it yourself. He already has the sourceforge
>project set up and it would be a good start.

First, as I understand it, APRSworld is a parser and web interface, just as
findU.com is. What we are really talking about here is the maps he is using
on his web site. These are generated from shapefiles using code from UMN
called MapServer. Perhaps Jim can clarify the exact mechanics more...

However, the APRSworld maps are US only. The coverage outside the US is
limited to coarse coastline and international borders. He depends on
shapefiles, the only comprehensive solution to making his mapping server
work for the world is to buy shapefiles for all countries that have APRS
users. However, none are free, and APRS cannot even afford to buy the files
for Canada.

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.

The APRSworld maps are a big part of the plans for the new system, the idea
is that the map server will default to those maps within US borders, and
use the best available map in other areas. As to supporting him, I've
switched the maps for find.cgi to his server for experimentation as he
requested, and I've offered a spare computer. What have you offered?

Steve K4HG

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

Subject: Re: IGate WEB page.
From: Steve Dimse <k4hg@tapr.org>
Date: Fri,  6 Feb 2004 15:41:17 -0500
X-Message-Number: 33

On 2/6/04 at 3:23 PM Robert Bruninga <bruninga@usna.edu> sent:

>Yes, my use of the term ALOHA circle was in the context of the APRS
>ALOHA Circle which we have defined and discussed quite often here on the
>APRSSIG since last September.  It means the individual circle unique to
>each station that is defined as the radius that encompases his nearest
>60  or so neighbors sharing the same APRS ALOHA channel on 144.39.

I do not believe this is a good concept to apply to limiting IGating,
because just like the arbitrary distance proposal, it depends on correct
transmission from the user. This also makes it difficult for neighboring
IGates to predict what the others are using for a disnace, and furthermore,
the use of circles in any sort of propagation setting is suspect,
propagation rarely occurs equally in all directions.

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
simpler to implement.

Steve K4HG

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



Read previous mail | Read next mail


 15.10.2026 20:22:34lGo back Go up