Determine whether ENVI header 'map info' can be mapped to LatLon

[lewismc]

The idea here is to see if we can derive some coordinate references from the map info key

The map info key lists geographic information in the following order:

• Projection name
• Reference (tie point) pixel x location (in file coordinates)
• Reference (tie point) pixel y location (in file coordinates)
• Pixel easting
• Pixel northing
• x pixel size
• y pixel size
• Projection zone (UTM only)
• North or South (UTM only)
• Datum
• Units See Enter Map Information for Georeferenced Files for further details.

Original reference at http://www.harrisgeospatial.com/docs/enviheaderfiles.html

Someone needs to investigate whether there is a mapping from the above elements to some coordinates.... preferably LatLon pair or Well Known Text (WKT)

[kristencheung]

From what we've found, lat/lon seems to be referred to as Geographic Coordinate Systems (GCS). https://support.esri.com/en/technical-article/000007880

Additionally, from the map info information, it seems that there exists libraries in Python that can be leveraged to convert specific datum (from map info) to be converted to GCS lat/lng: https://gis.stackexchange.com/questions/78838/converting-projected-coordinates-to-lat-lon-using-python

We think perhaps given some additional samples of metadata (specifically map info data), we should be able to tinker around with the python libraries to try and extract lat/lng data.

[lewismc]

Hi @kristencheung OK I found the following information https://www.harrisgeospatial.com/Support/Forums/aft/4515 An example of the 'map info' field for one of our .hdr files is as follows

map info = { UTM , 1.000 , 1.000 , 724522.127 , 4074620.759 , 1.1000000000e+00 , 1.1000000000e+00 , 12 , North , WGS-84 , units=Meters , rotation=75.00000000 }

Meaning that in the UTM projection, the location of the upper left hand point on the upper left hand pixel for the scene is at the 724522.127 (east) 4074620.759 (north) position.

[lewismc]

Some information on the complexities involved with converting between coordinate systems

Both Coordinate system (WGS 84 for example) and a Projection (Universal Transverse Mercator for example) are coordinate systems. The difference is that WGS 1984 is a geographic coordinate system, and UTM is a projected coordinate system. Geographic coordinate systems are based on a spheroid and utilize angular units (degrees). Projected coordinate systems are based on a plane (the spheroid projected onto a 2D surface) and utilize linear units (feet, meters, etc.).

It would appear that the AVIRIS-* imagery utilizes the UTM coordinate system, so in order to map this into a more recognized format (which we can plot on a map) we need to convert the UTM references to their WGS84 'equivalent'.

[lewismc]

OK folks, I think I've cracked it. Please check out https://awsm-tools.com/geo/utm-to-geographic If you consider the above example, you see that there are three elements of the value we need to be concerned with, namely 724522.127 which is the Pixel Easting (x coordinate), 4074620.759 which is the Pixel Northing (y coordinate) and the projection zone 12 (which will be present for UTM coordinate references only), which I actually map to 12X in https://awsm-tools.com/geo/utm-to-geographic When we enter this information into https://awsm-tools.com/geo/utm-to-geographic, you can see that it generates the following LatLon pair/Geographic coordinates 36.790806N 108.483710W. When you enter that in something like Google Maps, you end up with the location of the site at which the AVIRIS image was acquired... which is great! See the screenshot below for evidence.

Now all we need to do is code this conversion up within the Apache Tika extraction logic and we will be good to undertake geographic search within the COAL-SDS File Manager :)

[lewismc]

The algorithm to achieve the UTM to LatLon coordinate reference is available at https://en.wikipedia.org/wiki/Universal_Transverse_Mercator_coordinate_system#From_UTM_coordinates_(E,_N,_Zone,_Hemi)_to_latitude,_longitude_(%CF%86,_%CE%BB)

[DenimMazuki]

@lewismc Thank you for that, that sounds great. We will work on implementing the algorithm for conversion. Just to clarify, should we pull Apache Tika into our local device and implement the conversion logic there?

[DenimMazuki]

@lewismc We've made an attempt to code the conversion logic in EnviHeaderParser.java in Apache Tika. When I tried to push to a branch of Apache Tika (we created a new branch), it said that we do not have the authority to do so. Should we create a fork of the repository and work on that?

Please advise. Thanks!

[lewismc]

Yes that’s always how development is done. You should never have commit rights to a repository that you are not closely affiliated with or do not understand... otherwise you make mistakes.

What you do is 1) open an issue in the project issue tracker describing to as much detail, everything you wish to do, 2) close the project you wish to work on, 3) in your local close create a local branch named after the issue you created e.g. TIKA-XXXX, 4) work on that branch and when you are finished push to your own remote clone repository, 5) create a pull request from your own repository explicitly making a mapping between your work branch and the branch you wish to merge into, 6) correspond with the community you are trying to work with on the resulting pull request thread.

Thanks, Lewis

On Wed, Oct 31, 2018 at 19:05 Denim Mazuki notifications@github.com wrote:

@lewismc https://github.com/lewismc We've made an attempt to code the conversion logic in EnviHeaderParser.java in Apache Tika. When I tried to push to a branch of Apache Tika (we created a new branch), it said that we do not have the authority to do so. Should we create a fork of the repository and work on that?

Please advise. Thanks!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/capstone-coal/coal-sds/issues/27#issuecomment-434906685, or mute the thread https://github.com/notifications/unsubscribe-auth/ABHJlyn0XF-Ckoip-Q3vYazJEUTWciklks5uqlbqgaJpZM4X4Wz2 .

--

Lewis Dr. Lewis J. McGibbney Ph.D, B.Sc Skype: lewis.john.mcgibbney

[lewismc]

This issue is being developed at https://github.com/apache/tika/pull/257