The 180th Meridian is geographic industry's issue.
Each industry vendor develope their own strategy to work around it. The first remedy to arcgis server powered googlemaps seem solved this issue. The remedy for geojson powered ( independ to arcgis server ) have been developed, however, it seems only works for polygon. Line and point is still problematic.
The 180th Meridian located between Alaska and Russia. On Alaska side, the longitude is negative for example -179 degree. If you move just a little bit cross over the 180th Meridian, step on the Russia side, the longitude suddenly becames positive +179. West -180 degree actually also is East +180 degree. Human have no problem to understand this. GIS software use mathmatic fomula perform calculation must have some kind of remedy to immune this problem.
How ESRI arcgis server address this issue as of today ?
Sadly, NO, all arcgis server powered map on this web site get infected.
What is the symptom?
Symtom 1:
As soon as you see the 180th Meridian, all data disapear.
Arcgis server always incorrectly respond ( empty dataset ) when geometry envelop cross 180th Meridian
Symptom 2:
When I look Alaska data, only one side of 180th Meridian data shows, not both side at the same time.
Either Russia side or Alaska side of data are showing, but not both at the same time.
The remedy for arcgis server:
For arcgis server : arcgis-server-prefered-longitude = - ( 360 - true-longitude)
For example if the true longitude is +179, in order for arcgis server work correctly
You need to use above fomular to convert it to -181 in gemotry envelop object.
GeoJson powered map:
The arcgis server vaccine did NOT work for geojson.
GeoJSON specification (white paper) enforce right hand rule, counter clock wise for polygon.
While ESRI arcgis platform favor the opposite, clock wise polygon outer ring.
GeoJSON specification against the use of out of range longitude ( valid range is between -180 to + 180, for example -181 degree is invalid)
While ESRI arcgis server silently allow you to use out of range degree ( -360 to 360 ) as a vaccine to immune to 180 meridian issue.
GeoJSON specification favor of split the polygon into 2 polygon by 180th Meridian.
However 2 polygon( type: multipolygon) will greatly increase the mathmatic calculation complexity in downstream software.
Sometime create more serious problem than 180 Meridian or cause more severe damage to the downstream software.
Esri's tempary approach might be the best shot of the day.
The remedy for geojson :
Cut the bounding box (arcgis saying envelop ) into 2 bounding box by 180th Meridian.
Failed Geojson Rewind:
As soon as the bounding box cross 180th Meridian, the assumed negative -181 degree suddenly becomes positive +179, the geojson becomes invalid.
Because the sudden positive change make it violate the right hand rule ( counter clock wise for outer polygon ring).
Without the vaccine, all down stream calculation will mess up just like Arcgis server did.
Initiall I seek to cure this issue by re-enforece the right hand rule, rewind the clock wised polygon to counter clock wised polygon.
The outcome is another disaster, the rewinded counter clock wised polygon completely flip over the the other side of the earth.
The target bounding box is a small area cross 180th Meridian, between Russia and Alaska,
the rewinded polygon is a huge polygon cover all the other side of earth like Africa, Asia, Australia except the target area.
This diaster rule out the rewind geojson as a vaccine.
What about the Prime Meridian ( 0 degree cross London UK , from negative -1 to 0 to positive +1) ?
I have tested all the London, UK data, they are not infected.
How socrata open data rest api address this issue?
Sadly NO