Re: [Viking-devel] Viking 1.0.2 and 1.1 Projections
2011/5/14 Greg Troxel : > 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. If depending to proj is too heavy, we have to estimate the possibility of having both systems, with conditional compilation, in orderr to enable proj support, or current system. Wiki page is there for this reason: collect any though about the idea. -- 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 writes: > 2011/5/14 Greg Troxel : >> >> 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/
Re: [Viking-devel] tile age 30s ???
2011/5/13 Robert Norris : > > >>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] git repositories?
2011/5/10 Greg Troxel : > > Robert Norris writes: > >>> It looks like Rob is now working directly in the SF repo. >> >> Since I have commit privileges, 'simple' fixes / small changes get >> applied directly to the SF repo. >> This is a maintainer thing as they don't necessarily need any feedback >> before being applied. > > That's totally fine - I didn't mean to be critical of it. I was just > trying to figure out which repo to follow. Yes, it's true that this information is missing in source package. Even DOAP file does not contain the reference to the "official" Git repo (yes, Sourceforge hosted Git repo is currently the official one). >>> I'd like to see a HACKING.git in the official repo that lists all the >>> URLs of actively-maintained versions. Sort of like a list of forks, >>> but without buying ito any repo service as the one true way. >>> >>> So, can people explain what counts these days? >> >> I don't think this needs to be in the source, perhaps in the Wiki - >> contribute' part. > > It's vastly more important to be somewhere, of course, and that seems > fine. Even after logging in to sourceforge (I am 'lexort'), there's no > edit tab. > > My preference for being in the source comes from 1) me being from the > pre-wiki generation and 2) it follows git's notion of distributed > version control and local operations - so having a clone means you have > all the data. I'm finally fully agree with Greg. Initialy I imagined that whole documentation should be in the wiki. But I revised my opinion. I vote for having as much information in text files in the code. The main reason is that it ensure that documentation/information is always in sync with code and hackers will have hability to fork (even us if we decide to leave Sourceforge one day). The wiki should (probably) serve two goals (at least): - website, advertising about viking - community site, to share map sources or enumerate personnal forks of the Git repo. So please, add the Git repo URL and contribution conventions to HACKING file. -- 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
One other note on DRGs in case it isn't clear. When one selects "New GeoRef Map Layer," the tfw file that listgeo creates is the "World File Parameters" file specified in the "New GeoRef Map Layer" dialog box. Also, a bunch of free DRGs seem to be available at: http://www.mapcruzin.com/usgs-drg-topo-topographics-maps/usgs-drg-topographic-m aps.htm if one is looking for USGS DRGs... Harry McGavran On Sat, 14 May 2011 08:46:30 -0400 Greg Troxel wrote: --- Begin Message --- 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. pgpllHjRwPlN1.pgp Description: PGP signature --- End Message --- -- Harry G. McGavran, Jr. E-mail: w5...@w5pny.com -- 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
2011/5/14 Harry G McGavran Jr : > Why on earth Viking uses tfw files when the information > it needs is in the geotiff header I don't know. > It's hard to believe that code isn't there. But > listgeo will extract that info from the geotiff file > and create the tfw file. Projection support in Viking is really simple currently: only three simple projections. Thus, support for georeferenced image is simpler. One of the simplification used is that only the tfw format is implemented (hard coded). The code already exists and is called proj4 and gdal. But currently viking does not use these libraries. -- 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
To answer Greg's questions specifically, I beilieve DRGs ARE Geotiffs, so you should be able to follow the steps I sent. To get the tfw file, you can use "listgeo -tfw getiff_file_name" and on Ubuntu at least, listgeo is in the geo-bin package. Why on earth Viking uses tfw files when the information it needs is in the geotiff header I don't know. It's hard to believe that code isn't there. But listgeo will extract that info from the geotiff file and create the tfw file. Harry McGavran On Sat, 14 May 2011 08:46:30 -0400 Greg Troxel wrote: --- Begin Message --- 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. pgpM81qoYtpvv.pgp Description: PGP signature --- End Message --- -- Harry G. McGavran, Jr. E-mail: w5...@w5pny.com -- 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
One loads his gpx file with File->Open, and one loads the geotiff with Layers->New GeoRef Map Layer and selects the tif and the loads the tfw file for that tif and moves the Map layer down below the gpx layer in the Layer Name menu. That displays the track on the map but shifted by the projection difference. I didn't see any way to configure viking to handle the projection difference. It used to do this correctly. Viking should handle the different projections of different layers. If it only does WGS85, NAD27s and therefore geotiffs are useless. It's certainly a disappointment for me, I figured I just couldn't find how to configure viking to handle that. Harry McGavran On Sat, 14 May 2011 08:46:30 -0400 Greg Troxel wrote: --- Begin Message --- 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. pgp4dpkaz3pLa.pgp Description: PGP signature --- End Message --- -- Harry G. McGavran, Jr. E-mail: w5...@w5pny.com -- 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
2011/5/14 Greg Troxel : > > 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). > 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). -- 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
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/
