FSXA NY Orthos are in feet, not meters.

[JohnC1]

New York Orthoimagery is in feet not in meters. Coincidentally, I am getting coordinates using FWTools on New York that are way off.
Is there a methodology to convert/or/adjust this using FWTools? I have 340+ images so hand inputs into separate inf files is not an option.
I have to rely on the SDK for FSXA and this Forum's wiki.

 

[arno]

Hi,

As long as the coordinate system is defined correctly it should not matter if they are in meters or feet. So what makes you think the units are wrong?

And when you say that FWTools gives you wrong coordinates, how do you check the resulting coordinates?

P.S. FWTools is really old and not maintained anymore, I would not use it anymore. If you install QGIS you get a much newer version of the GDAL tools included that you can use from the "OWGeo4W Shell".

 

[JohnC1]

HI arno..thanks for the quick response....

Files: C:\FWTools2.4.7\bin\e_07052140_12_15100_4bd_2014.JP2
Size is 3000, 2000
Coordinate System is:
PROJCS["NAD_1983_2011_StatePlane_New_York_East_FIPS_3101_Ft_US",
GEOGCS["GCS_NAD_1983_2011",
DATUM["NAD_1983_2011",
SPHEROID["GRS_1980",6378137,298.257222101]],
PRIMEM["Greenwich",0],
UNIT["degree",0.0174532925199433]],
PROJECTION["Transverse_Mercator"],
PARAMETER["latitude_of_origin",38.83333333333334],
PARAMETER["central_meridian",-74.5],
PARAMETER["scale_factor",0.9999],
PARAMETER["false_easting",1614580.104166667],
PARAMETER["false_northing",0],
UNIT["US survey foot",0.3048006096012192,
AUTHORITY["EPSG","9003"]]]
Origin = (705000.000000000000000,2142000.000000000000000)
Pixel Size = (1.000000000000000,-1.000000000000000)
Corner Coordinates:
Upper Left ( 705000.000, 2142000.000) ( 77d59'44.93"W, 44d39'30.82"N)
Lower Left ( 705000.000, 2140000.000) ( 77d59'43.75"W, 44d39'11.11"N)
Upper Right ( 708000.000, 2142000.000) ( 77d59'3.50"W, 44d39'32.09"N)
Lower Right ( 708000.000, 2140000.000) ( 77d59'2.32"W, 44d39'12.37"N)
Center ( 706500.000, 2141000.000) ( 77d59'23.63"W, 44d39'21.60"N)
Band 1 Block=3000x1 Type=Byte, ColorInterp=Undefined
Overviews: arbitrary
Band 2 Block=3000x1 Type=Byte, ColorInterp=Undefined
Overviews: arbitrary
Band 3 Block=3000x1 Type=Byte, ColorInterp=Undefined
Overviews: arbitrary
Band 4 Block=3000x1 Type=Byte, ColorInterp=Undefined
Overviews: arbitrary

I highlighted the false easting because carrying out false easting to 9 digits really looks like a blunder to me.

 

[arno]

That false easting seems to be wrong indeed, if I look at the proj4 definitions that gdal uses the value should be 150000 instead. So maybe it would help if you just assign the correct projection again before doing the gdalwarp.

 

[JohnC1]

I am trying to come up with a way to edit a tiff image text data which I assume is in the alpha quarter of the file. Easier to call the powers that be in NY that they have made a "fat finger" error.

 

[arno]

Maybe you can use gdal_translate to assign the correct coordinate system definitions?

 

[JohnC1]

I have 372 actual images so at first this didn't seem practical...but I can try this with a horizontal strip of images and some estimates to start.

I haven't the patience or time to do this fo all of them. Perhaps a vertical stack will all share a well estimated longitude

 

[arno]

If it works with gdal_translate you can have a batch file update all 372 files in one go. Should be easy.

 

[arno]

Hi,

You could try this command:

gdal_translate -a_srs "+proj=tmerc +lat_0=38.83333333333334 +lon_0=-74.5 +k=0.9999 +x_0=150000 +y_0=0 +datum=NAD83 +units=us-ft +no_defs  <>" orig.tif new.tif

That should assign the proper coordinate system for the New York East coordinate system. Hopefully that fixes the error in the meta data.

 

[JohnC1]

Hello Arno..thank you for the help....I turn 79 next week so becoming more facile with GDAL probably is not the best path for me. I am starting to neglect my other totally unrelated projects. I will try to find a different year's data and see what happens there. I must say though that I have run gdalwarp in OSGeo4W and gotten only grayscale images so far. The same code in FSWTools2.4.7 keeps the RGB data. Perhaps FSX2020 is a better solution for me.

 

[arno]

Hi,

I can imagine all those command line processing are hard to learn at such an age indeed.

You can run this command in the old FWTools as well, if that solves the issue of loosing the color data.

If you would have a download link where I can get a sample image with the wrong meta data, I could have a quick look for you as well.

 

[JohnC1]

Finding the source was easy... I looked at the image filename in my post above, pasted just the jp2 filename in google and got the source back instantly...amazing.

http://gis.ny.gov/gateway/mg/2014/clinton/14ic_t_plattsburgh_e12_4bd.htm. The first file on the top.

Post edit:
Same result...FSWTools2.4.7 gets the colors right and the longitude coordinates wrong...OSGeo4W does the reverse...good longitudes but grayscale.
I note that gdalwarp.exe is much smaller in OSGeo4W.

FSW2.4.7 86K OsGeo4W 29K. I'm not a conspiracy theorist but......................