Norman,
Your solution works perfectly! Thanks a lot.
For the benefit of others, here is my Win32 build batch file. (That
odd-looking first line just reads the contents of a WKT .prj file into a
variable.)
for /F delims= %%p in (boston-image.prj) do set prj=%%p
gdal_translate -of vrt -a_srs %prj% boston-image.ecw boston-image.vrt
gdal_translate -of vrt -a_srs %prj% boston-dem.tif boston-dem.vrt
vpbmaster --terrain -d boston-dem.vrt -t boston-image.vrt -o out.ive
On Sat, Mar 29, 2008 at 11:48 AM, Norman Vine [EMAIL PROTECTED] wrote
Glenn Waldron writes:
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.
Glenn,
Have you tried using GDAL's VRT format to pass the projection info
http://www.gdal.org/gdal_vrttut.html
In a nutshell create a .vrt file with the correct projection
gdal_translate -of vrt -a_srs $YOUR_SRS $IN_FILE.ecw $OUT_FILE.vrt
You may need to tweak the resultant .vrt file
Then pass VPB the .vrt files instead of the ecw files
Of course this assumes you know your desired SRS
http://spatialreference.org/ is a handy site
HTH
Norman
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
