Lat / Long support

[Chrismarsh]

Experimental support is now enabled for lat/long input files in commit 65693a0.

Current problems

• CHM will scale all lat/long values by 100000 for the vtu output as Paraview seems to struggle rendering points so close to together.
• This scaling occurs during mesh read -- will be to be fixed later to be only in the vtu output.
• Internal area calculations are wrong, so should be computed as a parameter in mesher
• Internal distance calculations are wrong. Do the following?http://stackoverflow.com/questions/27928/calculate-distance-between-two-latitude-longitude-points-haversine-formula

[Chrismarsh]

Added back in support for geographic.

Internal (fast) distance calculations such as those used to cull stations in a radius and for buffer calculations (e.g., Liston wind) will be wrong as they assume meters, but the underlying mesh is in lat/long units.

I need a way to take meter distances and convert to delta-latlong. @NicWayand do you know if such a thing exists?

[NicWayand]

Hey Chris did you find a way for meter to delta-latlong? I have some scripts to go the other way. But hisw would depend where you are and what direction you are going I believe. Will think about it.

[Chrismarsh]

I've introduced point_from_bearing to solve this. Given a starting lat/long point, a bearing, and a distance, it computes the destination point. I have implemented a similiar version for UTM. These are in the new math/distance.*pp files. core::init() then uses boost function to hook up the function to the lat/long or UTM version. This way modules can seamlessly ask for "point X distance away in direction Y" regardless of coordinate system. This point can then be used as input to the existing find closest triangle functions.

The distance function is similar and computes the distance between two points and at runtime is hooked up to the right backend function depending on the coordinate system

[Chrismarsh]

This should be resolved in commit 6b4ee3a1e8bfd