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

Map Tiles default

Expand Messages
  • Mykle Raymond
    We have several sets of map tiles defined (we re up to five, some from on-line sources, some from local), and each of them works just fine. The last one was
    Message 1 of 3 , Oct 2, 2012
    • 0 Attachment
      We have several sets of map tiles defined (we're up to five, some from
      on-line sources, some from local), and each of them works just fine.

      The last one was added recently and I've been going around and copying
      the tiles to different computers and setting up the configuration, all
      without problems.

      The default tileset is not the one most recently added, so I switch to
      the usual one. However, the new one continues to be default, not the
      one being used when restarting or exit/start (I've been trying
      alternative ways of getting another tileset to "stick", but no success,
      not that there are many alternatives).

      Looking at the XML file, each of the TileServer sections is present and
      appears to be the same format. Just above the TileServer sections is a
      section of <OSM.xxxx> entries, which is currently specifying the new
      tileset. I suspect that this section should show the tileset being used
      when APRSIS32 is closed or restarted.

      Should the program be updating this section, or have I been missing a
      manual method to specify a default tileset?

      This program has us hooked, and the hook is set. When Lynn is able to
      devise alternate methods to place objects by coordinate and read
      coordinates of a point on the map (other than manually moving the
      cursor), we'll be able to get rid of additional programs. No this isn't
      a new request, it's already on Lynn's list (we hope, we hope).

      What are we needing this for? We're Search and Rescue. Comm provides
      cellphone coordinates of lost/injured caller, maybe good, maybe not
      (more and more the coords are relevant and not for a distant cell
      tower). Coords are nothing (just a pile of numbers) until you plot
      them, in whatever format they are provided (decimal degrees, usually).
      Then we translate the coords to our standard decimal minutes (same as
      aviation and same as APRS) and recite them to the helicopter. Then I
      point at a helispot next to the trail that is relatively close to the
      exhausted hiker and recite coordinates to the bird. They land, walk 15
      minutes up-trail and provide water and support to the patient, and
      assist her to the bird (not running!). Then I point to a helipad where
      we'd like the patient delivered, and recite more coordinates.

      Meanwhile the map continues to display the area of the operation. If I
      try to do all of this with only APRSIS32, I have to be parked on the
      side of the road. I have to reset the map to different points at high
      zoom with different tilesets that show points the best. And I have to
      calculate the format changes by hand. Bah! Not gonna happen.

      So I use a second mapping application. Place a waypoint on the map,
      change display format, edit coords, change display format back to
      decimal minutes, done deal. And I can do this at a traffic light (the
      only advantage of red lights is having a few moments to work on map).
      Way too complex for APRSIS32, so far. The purpose of relating this tale
      is not so much to entertain y'all, but to give Lynn an opportunity to
      sit in my seat. Perhaps he would like to be able to handle these needs
      by using APRSIS32. Maybe not. His program. His choice. The example
      is real, and typical, from the day before yesterday (Sunday).

      Anyway, we're certainly happy with APRSIS32 and are still busy creating
      mapsets (thanks to the available on-line sources, and to Global Mapper
      for supporting the OSM tileset format), and we are still creating more
      GPX files of trails in our area (thanks to Google Earth, and to Global
      Mapper for translating KMZ to GPX, and to APRSIS32 for providing GPX
      attributes for displaying the files). Yeah, other programs can create
      the GPX files, but while I'm using Global Mapper anyway ...

      Returning from my digression: So what about setting the default tileset?

      73 de Mykle N7JZT
      Tucson
    • Lynn W Deffenbaugh (Mr)
      ... Wbatever tile set has the checkmark in the Configure / Map / Tile Sets-cascade is the one that will be used on a restart as well as used for any new
      Message 2 of 3 , Oct 2, 2012
      • 0 Attachment
        On 10/2/2012 10:47 AM, Mykle Raymond wrote:
        > The default tileset is not the one most recently added, so I switch to
        > the usual one. However, the new one continues to be default, not the
        > one being used when restarting or exit/start (I've been trying
        > alternative ways of getting another tileset to "stick", but no success,
        > not that there are many alternatives).

        Wbatever tile set has the checkmark in the Configure / Map / Tile
        Sets-cascade is the one that will be used on a restart as well as used
        for any new MultiTracks that you open.

        The checked Tile Set will be the last one that you clicked Accept on via
        the Configure / Map / Tile Sets / <Whatever> configuration dialog.

        So to change the default startup and MultiTrack Tile Set, select it from
        the Configure / Map / Tile Sets cascade and click Accept.

        > Looking at the XML file, each of the TileServer sections is present and
        > appears to be the same format. Just above the TileServer sections is a
        > section of <OSM.xxxx> entries, which is currently specifying the new
        > tileset. I suspect that this section should show the tileset being used
        > when APRSIS32 is closed or restarted.
        >
        > Should the program be updating this section, or have I been missing a
        > manual method to specify a default tileset?

        Yes, it should, and that's what clicking Accept on a Tile Set
        configuration does, it copies the information from the TileServer to the
        OSM.* legacy entries.

        > This program has us hooked, and the hook is set. When Lynn is able to
        > devise alternate methods to place objects by coordinate and read
        > coordinates of a point on the map (other than manually moving the
        > cursor), we'll be able to get rid of additional programs. No this isn't
        > a new request, it's already on Lynn's list (we hope, we hope).

        Have you tried right-clicking on the map and notice the coordinates
        listed at the bottom of that popup menu? I know it's not everything you
        need, but is that the idea of "read coordinates of a point on the map"
        (although I'm not sure how any program would know what coordinate you
        want to read without you "manually moving the cursor" somehow)?

        Thank you for taking the time to describe the actual use case. I'm
        probably going to copy this e-mail to the bottom of the ToDo list
        because it's a really good description of the needs. User Interface
        isn't at the top of the priority list, but I will be getting to this
        sometime.

        Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
      • Mykle Raymond
        ... It works! There is a difference between the check-mark in Screen | Tile Set (selects the tileset to display) and Configure | Map | Tile Sets
        Message 3 of 3 , Oct 2, 2012
        • 0 Attachment
          > Posted by: "Lynn W Deffenbaugh (Mr)" kj4erj@... ldeffenb

          > Wbatever tile set has the checkmark in the Configure / Map / Tile
          > Sets-cascade is the one that will be used on a restart as well as used
          > for any new MultiTracks that you open.

          It works! There is a difference between the check-mark in
          Screen | Tile Set (selects the tileset to display)
          and
          Configure | Map | Tile Sets (selects the default AND tileset to display)

          >> This program has us hooked, and the hook is set. When Lynn is able to
          >> devise alternate methods to place objects by coordinate and read
          >> coordinates of a point on the map (other than manually moving the
          >> cursor), we'll be able to get rid of additional programs. No this isn't
          >> a new request, it's already on Lynn's list (we hope, we hope).
          >
          > Have you tried right-clicking on the map and notice the coordinates
          > listed at the bottom of that popup menu? I know it's not everything you
          > need, but is that the idea of "read coordinates of a point on the map"
          > (although I'm not sure how any program would know what coordinate you
          > want to read without you "manually moving the cursor" somehow)?

          Yes, that is useful to a limited degree. If I need to retrieve
          coordinates of a point, then I'll need to zoom in a lot, and maybe
          switch maps to an image. More of an argument for having a separate app.
          More arguments for that below.

          You are referring to the "cursor" as the crosshairs at the
          center-of-display. I can move the arrow to point at something else. If
          I wanted to mark a point, I'd point at it (with the arrow), right-click
          and select an option to place something there, then an attribute dialog
          would open that includes the ability to type coordinates and change the
          location. The dialog would also provide for choice of icon, comments,
          make-this-an-object, blah-de-blah. This I could do on the fly .. throw
          a point on the map and edit coordinates. Perfect.

          IDEALLY (I know that different platforms may make this problematic) a
          coordinate entry would automatically handle different formats (this
          would not be the first program to do so). Space or comma delimited.
          The first entry is degrees. The second is minutes. The third is
          seconds. One to three entries, use what you need. Any of them can be
          decimal (although only the last one should be decimal if any).

          You should consider the rest of the world, so we don't have to always
          include North/South and East/West, or use minus-signs. The map/
          crosshairs are in one geographic quadrant, so apply that to coord entry.

          This would be one place where the APRS format would not be appropriate.
          DDMM.mm would be hard to detect, rather than decimal degrees.

          The program can probably stick with decimal minutes, just to keep things
          simple. Only coordinate entry may provide for alternative formats.

          No, we don't need conversions between datums, since we assume the APRS
          standard which is the same as the GPS standard, WGS-84. That's an
          advanced topic and you'd better have an that can provide it. A
          dedicated mapping app should be sufficient (I use OziExplorer).

          No, we don't need conversions between projections (UTM). Use your
          mapping app.

          No kitchen sink needed, either. (a wash basin might be nice)
          73 de Mykle
        Your message has been successfully submitted and would be delivered to recipients shortly.