Loading ...
Sorry, an error occurred while loading the content.
 

Re: [aprsisce] Re: QRU Object Uniqueness and Locality (was: ?Group Objects)

Expand Messages
  • Keith VE7GDH
    Lynn KJ4ERJ wrote... ... The helicopter running for 2-3 days might have been an odd and useless thing to do, but it doesn t point out a fault of the APRS
    Message 1 of 65 , Apr 7, 2011
      Lynn KJ4ERJ wrote...

      > I'm referring to the direct observation with repeated attempts at
      > contact to find out why an Italian operator was "flying" a helicopter
      > object that departed Hawaii one day and flew, IIRC, for 2-3 days
      > despite repeated contacts by multiple people.

      The helicopter running for 2-3 days might have been an odd and useless
      thing to do, but it doesn't point out a fault of the APRS client that generated
      it, whether it was UI-View or something else. It also wouldn't have caused
      any harm or impacted anyone else. Heck, I could create a "helicopter"
      object now and send it on its way and it wouldn't be anything more than
      a curiosity. The only impact it could have on anyone would be if I was
      sending it out on RF at a high rate or a stupid path.

      > I realize that was a single incident, but it was pointed out at the
      > time, by UI-View users, that it was all too easy in UI-View to create
      > such an object, give it a course and speed, and not be aware that it
      > was running.

      Course and speed for an object wasn't "invented" by UI-View. It's a
      part of the spec, explained on page 57, 58 etc. of said spec. It may be
      easy to create an object in UI-View, but you can't inadvertently give
      it a course and speed. It takes two extra steps. The course must either
      be selected from a drop-down list and you must manually type in the
      course in degrees and finally type in the speed. Creating an object
      is an intentional act.

      > That is actually one reason that objects in APRSISCE/32 don't
      > support a course and speed setting via any direct support. Of course,
      > that doesn't stop you from putting one in the comment text (don't try it
      > James), but even then it would keep looping back to start over because
      > the origination coordinates would not be modified.

      If you don't add a course / speed option, that's up to you. Someone
      could always run a copy of APRS DOS or some other APRS client if
      they ever need to create a non-stationary object.

      > I may question, poke, and prod sometimes for details in UI-View, but
      > ordinarily it's an attempt to understand the function, not the form, of
      > a particular aspect of APRS. I've said it before and it's still true,
      > that I can only hope and aspire to develop something as good that will
      > continue to be useful after so many years of stagnation.

      If you add functions to cover everything in the APRS spec, that should
      about do it! After that, it's just a matter of working on the interface and
      usability. Don't throw the code out though. You can re-use a lot of it
      when you port it over to OpenTRAC!

      73 es cul - Keith VE7GDH
      --
      "I may be lost, but I know exactly where I am!"
    • Keith VE7GDH
      Lynn KJ4ERJ wrote... ... The helicopter running for 2-3 days might have been an odd and useless thing to do, but it doesn t point out a fault of the APRS
      Message 65 of 65 , Apr 7, 2011
        Lynn KJ4ERJ wrote...

        > I'm referring to the direct observation with repeated attempts at
        > contact to find out why an Italian operator was "flying" a helicopter
        > object that departed Hawaii one day and flew, IIRC, for 2-3 days
        > despite repeated contacts by multiple people.

        The helicopter running for 2-3 days might have been an odd and useless
        thing to do, but it doesn't point out a fault of the APRS client that generated
        it, whether it was UI-View or something else. It also wouldn't have caused
        any harm or impacted anyone else. Heck, I could create a "helicopter"
        object now and send it on its way and it wouldn't be anything more than
        a curiosity. The only impact it could have on anyone would be if I was
        sending it out on RF at a high rate or a stupid path.

        > I realize that was a single incident, but it was pointed out at the
        > time, by UI-View users, that it was all too easy in UI-View to create
        > such an object, give it a course and speed, and not be aware that it
        > was running.

        Course and speed for an object wasn't "invented" by UI-View. It's a
        part of the spec, explained on page 57, 58 etc. of said spec. It may be
        easy to create an object in UI-View, but you can't inadvertently give
        it a course and speed. It takes two extra steps. The course must either
        be selected from a drop-down list and you must manually type in the
        course in degrees and finally type in the speed. Creating an object
        is an intentional act.

        > That is actually one reason that objects in APRSISCE/32 don't
        > support a course and speed setting via any direct support. Of course,
        > that doesn't stop you from putting one in the comment text (don't try it
        > James), but even then it would keep looping back to start over because
        > the origination coordinates would not be modified.

        If you don't add a course / speed option, that's up to you. Someone
        could always run a copy of APRS DOS or some other APRS client if
        they ever need to create a non-stationary object.

        > I may question, poke, and prod sometimes for details in UI-View, but
        > ordinarily it's an attempt to understand the function, not the form, of
        > a particular aspect of APRS. I've said it before and it's still true,
        > that I can only hope and aspire to develop something as good that will
        > continue to be useful after so many years of stagnation.

        If you add functions to cover everything in the APRS spec, that should
        about do it! After that, it's just a matter of working on the interface and
        usability. Don't throw the code out though. You can re-use a lot of it
        when you port it over to OpenTRAC!

        73 es cul - Keith VE7GDH
        --
        "I may be lost, but I know exactly where I am!"
      Your message has been successfully submitted and would be delivered to recipients shortly.