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

RE: [aprsisce] Zoom stuff

Expand Messages
  • Fred Hillhouse Jr
    I m not sure how you did your math to get 186G, I joined one of the OSM groups. One of the guys there rendered and sent me the zoom 12 tiles for New England
    Message 1 of 3 , May 29, 2010

      I'm not sure how you did your math to get 186G,

      I joined one of the OSM groups. One of the guys there rendered and sent me the zoom 12 tiles for New England minus Maine . He calculated that rendering 12- 18 for the same area would take about 200 hours and be about 186GB for the lot. I have to believe him since I have no other reference.

       nor why you'd need to fetch the whole of New England onto a single device at the fully detailed zoom level,

      This area has poor cell phone coverage so downloading tiles on the fly is really not an option. And the continuous connection concept is beyond my current budget. I do like to get out and about. I like APRS running too and I like to see where I am on a map. I usually have the DeLorme State map next to me too. I have a small collection of these, only about 10 of them or so. These are the big red book of map that you may see in the grocery store. Maine ’s is kind of sea-green.

      That's certainly an extreme application of pre-fetch.

      Not really given the basic requirements of just wanting to have it. ;) There is reasoning behind the requirement. I see it like having a town/state map at my finger tips. Most of the time, I only need the area where I live. I work 40 mile as the crow flies so my living area is fairly large. On really bad traffic days I go find alternate routes. They may take longer than normal but they are usually more peaceful. I now know the area quite well but sometimes I need more information, so I pull out the map. In this case, it is already running on the laptop next to me. At the higher zooms, the street names are visible. This is quite useful. So I don’t really know how extreme it is but I like them on the machine. For me APRSIS32 is more than just an APRS application; it is map solution as well.

      I'll also admit to not having crunched through your entire suggestion, but will put it on file for when my attention is directed back at the maps and such, including an improved pre-fetcher and cache "freshner" approach. It may become applicable at that point. Skipping every other level and such approaches might have merit, but I more suspect that just limiting the lower levels and allowing full fetch and stretch of the levels above that will consume less disk space and still give you a reasonable render. I'll have to play with the options there.

      It was just a thought that might have merit.

      Remember, the zoom level stats at http://wiki.openstreetmap.org/wiki/Slippy_map_tilenames are for the entire planetary surface. At zoom 12, there's only 4096x4096 (16Million) for the Earth, New England would be substantially smaller.

      I read (long E) that and am mostly confused. :P But I haven’t given up. At some point it will be clear as mud and then I’ll be able to clean it up some. ;)

      I'd still allow the program to display non-selected zoom levels. It'll just automatically stretch the closest available zoom level tile.

      By adding a ‘skip’ option the user could make that choice. I find that I am at a zoom where street names (~level 15) can be seen or zoomed out to see more. I don’t have the level but typically 5 to 20 miles on the circle.

      I'm actually considering a smoother, fractional zoom that would do the same thing between the OSM levels because I think the doubling is too extreme for some uses.

      Zipping PNGs only serves to reduce the file count and round-off space in storage clusters. The PNGs themselves are usually so compressed that most compression tools simply store them or at most get maybe 2-3% reduction. It is a handy way to move an entire OSMTiles tree from one machine to another, though.

      I was wondering is file compression might make a difference but it the access times would suffer so I chose not to explore it.

      The defaults for retaining levels 00 through 05 don't add up to much space on "disk" which is why they're the defaults.

      True but I didn’t realize they were defaults. Just convert the zoom levels in my example to 10-15. J

       The level-specific stats for my entire OSMTiles tree are below. You can see your own if you look at the OSM trace window. These values are forced into the window on every purge pass, so you don't need to keep it enabled. When it opens, click Enable on the menu to stop the new stuff from going in.

      I will have to re-read this again later. I don’t purge tiles at all unless I messed up my XML and forgot to change the purge setting. I hate when I do that. My laptop purged a bunch of tiles and now I have to fetch them again.

      I'll second your PS as well: "Remember those that gave their life so we may be free!"!

      Ham radio is what is what is it partially because of those that died before us! Some countries have very little radio options.

      Lynn (D) - KJ4ERJ - Crunching on your suggestion...

      Thanks!

      Best regards,

      Fred – Thinking of new suggestions…



      OSMCalcTileStats:Level[00] Retained 1 in 8.33KB
      OSMCalcTileStats:Level[01] Retained 4 in 24.85KB
      OSMCalcTileStats:Level[02] Retained 16 in 126.83KB
      OSMCalcTileStats:Level[03] Retained 64 in 295.97KB
      OSMCalcTileStats:Level[04] Retained 256 in 931.32KB
      OSMCalcTileStats:Level[05] Retained 1024 in 2.62MB
      OSMCalcTileStats:Level[06] Purged to 186 in 1.47MB
      OSMCalcTileStats:Level[07] Purged to 423 in 3.08MB
      OSMCalcTileStats:Level[08] Purged to 338 in 2.42MB
      OSMCalcTileStats:Level[09] Purged to 441 in 4.24MB
      OSMCalcTileStats:Level[10] Purged to 810 in 12.89MB
      OSMCalcTileStats:Level[11] Purged to 1211 in 14.61MB
      OSMCalcTileStats:Level[12] Purged to 1629 in 15.20MB
      OSMCalcTileStats:Level[13] Purged to 1461 in 14.42MB
      OSMCalcTileStats:Level[14] Purged to 1813 in 13.49MB
      OSMCalcTileStats:Level[15] Purged to 2454 in 15.68MB
      OSMCalcTileStats:Level[16] Purged to 2799 in 12.54MB
      OSMCalcTileStats:Level[17] Purged to 3650 in 11.98MB
      OSMCalcTileStats:Level[18] Purged to 1885 in 3.58MB
      Total OSM Files 20466 in 135870633 Bytes

      Fred Hillhouse wrote:

      > Hi Lynn ,
      >
      >
      > The tiles are increasingly interesting to me.
      >
      > If I were to grab the New England (minus
      w:st="on">Maine ) at zoom levels 12-18, it
      > would be 186G (zipped) of data or so. That is a lot of data! And,
      definitely
      > a large load on the OSM tile servers. Of course, if it was spread over a
      > long time, maybe it would be less painful to everyone. So grabbing all the
      > tiles for each level is probably not good.
      >
      > So, I am proposing an addition to the XML file. Of course, someday a
      window
      > box would be helpful so XML editing would not be needed.
      >
      > The plan would be to only get tiles for the levels selected. You added a
      > minimum and maximum and that was appreciated. If could also not display a
      > zoom level that is not enabled, that might be an improvement as well. This
      > means if level 14 was disabled, then the UP/DOWN arrows would cause the
      > zooming to go from 13 to 15 or 15 to 13.
      >
      > The list below would make it easy on a user to see and modify. Of course,
      if
      > there was a particular zoom level needed at minimum, it could be left off
      > the list.
      >
      > Maybe level 0 can't be 'not loaded' of skipped.
      > [If that is the case, it shouldn't be here at all.]
      >
      > <OSM.ZoomFetch0>1</OSM.ZoomFetch0> grab this level tiles
      > <OSM.ZoomSkip0>0</OSM.ZoomSkip0> don't skip and do whatever
      you do now to
      > fill in missing tiles
      >
      > <OSM.ZoomFetch1>0</OSM.ZoomFetch1> don't grab this level tiles
      > <OSM.ZoomSkip1>1</OSM.ZoomSkip1> skip when changing levels
      >
      > <OSM.ZoomFetch2>0</OSM.ZoomFetch2> don't grab this level tiles
      > <OSM.ZoomSkip2>1</OSM.ZoomSkip2> skip when changing levels
      >
      > <OSM.ZoomFetch3>1</OSM.ZoomFetch3> grab this level tiles
      > <OSM.ZoomSkip3>0</OSM.ZoomSkip3> don't skip and do whatever
      you do now to
      > fill in missing tiles
      >
      > <OSM.ZoomFetch4>0</OSM.ZoomFetch4> don't grab this level tiles
      > <OSM.ZoomSkip4>0</OSM.ZoomSkip4> don't skip and do whatever
      you do now to
      > fill in missing tiles
      >
      > I'll stop there. I bet you get the idea. :)
      >
      > To help facilitate the user selecting the zoom levels, the numeric zoom
      > level would be very useful. It could be in addition to the bar graph or in
      > place of it. On my desktop here (-AP), and maximized, I am at zoom level
      "~1
      > mile of circle range thingy". It is the first level with street
      names.
      > According to my XML I am at zoom level 15. That means that I can pretty
      much
      > navigate by street name without zooming in further. Although, I just
      looked
      > at another part of the country and level 15 seems to be where the street
      > names are added. Sigh. I guess that is something one figures out when they
      > are visiting different areas.
      >
      > The same area quoted above would not be 186GB (zipped) but only 2.2GB
      > (zipped) for level 15 plus the lower zoom levels (0, 1, 2, ... 14) for
      > probably less than 3.0GB. I have for level 12 less than 50 MB and it
      > includes the whole area plus some of
      w:st="on">Maine . This would all fit on a 4GB SD
      > card. Of course it will take no short amount of time to right to the card.
      >
      > How this affects perfecting at the higher zoom levels I am not completely
      > sure. But I imagine that if the level is not enabled, it should not be
      > grabbed. I think right now if I move to the highest level, it will still
      > grab above the maximum but I am not sure.
      >
      >
      > Just a few thoughts for the long weekend! :D
      >
      > Thanks for listening! And thanks for the cool software!
      >
      > Have a great weekend!
      >
      >
      > Best regards,
      > Fred N7FMH
      >
      > PS. Remember those that gave their life so we may be free!
      >

    Your message has been successfully submitted and would be delivered to recipients shortly.