Hi @mattstoebe​,

To produce consistent units for measurement, the GeographicNeighborFinder reprojects the input data into a common Azimuthal Equal Distance coordinate system with the origin at the centroid of the input data. This is a useful technique if the data is concentrated in a relatively small area (ie. city or county), but does not work very well with a nationwide dataset.

If you are only interested in the best angles between locations, you can modify the GeographicNeighborFinder to use the Web Mercator projection instead:

• Right click on the GeographicNeighborFinder and choose Embed
• Right click on the GeographicNeighborFinder and choose Edit
• In the GeographicNeighborFinder, replace the CommonLocalReprojector with a Reprojector.
• Set the Destination Coordinate System in the Reprojector to EPSG:3857

The distances produced by Web Mercator will have a large distortion in the USA, but the bearing angles should be good.

Thank you @daveatsafe (Safer)​ 

I am also using the distance calculation output from this transformer. Will this fix cause issues with that value?

Applying the fix will definitely give you the wrong distances, but I don't think you are getting good distances before the fix either.

Using an Albers Equal Area coordinate system like US48, instead of EPSG:3857, will give you better values for the distances, but will affect the bearing angles for coastal locations.

You may want to split the locations into two parallel streams, reprojecting one stream to EPSG:3857, then sending to a NeighborFinder to calculate bearings. Reproject the second stream to US48, send to a another NeighbrFinder to calculate distances, then merge both outputs by point id in a FeatureMerger.

Thank you. I can do that. I am doing 5 nearest points per base point. With the differences in distance calculations between the two streams would these not then mismatch when there are close splits?

Use 5 points in the distance NeighborFinder, but maybe 10 in the angle NeighborFinder. If you use the distance results as the Requestors in the FeatureMerger, and only used the Merged output, the extra angle results will be discarded.

yes. I can do that, but this is around 500K base points and 500K targets repeated 4 times so the time requirement goes up significantly. Is there a more elegant solution? maybe to do a down stream analysis after the neighbor finder? So i would identify 5 nearest, then compute the angle only for those points?

Yes - you can use AttributeReprojectors to reproject the _closest_candidate_x, _y and _closest_base_x, _y to EPSG:3857, then calculate the angle using the @atan2() function in an AttributeCreator:

@radToDeg(@atan2((@Value(_closest_candidate_y)-@Value(_closest_base_y)),(@Value(_closest_candidate_x)-@Value(_closest_base_x))))