[OpenLayers-Users] getCentroid method influenced by floating-point math

[srweal]

Hi all,

I've just discovered an instance in OL where floating-point maths is causing
it to produce wrong results. Or at least I think that is the problem. Am
keen for the perspective of other users.

I have got a small polygon (about 4m x 16m land parcel) that I want OL to
show on the map and put a popup on. This polygon is defined in WGS84 as
follows:

146.499146	-35.964346
146.499147	-35.964234
146.499179	-35.964234
146.499179	-35.964346
146.499146	-35.964346

When it gets added to my map, it gets converted into spherical mercator
metres for display on Google Maps imagery:

16308210.33436940	-4295716.54499556
16308210.44568890	-4295701.14094059
16308214.00791260	-4295701.14094059
16308214.00791260	-4295716.54499556
16308210.33436940	-4295716.54499556

I then calculate a centroid for the polygon, which uses the getCentroid
method in LinearRing.js. This ends up putting the centroid at:

16306764.80622490	-4295327.62865597 (which is clearly outside the polygon)

If I apply the formula used in the getCentroid method using Excel (which is
explained here at
http://en.wikipedia.org/wiki/Centroid#Centroid_of_polygon), I get the
centroid computed as:

16308173.84173270	-4295698.77909395 (which is closer, but still not in the
polygon even though it should be).

Now clearly neither of these are in the right place. It is a result of the
centroid formula producing huge numbers when using spherical mercator
coordinates (which themselves are huge). 

I'm wondering if there is a better approach to computing the centroid that
can avoid these issues? 

Any ideas or implementations?

Thanks, Steve







--
View this message in context: http://osgeo-org.1803224.n2.nabble.com/getCentroid-method-influenced-by-floating-point-math-tp6346365p6346365.html
Sent from the OpenLayers Users mailing list archive at Nabble.com.