[geokon]

So this is sorta above my pay grade but I think this is a tangential issue.

Even if you are reading exotic data in some parochial format you internally probably wanna use one consistent format. If you have some massive data sets and don't wanna convert on read-in then there are way around that (you can setup a memoization system to convert and cache on as-needed basis). This format should be intuitive and convenient. I proposed a South/East format.. but you're free to choose whatever you want here. But the point is that Lon/Lat is likely never a good choice at this junction. It still has issues and you generally can do better.

At the interface the default we've arrived to as a society Lat/Lon WGS84 :) The merits here are irrelevant. If you want to support other i/o formats then you may. That really depends on your usecases - but they shouldn't map to whatever format you've decided on internally. And even if they did, you probably shouldn't be using Lon/Lat internally anyway

[kabes]

What you use internally really depends on the application requirements. Different projections have different properties. Depending on the area you need to cover and the questions you need to answer you may need to use multiple projections and to match performance requirements you may need to store all of these projections so you don't always need to convert on the fly