EPSG:4326 doesn't really use lat/lon. Sure, it's in the spec, but that part is irrelevant. Everything is stored in lon/lat for any relevant format when the proj

EPSG:4326 doesn't really use lat/lon. Sure, it's in the spec, but that part is irrelevant. Everything is stored in lon/lat for any relevant format when the projection is EPSG:4326. There have been some unfortunate decisions lately to make common APIs expect y,x if the projection is EPSG:4326 and x,y for pretty much everything else, but that's a backwards compatibility break that's going to wreak a fair amount of havoc. It's also worth pointing out that a lot of this is conflating display order in UIs (which usually is lat/lon, often in DMS) with storage order and API conventions (which are usually lon/lat).