3 ms·

>Add on top of that the X-Y coordinate on images generally have the X flipped and starting at the top left corner. So changing to Lon/Lat doesn't fix everything

>Add on top of that the X-Y coordinate on images generally have the X flipped and starting at the top left corner. So changing to Lon/Lat doesn't fix everything. Oversimplified... but: Most raw/original geo-referenced imagery in the US are projected in a SPCS (state plane coordinate system) in survey-feet, which aren't defined in x,y but n,e (Northing, Easting) or sometimes e,n. This order isn't as universal as x,y, for various reasons. (UTM in meters is also common for larger areas.) SPCSs aren't all the same type of projections, so Lambert conic (parallel defined) vs Transverse Mercator (meridian defined) (the two most common) means the "first" measurement traversed isn't always the same. (On a sphere, if I tell you to go 100 miles north, then 100 miles east, you get to a different point than 100 miles east, then 100 miles north.) Being grid systems, this shouldn't matter, but surveyors who used to do manual transformations would get in the habit of the order they regularly used. So "flipped" is a matter of perspective. It's one of those things that's a tell for someones educational background and localisms. Surveyor/Geographer/Geodesist vs Scientist/Mathematician/Software Developer. Did a progammer-first person develop a particular file format, or did a cartography/geography-first person? Or some combination of a compromise? >I have no "geospatial" background Checks out. If you're a learn-by-doing person, I recommend looking up the transformations for a few common CRS/datums/projections and going through the equations manually, either with a quick script or in excel. Check/compare to results from the NGS tools page. The transform steps and math will reveal where order of operations matter. https://www.ngs.noaa.gov/ https://www.ngs.noaa.gov/ https://geodesy.noaa.gov/NCAT/ https://geodesy.noaa.gov/NCAT/ https://geodesy.noaa.gov/INFO/datums-transformations.shtml https://geodesy.noaa.gov/INFO/datums-transformations.shtml

geokon 5y ago
Err, sorry I have a typo in my original post. The Y is "flipped" (not X). I feel a Northing Easting system should appeal to both surveyors and mathematicians b/c it matches the X-Y plane we're used to in math class. But unfortunately it doesn't match display coordinates which conventionally start in the upper left corner. If I output say an SVG and it's got some weird artifact or things are cropped strange due to some off-by-one errors then it's much easier to debug if your internal geographic coordinates are aligned to the final display coordinates. You don't need to do any mental translation and offsetting to figure out how the values correspond between the two systems In fact I go so far as to output SVGs with degrees values (degrees relative to the upper left point) and then there is a global scale factor for the final image to fit whatever size I want - so the image units are in real degrees - this makes life a lot easier. After reading all the responsese here my argument would be that you should use whatever internal representation is most convenient programmatically - and then you expose in your API or UI or whatever a system based on other criteria (though it's hard to see how lon/lat would ever be sensible here). Your internal and external systems don't have to have any relation. As you've deduced my problem space isn't too concerned with projections at the moment. Both precipitation and elevation data comes in a GeoTIFF (ie. lat/lon grid). In fact doing any kind of projections would distort by grid and greatly complicate my life :) But it's something I will keep in mind. When you start looking at large areas then you effectively have different data densities at different ends of the region and this is not great (poleward things have disproportionately more data). Thanks for the extra information and references - it may come in handy eventually.

geokon 5y ago

Err, sorry I have a typo in my original post. The Y is "flipped" (not X). I feel a Northing Easting system should appeal to both surveyors and mathematicians b/c it matches the X-Y plane we're used to in math class. But unfortunately it doesn't match display coordinates which conventionally start in the upper left corner. If I output say an SVG and it's got some weird artifact or things are cropped strange due to some off-by-one errors then it's much easier to debug if your internal geographic coordinates are aligned to the final display coordinates. You don't need to do any mental translation and offsetting to figure out how the values correspond between the two systems In fact I go so far as to output SVGs with degrees values (degrees relative to the upper left point) and then there is a global scale factor for the final image to fit whatever size I want - so the image units are in real degrees - this makes life a lot easier. After reading all the responsese here my argument would be that you should use whatever internal representation is most convenient programmatically - and then you expose in your API or UI or whatever a system based on other criteria (though it's hard to see how lon/lat would ever be sensible here). Your internal and external systems don't have to have any relation. As you've deduced my problem space isn't too concerned with projections at the moment. Both precipitation and elevation data comes in a GeoTIFF (ie. lat/lon grid). In fact doing any kind of projections would distort by grid and greatly complicate my life :) But it's something I will keep in mind. When you start looking at large areas then you effectively have different data densities at different ends of the region and this is not great (poleward things have disproportionately more data). Thanks for the extra information and references - it may come in handy eventually.