AGSGeometryEngine bufferGeometry produces "incorrect" result

[FredSpataro]

Hi All,

I'm calling the AGSGeometryEngine bufferGeometry for a point with small buffer distances of 10-100 meters.  The output polygon is short by about 25%... I'm overlaying these polygons on an imagery base map centered on a football or other sports field and the discrepancy is glaringly obvious. 

The map is Web Mercator and I think this is one of those issues we deal with all the time in ArcGIS programming.  The buffer operation is happening in a projection that's not optimal for the calculation.  I can reproduce the same issue using the Javascript API and the Geometry Service's buffer operation.  That service allows me to specify a "bufferSpatailReference".  When I use a local UTM zone for this parameter, I get polygons that seem much closer to correct if not perfect.

Unfortunately, this app will often be offline a lot of the time so I need to use the local geometry engine not the remote geometry service.  Is there a way to handle this operation in using local engine.  I hope I don't have to write my own buffer functions.... point wouldn't be too bad I guess...

Thanks

[DiveshGoyal]

What you can do is -
First, project your point into the "buffer spatial reference".
Next, buffer this point
Finally, re-project the result back to the original spatial reference.
You can do this all locally using the geometry engine.

[FredSpataro]

Divesh,

Thanks that works... makes sense since it's a local engine we can do the same process.  The parameter in the Javascript API simply reduces the need for back and forth to the server. 

One thing we did notice was the projectGeometry method fails form Web Mercator to WKID 32612 WGS_84_UTM_12N but was fine for WKID 103200 NAD_1983_HARN_StatePlane_Montana_FIPS_2500. 

Thanks

[DiveshGoyal]

This page contains links to the coordinate systems supported on mobile devices.

I can see that WGS 84 UTM 12 N is supported (search for 32612). So that should work. Can you provide a code snippet that fails so that we can investigate?

I also see that NAD_1983_HARN_StatePlane_Montana_FIPS_2500 is supported, but it has a WKID of 2818 (not 103200 as you reported)