caver456
commented
2 weeks ago Actually this is probably NOT new. In this commit, 10-17-18 this line of code was changed in addMarker:
old:
j['position']={"lat":lat,"lng":lon}
new:
jg['coordinates']=[lon,lat]
So, [lon,lat] has probably been around for a LONG time. I probably knew this some years back but can't find record of it.
Anyway, this means that it shouldn't be such a shock to downstream coders.
So - how to handle reversed coordinates in arguments to the addXX methods that accept lists of points? Go with the suggestion from the previous comment: automatically-fix-with-warning-during-validation if the coords are 'obviously' swapped.
For lists of points, first check all points in the list to categorize each point as 'obviously valid', or 'obviously swapped', or 'not obvious'.
If there are obviously-valid points, then, as long as there are no obviously-swapped points, leave the list alone.
If there are obviously-swapped points, then, as long as there are no obviously-valid points, swap every point in the list.
If there are no obviously-swapped or obviously-valid points, leave the list alone.
If there are both obviously-valid and obviously-swapped points, abort with an error.
Or something like that. Put this all into one validation function that actually returns a validated list of points.
In the past, [39,-120] i.e. [lat,lon] was the sequence to send.
At some point it looks like caltopo.com was switched over to require [lon,lat] instead.
Just noticed now that the necessary coord sequence seems to be reversed, and the server doesn't attempt to correct them, and doesn't send back an error when requested to draw something with lat/lon coordinates outside of physical bounds (+/- 180 lon; +/- 90 lat).
Based on actually drawing a shape and watching the network traffic, the required sequence is now [,] e.g. [-120,39]
The system does try to add shapes at [39,-120] where -120 is way south of the south pole, so that a map reload shows several mercator projections of the globe on one screen.
Do full QA from the top to test all feature types and modify as necessary. Probably best to make the class methods deal with swapped-sequence as determined by numbers out of physical bounds, to maintain compatibility with downstream code that worked with prior versions. But maybe it's better to force users to adapt to the new sequence...?