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

Re: [aprsisce] The map tiles directory structure

Expand Messages
  • Lynn W. Deffenbaugh
    Well, as James pointed out, I really strive hard to adhere to standards, so I went right out to OSM to see what they say only to discover that they re mum on
    Message 1 of 3 , Apr 24, 2010
      Well, as James pointed out, I really strive hard to adhere to standards,
      so I went right out to OSM to see what they say only to discover that
      they're mum on the subject. So I fired up my original sample tile links
      for the tile server and discovered.....they'll take it BOTH WAYS!


      As a matter of fact, their page describing the names doesn't even
      mention leading zeros or not and their example (wisely?) chose a zoom
      level of 12 at the bottom of

      So, I looked into the source to figure out why it is the way it is only
      to discover that I put the leading zero only on the zoom level and only
      for the local file name. I do not put the leading zero on the URL that
      is fetched....Hm...Why was I that inconsistent? Then I remembered!

      Operating systems prior to Vista and Windows 7, like Windows Mobile,
      weren't "numerically aware" when sorting file names. If you had names
      of 0, 1, 2, ..., 9 mixed in with 10..18, a directory listing would be 0,
      1, 10, 11, ... 18, 2, 3, 4... 9. Ugly. And difficult for my eyes when
      I happened to open a folder view of the OSMTiles directory, so to make
      it "look" better, the leading zero was born. It also allows
      character-based filename sorting in the code without having to be aware
      of, and parse through, numbers to get the order correct.

      So, there's a method behind my apparent madness. Which is "correct",
      both of them. Which is the one I'm using, the pretty & easy one. Is
      there anything you can do? Yes. If you're on Win32 (and I don't think
      there's that many Windows Mobile programs out there using, let alone
      caching, OSM tiles), find a program that lets you establish "hard links"
      which are like *nix's links and link 00 to 0, 01 to 1, and so forth (or
      vice versa). Our respective programs, as far as I understand it, will
      be unaware that the directory isn't named what we expect it to be named
      and you'll have complete sharability of the caches.

      Let me know if that works and doesn't mess up the tile purger (save a
      copy just in case APRSIS32 ends up purging your tree). In the meantime,
      I'll add an entry to the ToDo list to possibly support configuring
      leading or non-leading zero directories natively, but as James pointed
      out, if you get yet another program that wants to use your cache, you
      might still have to roll your own hard linked directories.

      Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32

      VE3NVK wrote:
      > I use both APRSISCE and D-Rats on a Windows 7 system. Both programmes use the same openstreetmap mapnik png map tiles, so I decided that to minimize duplicate downloads that I would use a common map tiles directory.
      > This is where I ran into not a problem, but a nuisance. For all of the directories numbered less than ten, the naming protocol used is different. In APRSISCE, the directories use a prefix of zero such as 01, but D-rats uses a single number such as 1. This means that my goal on minimizing downloads is not fully realized.
      > I mentioned this aspect to the developer of D-rats, as I thought myself that the double digit numbering scheme was a better one, but his feedback was that he was using the openstreetmap numbering scheme, and was thus unlikely to change.
      > So I am asking can a change be anticipated in APRSISCE to have a consistent directory naming structure? It is probably not a great deal in the amount of map tiles downloaded, but it would be nice to be consistent.
      > 73;
      > Andy Hart - VE3NVK
    Your message has been successfully submitted and would be delivered to recipients shortly.