XY order

default

By default, the order and interpretation of the two-point coordinates in the GeoDMS Geometric functions is Y and then X (row-column). This originates from the fact that the GeoDMS was developed to calculate mainly with Grid data, in which the row is usually the major order and left index and column the minor order and right index.

setting

Later on, when the GeoDMS was used more and more for projects using also (and mainly) Vector data, a setting was introduced in the config.ini to set the coordinate order to (X, Y) to overrule the default (Y, X) order.

YX: For projects with mainly Grid data, we did advise to keep the default orientation Y, X. No settings have to be added to the config.ini, or the following setting can be added:

ConfigPointColRow=0

XY: For projects with mainly Vector data, we did advise to overrule the order to X, Y by the following setting in the config.ini file:

ConfigPointColRow=1

Starting from GeoDMS 14.9.0, the point function and point literal syntax are marked as deprecated as part of a step-by-step plan to phase out the use of the (sometimes unexpected) configuration of the coordinate order with this setting.

Starting from GeoDMS 14.9.0, the advice is to use point_xy(first, second, optional coordinate unit) to specifically provide coordinates in traditional GIS-order. Using functions that depend on the ConfigPointColRow setting now produces a deprecation warning. For the PROJ functions, all coordinates are converted from DMS-order to projection-specific order and, after conversion back, depending on the destination CRS.
We’ve planned to internally revert the (first=row, second=col) order to (first=x, second=y) order to guarantee that DMS-order == traditional-GIS-order in GeoDMS 15.0.0; we expect the Area function and boost::polygon clipping functions to be unaffected (as its implementation takes the definition of the DMS-order into account). Still, conversions to string, CSV output, and table-column representation will be affected.
in a later version, the old functions that depend on the ConfigPointColRow setting will become obsolete.

textual representation

Since GeoDMS 20.14.0, every textual rendering of a point states which coordinate comes first, in the same xy(..) / yx(..) spelling that point literals in [[data blocks data block]] have used since 18.1.0. Output is always xy(x; y):

where	example
the Range and cat_range Property	`range = "[xy(0; 300000), xy(280000; 625000))"`
the `Range` entry in an MMD `0Dictionary.dms`	`Range = "[xy(0; 0), xy(5; 4)) "`
`string(..)` of a point	`xy(280000; 625000)`
`string(..)` of an Arc or Polygon	`{5: xy(10; 10) xy(20; 10) xy(20; 20) xy(10; 20) xy(10; 10)}`
the Range row of the Detail pages	`From xy(0; 300,000) to xy(280,000; 625,000)`

Reading is lenient, so nothing that was configured earlier stops working:

xy(x; y) states the x coordinate first, yx(y; x) the y coordinate first;
a bare {first, second} is the legacy untagged form and always meant {row, col}, that is {y, x} — the same reading as before 20.14.0;
, and ; are interchangeable, both between the two coordinates of a point and between the two bounds of a range.

Reading a Range written in the untagged form now reports a deprecation warning, naming the xy(..) spelling to replace it with. The reading itself is unchanged, so a configuration that triggers the warning still produces the same rectangle; the warning marks a spelling whose meaning is not visible in the text, and which a future major version is intended to stop accepting.

So the following four all denote the same rectangle, x in [0, 280000) and y in [300000, 625000):

unit<fpoint> rdc_meter: range = "[xy(0; 300000), xy(280000; 625000))"; // written by 20.14.0
unit<fpoint> rdc_meter: range = "[xy(0, 300000), xy(280000, 625000))";
unit<fpoint> rdc_meter: range = "[yx(300000, 0), yx(625000, 280000))";
unit<fpoint> rdc_meter: range = "[{300000, 0}, {625000, 280000})";     // legacy, still accepted

Before 20.14.0 the untagged form was not only ambiguous but inconsistent: the range property rendered a point as {row, col} while the detail pages rendered the very same rectangle as {col, row}.

The same release also stopped GeoDMS from rendering whole numbers in scientific notation — a coordinate of 300000 used to come out as 3e+05, and with thousand separators switched on as the corrupted 3e,+05. Plain notation is now used whenever the value permits it, and a value that does still need scientific notation never gets thousand separators.

examples

The following two examples show how to configure a geographic Grid Domain based on the setting for the X, Y order:

I (default order of Y, X):

unit<fpoint> rdc_meter: Range = "[{300000, 0}, {625000, 280000})";

parameter<rdc_meter> TopLeftCoord := point(float32(625000), float32(10000), rdc_meter);

parameter<int16> nrofrows := int16(3250);
parameter<int16> nrofcols := int16(2700);

unit<spoint> rdc_100m
:=  range(
      gridset(
         rdc_meter
        ,point(float32(-100), float32(100), rdc_meter)
        ,TopLeftCoord
        ,spoint
      )
      ,point(int16(0), int16(0))
      ,point(nrofrows, nrofcols)
   )
,  Descr = "rdCoords/100m van NW naar SE (3250 rows, 2700 cols)";

II (order overruled to X, Y):

unit<point> rdc_meter: Range = "[{0, 300000}, {280000, 625000})";

parameter<rdc_meter> TopLeftCoord := point(float32(10000), float32(625000), rdc_meter);

parameter<int16> nrofrows := int16(3250);
parameter<int16> nrofcols := int16(2700);

unit<spoint> rdc_100m
 :=  range(
       gridset(
          rdc_meter
         ,point(float32(100), float32(-100), rdc_meter)
         ,TopLeftCoord
         ,spoint
       )
       ,point(int16(0), int16(0))
       ,point(nrofcols, nrofrows)
   )
,  Descr = "rdCoords/100m van NW naar SE (3250 rows, 2700 cols)";

III (advised from GeoDMS 14.9.0):

unit<fpoint> rdc_meter := Range(fpoint, point_xy(0, 300000), point_xy(280000, 625000));

parameter<rdc_meter> TopLeftCoord := point_xy(float32(10000), float32(625000), rdc_meter);

parameter<int16> nrofrows := int16(3250);
parameter<int16> nrofcols := int16(2700);

unit<spoint> rdc_100m
 :=  range(
       gridset(
          rdc_meter
         ,point_xy(float32(100), float32(-100), rdc_meter)
         ,TopLeftCoord
         ,spoint
       )
       ,point_xy(int16(0), int16(0))
       ,point_xy(nrofcols, nrofrows)
   )
,  Descr = "rdCoords/100m van NW naar SE (3250 rows, 2700 cols)";