Proj4 js nadgrid transform does not take into account the nadgrid param

[th30d0r]

When using the js binding for proj4 with nadgrid param, the output coordinate transform is the same as without the nadgrid param in the proj4 string

0. the proj4 string customProj4 = +proj=tmerc +lat_0=52.3 +lon_0=-1.5 +k=1 +x_0=198873.0046 +y_0=375064.3871 +ellps=WGS84 +units=m +no_defs +nadgrids=key
1. Reading the gsb file into a buffer array switchMap(gsbFileResp => { const buffer = gsbFileResp.arrayBuffer(); return from(buffer); }) ) .subscribe(buffer => { (proj4 as any).nadgrid('key', buffer); // no errors }

transform code proj4For3857 = '+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=@null +wktext +no_defs',

proj4 ( proj4For3857, customProj4, coordinate)

The output transformed coordinate has a shift, and it is the same out as if I remove the nadgrid param from the custom proj4 string. So i assume that even though proj4 register the gsb file, when doing the proj transformation it does not take it into consideration

Using Angular 10 proj4 2.7.4

[ahocevar]

You need to prefix the grid key with a @. In your def, it should be +nadgrids=@key,null. Also make sure you don't perform the transform before the key is registered - you're setting it asynchronously.

[th30d0r]

Even with the @ it does not work. The transform is done after the key is registered. I think i tracked it down to this area of the code in the datum_transform.js - which is where i assume the gridshift is happening.

export default function(source, dest, point) {
  // Short cut if the datums are identical.
  if (compareDatums(source, dest)) {
    return point; // in this case, zero is sucess,
    // whereas cs_compare_datums returns 1 to indicate TRUE
    // confusing, should fix this
  }

  // Explicitly skip datum transform by setting 'datum=none' as parameter for either source or dest
  if (source.datum_type === PJD_NODATUM || dest.datum_type === PJD_NODATUM) {
    return point;
  }

  // If this datum requires grid shifts, then apply it to geodetic coordinates.
  var source_a = source.a;
  var source_es = source.es;
  if (source.datum_type === PJD_GRIDSHIFT) {
    var gridShiftCode = applyGridShift(source, false, point);
    if (gridShiftCode !== 0) {
      return undefined;
    }
    source_a = SRS_WGS84_SEMIMAJOR;
    source_es = SRS_WGS84_ESQUARED;
  }

  var dest_a = dest.a;
  var dest_b = dest.b;
  var dest_es = dest.es;
  if (dest.datum_type === PJD_GRIDSHIFT) {
    dest_a = SRS_WGS84_SEMIMAJOR;
    dest_b = SRS_WGS84_SEMIMINOR;
    dest_es = SRS_WGS84_ESQUARED;
  }
  

The applyGridShift(source, false, point) function is not called because it exits the function here // Explicitly skip datum transform by setting 'datum=none' as parameter for either source or dest if (source.datum_type === PJD_NODATUM || dest.datum_type === PJD_NODATUM) { return point; }

[th30d0r]

Yep I just tested this. If i provide the from proj4 string of 27700 the transform works perfectly. However It cannot convert points from 3857

[ahocevar]

What happens if you change that snippet you cited above to

  // Explicitly skip datum transform by setting 'datum=none' as parameter for either source or dest
  if (source.datum_type === PJD_NODATUM && dest.datum_type !== PJD_GRIDSHIFT || dest.datum_type === PJD_NODATUM && source.datum_type !== PJD_GRIDSHIFT) {
    return point;
  }

?

[utraum]

What happens if you change that snippet you cited above to

  // Explicitly skip datum transform by setting 'datum=none' as parameter for either source or dest
  if (source.datum_type === PJD_NODATUM && dest.datum_type !== PJD_GRIDSHIFT || dest.datum_type === PJD_NODATUM && source.datum_type !== PJD_GRIDSHIFT) {
    return point;
  }

?

this works for us ! We had big differences due to missing gridshift. Thanks

[th30d0r]

so to go around this problem we crated a jump. Gridshift crs -> bng-> 3857 and vice versa. The accuracy we get when comparing to ground control points is around 0.001.

[chvarma80]

so to go around this problem we crated a jump. Gridshift crs -> bng-> 3857 and vice versa. The accuracy we get when comparing to ground control points is around 0.001.

Hi, How exactly you created the jump? I am having issue with this, vector layers are transforming properly but OSM is not transforming.

[ahocevar]

A possible workaround would be to define EPSG:3857 differently:

proj4.defs('EPSG:3857', '+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +datum=WGS84 +wktext +no_defs');

[chvarma80]

Hi Mr.Hocevar

Are you saying i should define this projection 3857 and assign it to OSM?

I am trying to transform my all other data here to nadgrids (HS2TN15_NTv2), you think the approach suggested by you will solve my problem?

Thanks

On Tue, 8 Feb 2022, 7:29 pm Andreas Hocevar, @.***> wrote:

A possible workaround would be to define EPSG:3857 differently:

proj4.defs('EPSG:3857', '+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +datum=WGS84 +wktext +no_defs');

— Reply to this email directly, view it on GitHub https://github.com/proj4js/proj4js/issues/389#issuecomment-1032341242, or unsubscribe https://github.com/notifications/unsubscribe-auth/AXLBSCQDGOJ24TUZN2XXSADU2DH7FANCNFSM465QPWVQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you commented.Message ID: @.***>

[ahocevar]

@chvarma80 Give it a try. Are you working with OpenLayers?

[chvarma80]

Hi

Yes, I am working on openlayers, I have tried and that does not work, projection or no projection OSM is not matching the transformation, below is my projection for the data transform.

proj4.defs(myProjectionName,'+proj=tmerc +lat_0=52.3 +lon_0=-1.5 +k=1 +x_0=198873.0046 +y_0=375064.3871 +ellps=WGS84 +units=m +no_defs @.***,null'); // assigned key

As a result, I am getting all vector data from Geojson and points placed in the openlayers ( Lat,lon) are transforming perfectly, however the OSM is way off, refer below picture for shifting, please note that OSM vector data layers are transforming perfectly.

Once again, thank you very much, I am facing too much difficulty on this.

[image: image.png]

On Tue, Feb 8, 2022 at 7:50 PM Andreas Hocevar @.***> wrote:

@chvarma80 https://github.com/chvarma80 Give it a try. Are you working with OpenLayers?

— Reply to this email directly, view it on GitHub https://github.com/proj4js/proj4js/issues/389#issuecomment-1032358861, or unsubscribe https://github.com/notifications/unsubscribe-auth/AXLBSCVWEV32THCDZYSKKQTU2DKNZANCNFSM465QPWVQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you were mentioned.Message ID: @.***>

[th30d0r]

Not sure what are the implication of removing that if statement, but I would think it should be consider. Tried the suggested implementation if (source.datum_type === PJD_NODATUM && dest.datum_type !== PJD_GRIDSHIFT || dest.datum_type === PJD_NODATUM && source.datum_type !== PJD_GRIDSHIFT) { return point; }, however that resulted in a very big error (~20 km shift ), so I am not sure that is correct.

The way to go around this bug is to just take what you want to convert and first convert it to bng, then to the what you need

[ahocevar]

@th30d0r Does the workaround work for you? Removing that if-block wouldn't be a good idea, because it would mean that we always try to apply a datum transform even if we don't know the source or destination datum.

[ahocevar]

@chvarma80 Please don't reply by e-mail, because that does not support images and also your projection string is obfuscated (+nadgrids=@something?).

[chvarma80]

Hi

I have tried the suggested implementation, that doesn't do anything. I am not sure what you are referring to when you say convert to bng i have issue with OSM here, don't understand your suggestion.

On Tue, 8 Feb 2022, 9:29 pm th30d0r, @.***> wrote:

Not sure what are the implication of removing that if statement, but I would think it should be consider. Tried the suggested implementation if (source.datum_type === PJD_NODATUM && dest.datum_type !== PJD_GRIDSHIFT || dest.datum_type === PJD_NODATUM && source.datum_type !== PJD_GRIDSHIFT) { return point; }, however that resulted in a very big error (~20 km shift ), so I am not sure that is correct.

The way to go around this bug is to just take what you want to convert and first convert it to bng, then to the what you need

— Reply to this email directly, view it on GitHub https://github.com/proj4js/proj4js/issues/389#issuecomment-1032452395, or unsubscribe https://github.com/notifications/unsubscribe-auth/AXLBSCWM2KGRNA6RO3TFWCLU2DV75ANCNFSM465QPWVQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you were mentioned.Message ID: @.***>

[chvarma80]

Okay, my projection string has a key associated with arraybuffer as per the documentation, that part working fine.

Only issue with OSM falling somewhere else.

On Tue, 8 Feb 2022, 9:51 pm Andreas Hocevar, @.***> wrote:

@chvarma80 https://github.com/chvarma80 Please don't reply by e-mail, because that does not support images and also your projection string is obfuscated @.***?).

— Reply to this email directly, view it on GitHub https://github.com/proj4js/proj4js/issues/389#issuecomment-1032472477, or unsubscribe https://github.com/notifications/unsubscribe-auth/AXLBSCXYUJZS2XVVZIFR62LU2DYTDANCNFSM465QPWVQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you were mentioned.Message ID: @.***>

[th30d0r]

@ahocevar the work around works in my case. The part that is curious is that the python version works as expected. Haven't checked if they have that if statement in or not.

[th30d0r]

@chvarma80 you go from hs2->bng-> 3857

[chvarma80]

I am still not sure, my map projection is HS2, I am parsing all data to this projection and it is working fine except OSM, when you say hs2 to bng to 3857, are you referring for OSM reprojection? When I declare OSM tiles it is same with projection or without projection, projection is not affecting OSM, BTW the shifting of OSM is around 200meters.

On Tue, 8 Feb 2022, 10:03 pm th30d0r, @.***> wrote:

@chvarma80 https://github.com/chvarma80 you go from hs2->bng-> 3857

— Reply to this email directly, view it on GitHub https://github.com/proj4js/proj4js/issues/389#issuecomment-1032482338, or unsubscribe https://github.com/notifications/unsubscribe-auth/AXLBSCWS3NWWVGHVL7HHCMTU2DZ6NANCNFSM465QPWVQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you were mentioned.Message ID: @.***>

[ahocevar]

@chvarma80 Is EPSG:3857 your destination projection? If so, there is no need to reproject an OSM tile layer, because that is in EPSG:3857 already. So I suspect you're indeed facing the same issue as @th30d0r, and I would suggest specifying EPSG:3857 in OpenLayers, like I explained in https://github.com/proj4js/proj4js/issues/389#issuecomment-1032341242.

@th30d0r I think the difference between proj4.js and its siblings in other languages is that not only +datum=none means NO DATUM, but also the case where no datum is implicitly or explicitly specified. That may mean WGS84 in other flavors, but I haven't had time yet to check the respective documentations throughly enough.

[chvarma80]

My destination projection is not 3857, it is HS2 with a grid shift, and I have specified 3857 as you said, there is absolutely no change.

On Tue, 8 Feb 2022, 10:58 pm Andreas Hocevar, @.***> wrote:

@chvarma80 https://github.com/chvarma80 Is EPSG:3857 your destination projection? If so, there is no need to reproject an OSM tile layer, because that is in EPSG:3857 already. So I suspect you're indeed facing the same issue as @th30d0r https://github.com/th30d0r, and I would suggest specifying EPSG:3857 in OpenLayers, like I explained in #389 (comment) https://github.com/proj4js/proj4js/issues/389#issuecomment-1032341242.

@th30d0r https://github.com/th30d0r I think the difference between proj4.js and its siblings in other languages is that not only +datum=none means NO DATUM, but also the case where no datum is implicitly or explicitly specified. That may mean WGS84 in other flavors, but I haven't had time yet to check the respective documentations throughly enough.

— Reply to this email directly, view it on GitHub https://github.com/proj4js/proj4js/issues/389#issuecomment-1032529433, or unsubscribe https://github.com/notifications/unsubscribe-auth/AXLBSCTMNLVHQF5YX6INU73U2EAOHANCNFSM465QPWVQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you were mentioned.Message ID: @.***>

[th30d0r]

@ahocevar, tried with the proj4 that you are suggesting, and still the same. If i remember correctly there is somewhere in the codebase where you are searching specifically for WGS84 and 4326 and you set for those 2 the datum type as none