Re: [osg-users] [VPB] Overriding source reprojection requirement in vpbmaster
Hi Glenn, It's correct vpbmaster refuses to do a build if the sources aren't all the same coordinate system as otherwise running osgdem on multiple processes at the same time would cause multiple reprojections on the same data at the same time and an unholy mess. The way to manage the reprojection is do it as a preprocessing step, creating a cache of reprojected data. For this you use another tool vpbcache. I'm looking after my little 4 year old right now so can't answer any further right now - we're going out for walk!! Robert. On Sat, Mar 29, 2008 at 12:50 AM, Glenn Waldron [EMAIL PROTECTED] wrote: Robert, I've noticed that vpbmaster refuses to continue if it detects that all sources are not in the same coordinate system. I can certainly understand why. That said, is there a way to override this decision and tell vpbmaster to trust me that all sources are in a common projection? Case in point: GDAL's ECW (ER Mapper compressed wavelet raster) plugin is sometimes not able to correctly parse the coordinate system information in the file. (This is a known issue -- http://www.gdal.org/frmt_ecw.html). So vpbmaster won't run since it thinks the ECW is in a different projection than other input layers. I tried using the --cs option to manually specify the CS; also --ReprojectSources False; no luck in either case. I'm running on Win32 with the latest SVN head of OSG and VPB. Glenn -- Glenn Waldron : Pelican Mapping : http://pelicanmapping.com : 703-652-4791 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [VPB] Overriding source reprojection requirement in vpbmaster
Hi Glenn, If VPB is reading the coordinate systems for the source and the required target coordinate system and not matching them it'll reproject, this matching does rely upon the WTK strings to be equal, so perhaps this is where the divergance is occurring. I don't have any ECW data or plugin available under Linux so I can test this route personally. Try using gdal to convert from ECW to GeoTiff and pass the GeoTiff's into VPB. Robert. On Sat, Mar 29, 2008 at 12:28 PM, Glenn Waldron [EMAIL PROTECTED] wrote: Robert, I didn't explain myself properly. All my data is indeed reprojected in advance. The issue is that vpbmaster just *thinks* the data needs reprojection -- I suspect the fault lies with the ECW plugin -- and so I'd like to override the check and tell vpbmaster to forge ahead anyway and treat the data as if it needs no reprojection. Which it doesn't. :) Does that make sense? I hope you enjoyed your walk! Glenn On Sat, Mar 29, 2008 at 5:20 AM, Robert Osfield [EMAIL PROTECTED] wrote: Hi Glenn, It's correct vpbmaster refuses to do a build if the sources aren't all the same coordinate system as otherwise running osgdem on multiple processes at the same time would cause multiple reprojections on the same data at the same time and an unholy mess. The way to manage the reprojection is do it as a preprocessing step, creating a cache of reprojected data. For this you use another tool vpbcache. I'm looking after my little 4 year old right now so can't answer any further right now - we're going out for walk!! Robert. On Sat, Mar 29, 2008 at 12:50 AM, Glenn Waldron [EMAIL PROTECTED] wrote: Robert, I've noticed that vpbmaster refuses to continue if it detects that all sources are not in the same coordinate system. I can certainly understand why. That said, is there a way to override this decision and tell vpbmaster to trust me that all sources are in a common projection? Case in point: GDAL's ECW (ER Mapper compressed wavelet raster) plugin is sometimes not able to correctly parse the coordinate system information in the file. (This is a known issue -- http://www.gdal.org/frmt_ecw.html). So vpbmaster won't run since it thinks the ECW is in a different projection than other input layers. I tried using the --cs option to manually specify the CS; also --ReprojectSources False; no luck in either case. I'm running on Win32 with the latest SVN head of OSG and VPB. Glenn -- Glenn Waldron : Pelican Mapping : http://pelicanmapping.com : 703-652-4791 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Glenn Waldron : Pelican Mapping : http://pelicanmapping.com : 703-652-4791 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [VPB] Overriding source reprojection requirement in vpbmaster
Robert, Exactly: it is quite possible for different WKT strings to represent the same CS -- I don't think there is a canonical WKT representation per se. I have the same challenge in osgGIS. ECW=GeoTIFF would work but ... unfortunately most of my ECW's are just plain large -- in one case I have 0.15m imagery covering 4000 sq kms. If you do have the time, I have uploaded a sample dataset that demonstrates the issue. There is a small ECW and a corresponding DEM (GeoTIFF). They are both WGS84. The build command line is included: http://pelicanmapping.com/downloads/ecw-sample.zip FWTools contains a pre-built GDAL library with ECW support included: http://fwtools.maptools.org/ Thanks again for your continued great work! I am especially appreciative of the upgrades to DatabasePager and look forward to test-driving this soon. Glenn On Sat, Mar 29, 2008 at 8:36 AM, Robert Osfield [EMAIL PROTECTED] wrote: Hi Glenn, If VPB is reading the coordinate systems for the source and the required target coordinate system and not matching them it'll reproject, this matching does rely upon the WTK strings to be equal, so perhaps this is where the divergance is occurring. I don't have any ECW data or plugin available under Linux so I can test this route personally. Try using gdal to convert from ECW to GeoTiff and pass the GeoTiff's into VPB. Robert. On Sat, Mar 29, 2008 at 12:28 PM, Glenn Waldron [EMAIL PROTECTED] wrote: Robert, I didn't explain myself properly. All my data is indeed reprojected in advance. The issue is that vpbmaster just *thinks* the data needs reprojection -- I suspect the fault lies with the ECW plugin -- and so I'd like to override the check and tell vpbmaster to forge ahead anyway and treat the data as if it needs no reprojection. Which it doesn't. :) Does that make sense? I hope you enjoyed your walk! Glenn On Sat, Mar 29, 2008 at 5:20 AM, Robert Osfield [EMAIL PROTECTED] wrote: Hi Glenn, It's correct vpbmaster refuses to do a build if the sources aren't all the same coordinate system as otherwise running osgdem on multiple processes at the same time would cause multiple reprojections on the same data at the same time and an unholy mess. The way to manage the reprojection is do it as a preprocessing step, creating a cache of reprojected data. For this you use another tool vpbcache. I'm looking after my little 4 year old right now so can't answer any further right now - we're going out for walk!! Robert. On Sat, Mar 29, 2008 at 12:50 AM, Glenn Waldron [EMAIL PROTECTED] wrote: Robert, I've noticed that vpbmaster refuses to continue if it detects that all sources are not in the same coordinate system. I can certainly understand why. That said, is there a way to override this decision and tell vpbmaster to trust me that all sources are in a common projection? Case in point: GDAL's ECW (ER Mapper compressed wavelet raster) plugin is sometimes not able to correctly parse the coordinate system information in the file. (This is a known issue -- http://www.gdal.org/frmt_ecw.html). So vpbmaster won't run since it thinks the ECW is in a different projection than other input layers. I tried using the --cs option to manually specify the CS; also --ReprojectSources False; no luck in either case. I'm running on Win32 with the latest SVN head of OSG and VPB. Glenn -- Glenn Waldron : Pelican Mapping : http://pelicanmapping.com : 703-652-4791 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Glenn Waldron : Pelican Mapping : http://pelicanmapping.com : 703-652-4791 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Glenn Waldron : Pelican Mapping : http://pelicanmapping.com : 703-652-4791 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] [VPB] Overriding source reprojection requirement in vpbmaster
Robert, I've noticed that vpbmaster refuses to continue if it detects that all sources are not in the same coordinate system. I can certainly understand why. That said, is there a way to override this decision and tell vpbmaster to trust me that all sources are in a common projection? Case in point: GDAL's ECW (ER Mapper compressed wavelet raster) plugin is sometimes not able to correctly parse the coordinate system information in the file. (This is a known issue -- http://www.gdal.org/frmt_ecw.html). So vpbmaster won't run since it thinks the ECW is in a different projection than other input layers. I tried using the --cs option to manually specify the CS; also --ReprojectSources False; no luck in either case. I'm running on Win32 with the latest SVN head of OSG and VPB. Glenn -- Glenn Waldron : Pelican Mapping : http://pelicanmapping.com : 703-652-4791 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
