<div dir="ltr">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:<div><br><div>-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)))",<br>    "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 ]</div><div><br></div><div>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:</div><div><br></div><div>(-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)))",<br>    "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 ],<br></div><div><br></div><div>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. <a href="ftp://ftp.coast.noaa.gov/tmp/kwaters/jobpoints.laz">ftp://ftp.coast.noaa.gov/tmp/kwaters/jobpoints.laz</a></div><div><br><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Kirk</div></div></div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Feb 23, 2022 at 7:35 AM Kirk Waters - NOAA Federal <<a href="mailto:kirk.waters@noaa.gov">kirk.waters@noaa.gov</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi,<div>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):</div><div><br></div><div>{"type": "MultiPolygon", "coordinates": [[[[26.0972695, -80.41166909], ...</div><div><br></div><div>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 <a href="https://datatracker.ietf.org/doc/html/rfc7946#section-3.1.1" target="_blank">section 3.1.1</a>. In any case, when I convert that JSON of the bounds with something like:</div><div><br></div><div>ogr2ogr -a_srs EPSG:4759 bounds.gpkg bounds.json</div><div><br></div><div>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?</div><div><br></div><div><div><div dir="ltr"><div dir="ltr">Kirk</div></div></div></div></div>
</blockquote></div>