Re: [Viking-devel] Viking 1.0.2 and 1.1 Projections
I haven't tried geotiff, but I do have DRG images for my region (in NAD27). If you could send a note how you configure that, I'll try it. I wonder if viking should depend on proj. pgpTNWHc5IXqh.pgp Description: PGP signature -- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay___ Viking-devel mailing list Viking-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/viking-devel Viking home page: http://viking.sf.net/
Re: [Viking-devel] tile age 30s ???
2011/5/13 Robert Norris rw_nor...@hotmail.com: The default for tile age seems to be 30s. This seems way too short. While someone actively mapping in OSM might want to reload, it seems like map tiles are relatively static over that kind of timescale. I have set the tile age to 604800s (1 week). It seems rude to OSM to recheck tiles more often than once a day, or maybe once an hour. For terraserver DRG and imagery, 1 week is perhaps too short - those bits are quite static. What's the motivation for 30s? Would anyone object to changing it to 1 week? No idea why it was set to 30. Presumably because that's better than 1 second! I thought the default was changed, but double checking shows it was just upping the max allowable value in gui preference. Maybe the value should be shown in days/hours. I mean how useful is it to set it to 54320 seconds? - what does that even mean! Agreed 1 week is much better, although personally I use 1 day (86400s) which might be better for OSM type usage. Please, note that such SMALL delay was coupled with the ability to check the status of files on remote without downloading it. So, theorically, the load on server is quite reasonable. But it seems our implementation of this part is perfectible. Other note: due to theory of observation, the refresh frequency should be more than twice the effective refresh on server. The better example for this, is the case of a clock: the UI part should use a timer less than half a second (for example 0,4 second) in order to ensure the clock always displays the right value. So, if you think tiles are refreshed once a day, you have to set a value less than half a day. Example: with a 1 day delay, if tile is changed in 1 day + 1 second, you will wait 2 days before having the fresh tile. Other note: how work web browsers about this? What is the delay used? Another alternative could be to have another tile age for 'non-volatile'* maps such as mentioned: terraserver, bing, etc... *better name needed - stable? Which would default to something like a month. Why not only zero, in order to only alow manual refresh? -- Guilhem BONNEFILLE -=- JID: gu...@im.apinc.org MSN: guilhem_bonnefi...@hotmail.com -=- mailto:guilhem.bonnefi...@gmail.com -=- http://nathguil.free.fr/ -- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay ___ Viking-devel mailing list Viking-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/viking-devel Viking home page: http://viking.sf.net/
Re: [Viking-devel] Viking 1.0.2 and 1.1 Projections
Guilhem Bonnefille guilhem.bonnefi...@gmail.com writes: 2011/5/14 Greg Troxel g...@ir.bbn.com: I haven't tried geotiff, but I do have DRG images for my region (in NAD27). If you could send a note how you configure that, I'll try it. I don't know what NAD27 is. AFAIK, currently, viking only support 3 projections: UTM, Mercator and LatLon (I don't have corresponding codes as I' writing). Those are projections, which are ways to convert coordinates in lat/lon to numbers on some plane. NAD27 is a datum, which is a separate concept, about how particular lat/lon coordinates are assigned to particular places. Today, WGS84 is used for most things, and it's ~= to ITRF00 at the few mm level. There is also NAD83, the official datum of the US, which is a few meters different, and other datums in other places around the world. NAD27 is from 1927, and coordinates differ by tens of meters. It was the official datum of the US before NAD83, and many USGS topo maps are in NAD27. Plus NAD27 uses a different ellipsoid. So one has to transform to/from WGS84 to NAD27 to use USGS DRGs with GPS data. What I don't understand is how this ever worked. I wonder if the GPS data had been transformed to NAD27?? Perhaps gpsbabel can do that. Long term, viking should be projection and datum aware. I wonder if viking should depend on proj. I think so. I started to look a the proj4 library, but it is certainly a significant change, reclaiming long time invest. And I don't have this time currently. But proj support will certainly be a great add. Anynbody working on this would gain all my support. Note that I started to wrote notes about this on the following wiki page: https://sourceforge.net/apps/mediawiki/viking/index.php?title=Idea:gdal Feel free to contribute (on code or on this page). I have used proj, and it's pretty easy. The key question is if it's ok to depend on it, which requires anyone using viking to have it. But I think most geo software does already. I am generally in favor of requiring it, but I think we should understand/plan a bit better first. pgp095ZlGDzHh.pgp Description: PGP signature -- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay___ Viking-devel mailing list Viking-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/viking-devel Viking home page: http://viking.sf.net/
