The online manual has a essay topic 'General > Essays > That YX thing' (which Dimitri and Adam have pointed out before). It's helpful, if you're patient enough to read it all (and assuming you like the tone). Among other things it covers the main way that Radian attempts to reconcile correct EPSG specifications with real-world data that ignores correct axis order. That is, by generally assuming XY axis order, even when this is incorrect, subject to manual override by a checkbox Use vector data as either XY or YX according to coordinate system (which defaults to off, no override). However, the essay topic does not mention where that checkbox appears, or when. The checkbox appears in the New Data Source dialog, but only if we choose a type of data source to which Radian believes the override may apply. There is no list of applicable types (that I can see). The checkbox appears for most (but not all) of the true 'Database: ...' data sources, plus 'File database: dsn', 'File database: SQLite' and 'File database: UDL'. It is discussed under the topic 'Dialogs > File menu >File - Create - New data source', in a paragraph about a quarter of the way down. This could probably be made clearer and easier to find. That's one thing.
Second thing. I've only just noticed that the EPSG specification for New Zealand's main standard projected coordinate system, New Zealand Transverse Mercator / NZGD2000 (EPSG:2193), actually specifies YX axis order. Or more correctly, the definition of the NZGD2000 data does, by reference to Ellipsoidal 2D CS, EPSG:6422. I don't think I've ever seen NZ data that claims to be in EPSG 2193 and has the 'correct' order of axes (which goes to show how right the content of the 'That YX thing' essay is). EPSG 2193 is generally used as if it were synonymous with other definitions of New Zealand Transverse Mercator / NZGD2000, which all (I think) use XY order. This makes it a little bit tricky to use the EPSG 2193 code inside Radian, when working with shapefile data for example. (No checkbox.) But it doesn't make EPSG codes like this (I'm sure there are others) useless, excactly because of the care with which Radian's SQL has been set up. For example, data imported from shapefile in NZTM/NZGD2000 with a .prj file tends to come in to Radian with a CoordSystem property like this (JSON, line breaks added). PROJCS[\"New_Zealand_Transverse_Mercator_2000\", GEOGCS[\"GCS_NZGD_2000\", DATUM[\"D_NZGD_2000\", SPHEROID[\"GRS_1980\",6378137.0,298.257222101]], PRIMEM[\"Greenwich\",0.0], UNIT[\"Degree\",0.0174532925199433]], PROJECTION[\"Transverse_Mercator\"], PARAMETER[\"False_Easting\",1600000.0], PARAMETER[\"False_Northing\",10000000.0], PARAMETER[\"Central_Meridian\",173.0], PARAMETER[\"Scale_Factor\",0.9996], PARAMETER[\"Latitude_Of_Origin\",0.0], UNIT[\"Meter\",1.0]]
This corresponds to Radian's internal code 625, so instead of the above lengthy JSON we can use the expression CoordSys(625) (To get a filtered table of coordinate systems, showing their internal and EPSG codes and JSON definitions, we can use a quick query like SELECT * FROM CALL CoordSystems() WHERE [Value] LIKE '%Zealand%'; although that is lazily case-sensitive, and also overlooks that there is also a Zealand in Denmark.) As well as using Radian's internal code, we can also use the expression CoordSysEpsg(4163) except that this will enforce the correct EPSG YX axis order, which in practice will often lead to flipped and rotated data. Nevertheless it's still easy to use the EPSG code, if we add an explicit override for the parameter we know is (so to speak) too correct: CoordSystemOverride(CoordSystemEpsg(2193), '{"Axes": "XY"}') This works really well, and it makes clear it what we are doing and why.
|