Re: Objects (Dev: 2011/03/30 12:36)
- As an avid D700 User I will simply say that trying to get to the + symbol with the keypad on the radio, is a GIANT!!!!!!!!! PITA....
I love the idea, but from a mobile radio standpoint + would make me not even bother to use it... Yes, it's a HUGE PITA.... if you needed to hear it again.
--- In email@example.com, "Lynn W Deffenbaugh (Mr)" <kj4erj@...> wrote:
> On 3/30/2011 9:31 PM, James Ewen wrote:
> > There it was, just like you said... now that I have a little time to
> > play, I'll dig in deeper. I only had about 10 minutes after release to
> > look at all the new goodies before having to head to a customer
> > jobsite and earn my keep.
> Ever notice that "work" is a 4-letter word? But then again, so is "play"!
> > So, out of my list of globally configurable options that was WAY too
> > long, you dropped changing the icon and interval. Two measly extra
> > options rates a "WAY" adjective? You're WAY too dramatic! 8)
> Yep, I've been told I use the "shriek", "bang", "exclamation point",
> whatever you call it way too often too!
> > You do realize, that now you just about have TWP support
> > almost complete.
> > If you create an object(s) that describes the local hospital and put
> > it in a specially named group (say +HOSP) APRSISCE/32 would respond to
> > a query with just the objects in the specific group. Any group with
> > the special prefix of "+" would be treated as a special object that
> > can be queried as a TWP. Groups such as +GAS (or +PETROL for our
> > friends across the pond), +VOICE, +CLUB, +NET, +FD can be created and
> > stored locally, and only sent upon receipt of a query.
> I have to think about the + sign, but I like where you're going.
> Royalty free? ;)
> > One problem with the TWP concept that I see is that these queries need
> > to be directed at a specific station for a response. If you're looking
> > for a hospital, it's pretty tough to have the calm cool demeanor
> > necessary to scan through the local stations looking for someone
> > advertising that they have stored objects that can be queried, and
> > then compose a query and await the response.
> > I would think that being able to send a generic request out such as
> > ?HOSP? and having any station with a HOSP entry respond appropriately
> > would be better. I don't think anything like that is available
> > currently. I'll have to think about how that would be implemented with
> > our current hardware and APRS capabilities. Perhaps sending an APRS
> > message to a generic destination that all APRS clients snoop for, and
> > look for these types of generic queries...
> We already have ALL, QST, and CQ message destinations which are
> "supposed" to be displayed by all APRS clients, but acked by none (top
> of page 73 of aprs101.pdf). Maybe we could use TWP? If we could
> standardize the ?<group> query names globally (only one ?, they're
> non-trivial to type on radios, I believe), send the message to TWP, and
> have similarly named groups of objects (some/many of which may only
> contain a single object), we'd be almost there.
> However, think about APRS-IS. Those ALL messages may be seen by every
> client on the planet, at least those running a t/m or full feed. We
> definitely don't want all of those objects flooding out at once. I'm
> thinking that this functionality will require a local RF port and only
> queries received via that port will be processed and the resulting
> object transmitted over the same port the query was received from. The
> object may (will?) end up gating back into APRS-IS from some other
> IGate, but the object IDs should be globally unique anyway.
> Let me mull this one a bit, but I kind of like where it's going. But
> +? How about starting the group with ? and then it can directly match
> the ?<query> name? But of course, only TWP-directed queries received on
> a local RF port will trigger immediate transmission of all objects in
> the same-named ?<query> object group. Nice.
> >> Here's what I see as the DF field sequence now.
> >> Right click, Coordinates, New DF @Center or HERE.
> >> Click DF to set the Quality and possibly change the range (default is circle scale)
> >> If you know the correct Bearing, set it here also.
> >> Accept the DF, then Accept the Object
> >> If bearing in degrees was not known, Right click map again, Coordinates, Point xxxx HERE
> >> (Note the current and proposed bearing degrees in the parenthetical)
> >> Done
> > Yup, pretty much.
> Actually, I'm improving the two DF creation messages again. The @Center
> is actually going to give a cascading menu of quality settings (+/- 1/2
> of the quality range) and will default the bearing to point from the
> center through the right click point. The DF HERE option will still use
> quality 3 (+/- 32 or 64 degrees wide) as it does now because menus must
> have unique values across the hierarchy, a restriction I'm trying to
> work around, but it will point through the center from wherever you
> right clicked. The range will still use the current circle range.
> Have your center where you are, you ARE using a GPS, right?
> Right Click in the direction of signal, Select @Center to cascade to
> quality and choose the right one.
> Click Accept to the Object dialog (no need to check anything)
> Done, the pie-slice DF object is now on your map.
> > This little battle of the wills can probably be avoided by doing a
> > duplicate name check against any existing objects when naming a new
> > object.
> I'll see about putting that in place, thanks for the suggestion. Of
> course, you'll have to do the testing because I really didn't follow
> your description (which I cut out for brevity in this response).
> >> Oh, Rinse and Repeat until the (now darker overlapping) DF beams pinpoint
> >> the transmitter. In case you haven't seen the DF overlaps yet, there's a
> >> screenshot below.
> > You've gotten the process much easier to deal with now... however,
> > once you've completed the hunt, and you want to show your buddies your
> > 7 DF plots used to track down the hidden transmitter, you have to
> > navigate the menu minefield 7 times to check enabled, and accept.
> > Configure|Objects|DF|SRV.DF.1|enable|accept.
> > Now you're done, and you want to kill the DF objects, and disable
> > them, or delete them. 7 more times through the menus to check Killed,
> > and 7 more times through the menus to uncheck enabled, or to delete
> > the object. You don't want to delete before killing the object from
> > everyone else's screens.
> Group Enable/-IS/RF are coming, and probably even Kill as soon as I
> figure out a way around the duplicate menu options (every group will
> start with the same 4 actions) issue. Deleting the objects will still
> be one-at-a-time as an in-your-face confirmation that you really want to
> throw away all of that work you just did. So...
> 4 clicks per DF object to create it (6 if you count re-centering on me)
> They come up enabled for local display.
> One or 2 more clicks for Group / -IS/RF enable - Interval will be a
> problem here unless you set it up while creating the objects. Maybe I
> should default the Interval to 10 (traditional net cycle time) on
> newly-created objects knowing that it will only take effect if you
> enable -IS or RF? Then it would be an explicit and purposeful step to
> configure one for Query-only issuance. Reduces the support questions of
> "I made an object and set the Via but it won't transmit!". Done.
> Default new object interval is now 10.
> When you're done showing off, hit the Group / Kill and wait a bit
> (APRSISCE/32 doesn't flood the RF with changed objects but paces itself
> to one every N (I think 30) seconds.
> Sometime later, Group / uncheck Enable and/or Via options. Sometime
> LOTS later, delete each individual object.
> > When you start playing with multiple objects, you can see the value of
> > being able to make some changes in a global fashion to a group.
> Why do you think the groups were born so quickly? Global options will
> be coming soon. Have you noticed my GP objects lining the Appalachian
> Trail for Bob's Golden Packet initiative?
> (http://www.aprs.org/at-golden-packet.html) Yeah, I want it too!
> Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
- On Tue, Apr 5, 2011 at 5:01 PM, Steve Daniels
> What I love about the USA is you pay for something via tax andCanada followed the UK standard for years, but just recently, the tide
> get the data for free, (well other than having paid via tax) here you
> pay for it via tax and then get to pay thousands to access the data after.
has turned. We are now getting overwhelmed with free access to our
taxpayer's paid for data.
If you look at the OSM map around my area, most of the rural roads
came from CanVec, and the water and woods being imported are also from
CanVec. The data may be a little less than perfect, but it is much
better than the big blank that we had due to so few OSM users in such
a large country. CanVec is also looking at using OSM contributed data
to update their information in the future.
The UK might see the light one day.