LS Background shift

[Kelly Bellis]

Please try using the georeferenced image with its world file used in Justin Link without shifting it. And then if it's possible, create a background map from it for LS of just those portions around the cemetery and then post here in this thread for downloading.

Did you try to reference in Global Mapper by using WGS84@2005.0 coordinates.

Regardless of Global Mapper workspace's projection in any given project, Global Mapper automatically (transparent to the user) reprojects to the the Web Mercator projection system when exporting to MBTiles and RMaps formats. This is where I get confused because the [WGS 84 / Psuedo-Mercator], also known as [Web Mercator], also known as [WGS 84 / Popular Visualisation Web Mercator], also known by the EPSG Code 3857 with corresponding parameters as follows:

PROJCS["WGS 84 / Pseudo-Mercator",
GEOGCS["WGS 84",
DATUM["WGS_1984",
SPHEROID["WGS 84", 6378137, 298.257223563, AUTHORITY["EPSG","7030"]],
AUTHORITY["EPSG","6326"]],
PRIMEM["Greenwich", 0, AUTHORITY["EPSG","8901"]],
UNIT["degree", 0.01745329251994328, AUTHORITY["EPSG","9122"]],
AUTHORITY["EPSG","4326"]],
PROJECTION["Mercator_1SP"],
PARAMETER["central_meridian",0],
PARAMETER["scale_factor",1],
PARAMETER["false_easting",0],
PARAMETER["false_northing",0],
UNIT["metre", 1, AUTHORITY["EPSG","9001"]],
AXIS["X",EAST],
AXIS["Y",NORTH],
AUTHORITY["EPSG","3857"]]

... and this is where flattening is defined [EPSG Code 3857] for the current so-called Web Mercator system but then our data are reportedly being projected as if there's no flattening; i.e., on a sphere [EPSG Code 3758]. This is what I understand gets spit out into, for example, the HillsideCemetery.sqlitedb (attached).

Before we go further down this rabbit hole, please clarify which WGS84 Datum Epoch 2005.0 you speak about as there are (2): a.) WGS84(G1674) and b.) WGS84(G1762), both based on ITRF2008.

 

[Vladimir Prasolov]

Hi Kelly,
I would suggest to entrap that rabbit in two steps:
1. Use WGS84(ITRF2008) @ 2005.0 coordinates for referencing in Global Mapper. It does not matter what ITRF2008 realization to use. IGS and IERS realizations are very close, the difference is in submillimeter level. See example below.
2. After that we see difference due to projection and fix it, or create option for user selection.
I hope it would be enough.

WGS84(G1674) vs. WGS84(G1762)

HTDP Output
****************************************
HTDP (VERSION v3.2.5 ) OUTPUT
TRANSFORMING POSITIONS FROM NAD_83(2011/CORS96/2007) (EPOCH = 07-02-2017 (2017.5000))
TO WGS_84(G1674) (EPOCH = 01-01-2005 (2005.0000))
San Jose
LATITUDE 37 20 0.00000 N 37 20 0.00465 N 24.59 mm/yr north
LONGITUDE 121 54 0.00000 W 121 54 0.04201 W -18.68 mm/yr east
ELLIP. HT. 0.000 -0.533 m -1.34 mm/yr up
X -2683221.741 -2683222.349 m -7.42 mm/yr
Y -4310775.999 -4310775.018 m 23.44 mm/yr
Z 3846872.626 3846872.417 m 18.73 mm/yr

HTDP Output
****************************************
HTDP (VERSION v3.2.5 ) OUTPUT
TRANSFORMING POSITIONS FROM NAD_83(2011/CORS96/2007) (EPOCH = 07-02-2017 (2017.5000))
TO WGS_84(G1762) (EPOCH = 01-01-2005 (2005.0000))
San Jose
LATITUDE 37 20 0.00000 N 37 20 0.00465 N 24.59 mm/yr north
LONGITUDE 121 54 0.00000 W 121 54 0.04201 W -18.68 mm/yr east
ELLIP. HT. 0.000 -0.533 m -1.34 mm/yr up
X -2683221.741 -2683222.349 m -7.42 mm/yr
Y -4310775.999 -4310775.018 m 23.44 mm/yr
Z 3846872.626 3846872.417 m 18.73 mm/yr

 

[Kelly Bellis]

Hello Vladimir,

The [Web Mercator] coordinate system, also known by the EPSG Code 3857, uses the original WGS 1984 datum, also known by the ESPG Code 4326. Is it possible for JField to make the necessary corrections ?

If not, would you happen to know if there is a standard means of embedding epoch data inside of RMaps that could be used instead of WGS 1984 datum ESPG Code 4326?

 

[Vladimir Prasolov]

Hello Vladimir,

The [Web Mercator] coordinate system, also known by the EPSG Code 3857, uses the original WGS 1984 datum, also known by the ESPG Code 4326. Is it possible for JField to make the necessary corrections ?

If not, would you happen to know if there is a standard means of embedding epoch data inside of RMaps that could be used instead of WGS 1984 datum ESPG Code 4326?

It is definitely possible. For example Google and Yandex maps are using different approaches, spherical and ellipsoidal correspondingly. I will investigate about RMaps and epochs. In any case we could provide option for users to select projection type and epoch manually. Could you help us to resolve epoch issue by processing map by Global Mapper with WGS84@2005.0 to see difference please.

 

[Vladimir Prasolov]

Unfortunately RMaps SQLite database format has no place for coordinate system and epoch info. The following is the schema:

We have complimentary xml-file on Triumph-LS with some additional information. For example:
<MapInfoxmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:schemaLocation="MapInfoSchema.xsd">
<ImageTileSize>256</ImageTileSize>
<Version>1.10</Version>
<MipLevelMin>0</MipLevelMin>
<MipLevelMax>19</MipLevelMax>
<Layerid="0">
<MipLevelMin>0</MipLevelMin>
<MipLevelMax>19</MipLevelMax>
<XIndexMin>0</XIndexMin>
<XIndexMax>0</XIndexMax>
<YIndexMin>0</YIndexMin>
<YIndexMax>0</YIndexMax>
</Layer>
</MapInfo>
So we can add epoch, type of projection or even entire system definition into that file. User will be able to select values and program will keep them into that xml.

 

[Kelly Bellis]

Could you help us to resolve epoch issue by processing map by Global Mapper with WGS84@2005.0 to see difference please.

Yes, I'm happy to help; however, am unclear on what is meant by "processing map".

Uncertain if this is what you wanted, I proceeded to define the Global Mapper workspace using WGS84 (G1762) EPSG 7665. I next exported from Global Mapper HillsideCemeteryEPSG7665.sqlitedb, loaded it into the LS and set it as the background map noting that my JField project is NAD83(2011) Maine2000 East Epoch 2010.0000.

The result was that nothing looked different; i.e., the map doesn't align properly with the survey points on the LS.

 

[Kelly Bellis]

We have complimentary xml-file on Triumph-LS with some additional information. So we can add epoch, type of projection or even entire system definition into that file. User will be able to select values and program will keep them into that xml.

That sounds great Vladimir. Perhaps there is room on the Project Settings page beneath Background map for the user to augment JField's XML.

I still am curious why that would be necessary if the de facto definition for RMaps is predicated on the original WGS 1984 datum ESPG Code 4326, isn't this enough for JField's transformation to WGS84 (G1762) EPSG 7665 (or whatever JField needed)?

 

[Vladimir Prasolov]

Yes, I'm happy to help; however, am unclear on what is meant by "processing map".

Uncertain if this is what you wanted, I proceeded to define the Global Mapper workspace using WGS84 (G1762) EPSG 7665. I next exported from Global Mapper HillsideCemeteryEPSG7665.sqlitedb, loaded it into the LS and set it as the back background map noting that my JField project is NAD83(2011) Maine2000 East Epoch 2010.0000.

The result was that nothing looked different; i.e., the map doesn't align properly with the survey points on the LS.

View attachment 6027

Could you send us the Global Mapper view for those points on that background please.

 

[Kelly Bellis]

Do you mean a screen capture ?


If you have Global Mapper, the files used are posted on my website for you:

minimal data set for discussion on Javad forum.gmw
2014_55959187_15.tif
2014_55959187_15.tfw
Hillside-170121.txt

 

[Vladimir Prasolov]

The following feature request has been added:
VSAPP-3428 Background Map: Customize projection type and epoch