fix-googlemap-china-offset: fix style issues

[johnd0e]

lint:

• let is not in es5
• 'HK_LENGTH' is assigned a value but never used
• 'original' is defined but never used

style:

• == vs ===
• Mixed spaces and tabs
• fix indents, missed/extra/trailing spaces, missed semi

[johnd0e]

And there is still error in L.GridLayer.prototype._setZoomTransform

L.GridLayer.prototype._setZoomTransform = (function (original) {
  return function (level, center, zoom) {
    center = window.plugin.fixChinaOffset.getLatLng(center, this.options.type);
    original.apply(this, arguments);
  };
})(L.GridLayer.prototype._setZoomTransform);

• zoom is defined but never used
• center is assigned a value but never used

So center is not propagated back to arguments.

[johnd0e]

'original' is defined but never used

I suppose this also should be fixed adding something like original.apply(this, arguments);

[modos189]

Please update PR to new commit

[modos189]

So center is not propagated back to arguments.

No, it is propagated back. This is a bug in es linter, or browser?
Maybe original.apply(this, [level, center, zoom]);

[johnd0e]

No, it is propagated back. This is a bug in es linter, or browser?

You are right. I suppose bug in eslint.
Anyway, your second variant looks cleaner:

Maybe original.apply(this, [level, center, zoom]);

And please comment about this:

'original' is defined but never used

Was it really unused argument?
Or there is missing original.apply(this, arguments);

[modos189]

Was it really unused argument?

Here, indeed, unused variable. I tried calling original method as in other cases, but then errors occur when calling class Bounds

[johnd0e]

Merged (need to test again).

And I am going to review the code one more time.
E.g. I doubt that we need PRCoords as object. Wouldn't it better just have two distinct functions?

[modos189]

Method isInGoogle can be completely removed. It is not used

[johnd0e]

It is not used

As I can see it is used as fast precheck if latlng is in bounds of square, which covering China.
Should be renamed.

[modos189]

But why? The plugin still needs to be installed separately for those from China.

[johnd0e]

Perhaps for those who are not China, but still want to see real map offset while browsing China.

Could you make some tests comparing performance between these two functions?
(May be we do not need optimization here)

[johnd0e]

BTW, here is another implementation of same pnpoly-algorithm: https://github.com/substack/point-in-polygon / https://github.com/iominh/point-in-polygon-extended

And here is improved version: https://github.com/mikolalysenko/robust-point-in-polygon

And here is different algorithm: https://stackoverflow.com/a/36070256/2520247.
See other answers too, as there are useful references to GeoJSON-libraries. Some of them:

• https://github.com/maxogden/geojson-js-utils#point-in-polygon
• http://turfjs.org/docs/#booleanPointInPolygon
• https://github.com/mapbox/leaflet-pip

And even more: https://libraries.io/search?keywords=points%2Cpolygon&languages=JavaScript&q=Point+polygon&sort=latest_release_published_at

[modos189]

I'm confused. Method isInGoogle is used. It as roughly and thoroughly checked the coordinates.
This method calling from gcjObfs.

Another thing is that there is no need to make it public.

[johnd0e]

Another thing is that there is no need to make it public.

Well, it could be useful for someone, who wants to reuse this function.

[modos189]

Um. Well, maybe as two distinct functions

[johnd0e]

I failed to identify the source of obfuscation algorithm in our code.
As it differs from old (which was referenced as https://on4wp7.codeplex.com/SourceControl/changeset/view/21483#353936).
And it also differs from included with new link: https://github.com/Artoria2e5/PRCoords

So it's sort a mess...

I'm prefer that policy about external sources (and images) should be included unmodified (and inlined only in build-process).

[johnd0e]

Well, maybe as two distinct functions

Agree, as there are 2 distinct action, and there are several methods to do every of them.
So better to divide them in order to make support simpler (e.g. tomorrow we'll prefer to replace one function)

[johnd0e]

Parent issue: #64