[pdal] boundary json coordinate order for geographic

[Kirk Waters - NOAA Federal]

A small update. It seems like this behavior is not consistent. The very
large (10Gb) laz file that surfaced this problem has json output where the
order of coordinates is different in the "boundary" element compared to the
"boundary_json" element. Here are the last few of the boundary coordinates
and the first few of the boundary_json coordinates from the same output:

-80.089349 26.156294,-80.089265 26.156342,-80.089265 26.156439,-80.089349
26.156391,-80.089418 26.156415,-80.089376 26.156342,-80.089432
26.156294,-80.089432 26.156198,-80.089376 26.15615,-80.089432
26.156053,-80.089502 26.156077,-80.089557 26.156029,-80.089502
26.155981,-80.089557 26.155884,-80.089502 26.155836,-80.089557
26.15574,-80.089516 26.155716)))",
    "boundary_json": { "type": "MultiPolygon", "coordinates": [ [ [ [
26.097269499999999, -80.411669090000004 ], [ 26.097269499999999,
-80.411251469999996 ], [ 26.097317719999999, -80.411195789999994 ], [
26.097269499999999, -80.411112259999996 ], [ 26.097269499999999,
-80.410165649999996 ]

>From a different laz file of the same general area and in the same
coordinate system, but much smaller at around 90 Mb the pdal info
--boundary output looks like this:

(-80.93805 26.603566,-80.938917 26.605068,-80.938917 26.602064,-80.936605
26.602064,-80.935448 26.603066,-80.935737 26.604567,-80.93805
26.603566),(-80.947588 26.604067,-80.947588 26.602064,-80.943542
26.602064,-80.942386 26.603066,-80.943542 26.605068,-80.945854
26.605068,-80.947588 26.604067)))",
    "boundary_json": { "type": "MultiPolygon", "coordinates": [ [ [ [
-80.987766449999995, 26.554502500000002 ], [ -80.98603215,
26.554502500000002 ], [ -80.984875950000003, 26.5555038 ], [
-80.983141649999993, 26.554502500000002 ], [ -80.980829249999999,
26.554502500000002 ], [ -80.979673050000002, 26.5555038 ], [
-80.977938739999999, 26.554502500000002 ],

You can see that the coordinates are in the same order in the boundary and
boundary_json elements and everything works as expected. I've put the big
file on ftp if you want to test, but it is painfully large.
ftp://ftp.coast.noaa.gov/tmp/kwaters/jobpoints.laz

Kirk


On Wed, Feb 23, 2022 at 7:35 AM Kirk Waters - NOAA Federal <
kirk.waters at noaa.gov> wrote:

> Hi,
> I've been using pdal info --boundary to generate bounds for datasets. I
> take the boundary_json element and feed it to ogr2ogr to use for clipping.
> That has worked well. However, if the data is in geographic, the
> coordinates get flipped. Instead of xy, the entries are lat lon. For
> example (in Florida):
>
> {"type": "MultiPolygon", "coordinates": [[[[26.0972695, -80.41166909], ...
>
> That seems like it would match with the GDAL expectation since GDAL 3
> honors by default authority (EPSG) axis order, so that means lat/lon for
> geographic CRS. But I think it conflicts with GeoJSON in the spec section
> 3.1.1 <https://datatracker.ietf.org/doc/html/rfc7946#section-3.1.1>. In
> any case, when I convert that JSON of the bounds with something like:
>
> ogr2ogr -a_srs EPSG:4759 bounds.gpkg bounds.json
>
> I'll get the order flipped and it will be south of Africa instead of in
> Florida. If I flip all the coordinates in the json and then run it through
> ogr2ogr, it lands in the right place. Is this a PDAL issue or am I just
> doing something wrong?
>
> Kirk
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/pdal/attachments/20220223/351f0bfc/attachment.html>