<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
A compatibility layer would be nice where practical, maybe marked
with the [[deprecated]] attribute. I'm not sure that all the
refactoring that has been done is amenable to that. I also don't
want PDAL to be held back or code quality to suffer from not
refactoring when appropriate.<br>
<br>
A minimal solution might be to call the next PDAL release version
3.0 to call attention to the API incompatibility. That way projects
can either specify they need 2.3 or test for 2.3 vs 3.0 and behave
accordingly. And then packagers will also get a heads up that
something changed where they need to pay extra attention.<br>
<br>
That's my 2 cents.<br>
<br>
<div class="moz-cite-prefix">On 1/26/22 07:28, Andrew Bell wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CACJ51z3bhGus622mBSRMhHhMT4i2YtxvWfTKCFggjEGX=-c7=Q@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">There may still be changes before release. I've
tried to maintain API in the past and it may be worth sticking a
layer on top of what''s in master to support users who have
already made PDAL part of their code. Unfortunately, our API
became everything, because there was no line drawn between
private code and public code from the library's outset. I've
tried to correct some of that, but haven't been terribly
successful.</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Fri, Jan 21, 2022 at 10:12
AM Howard Butler <<a href="mailto:howard@hobu.co"
moz-do-not-send="true" class="moz-txt-link-freetext">howard@hobu.co</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">Indeed,
the LAS code was refactored to bring together COPC/EPT and
LAS/LAZ common components. The LAS code was pseudo-private to
PDAL, and so we reserved the right to change it as needed
given PDAL's more public interfaces. <br>
<br>
We hope and expect that these changes weren't too disruptive,
but we would much rather add missing things that are needed
instead of supporting the previous behaviors and classes.
Please reach out if there is something that cannot be done
with the new pseudo-internal API that was available before.<br>
<br>
<br>
<br>
> On Jan 21, 2022, at 3:34 AM, Jean-Roc Morreale (ml) <<a
href="mailto:jrmorreale_ml@enoreth.net" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">jrmorreale_ml@enoreth.net</a>>
wrote:<br>
> <br>
> Hi,<br>
> <br>
> For CloudCompare, the PDAL plugin is being rewritten :<br>
> <a
href="https://github.com/CloudCompare/CloudCompare/pull/1561"
rel="noreferrer" target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">https://github.com/CloudCompare/CloudCompare/pull/1561</a><br>
> <br>
> as the plugin does not compile against current PDAL :<br>
> <a
href="https://github.com/CloudCompare/CloudCompare/issues/1573"
rel="noreferrer" target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">https://github.com/CloudCompare/CloudCompare/issues/1573</a><br>
> <br>
> Le jeudi 20 janvier 2022 à 14:22 -0600, Jim Klassen a
écrit :<br>
>> The recent changes to the LAS code broke the entwine
build in<br>
>> entwine/util/pipeline.cpp. It looks like things like
`scaleX()` need<br>
>> to be updated to `scale.x`. I also suspect these
changes probably<br>
>> also impact the CloudCompare PDAL plugin.<br>
>> <br>
>> However, I'm not sure where the fix should be:<br>
>> <br>
>> Is this a bug in entwine (and likely CloudCompare)
for using a pdal<br>
>> API that is intended to be private (and they should
be using entirely<br>
>> other means for accessing this information)?<br>
>> <br>
>> Is this an issue where entwine needs to be updated to
match the<br>
>> current pdal API?<br>
>> <br>
>> Is this an issue in pdal for changing the existing
API?<br>
>> <br>
>> Some/all/none of the above?<br>
>> _______________________________________________<br>
>> pdal mailing list<br>
>> <a href="mailto:pdal@lists.osgeo.org"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">pdal@lists.osgeo.org</a><br>
>> <a
href="https://lists.osgeo.org/mailman/listinfo/pdal"
rel="noreferrer" target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">https://lists.osgeo.org/mailman/listinfo/pdal</a><br>
> <br>
> _______________________________________________<br>
> pdal mailing list<br>
> <a href="mailto:pdal@lists.osgeo.org" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">pdal@lists.osgeo.org</a><br>
> <a href="https://lists.osgeo.org/mailman/listinfo/pdal"
rel="noreferrer" target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">https://lists.osgeo.org/mailman/listinfo/pdal</a><br>
<br>
_______________________________________________<br>
pdal mailing list<br>
<a href="mailto:pdal@lists.osgeo.org" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">pdal@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/pdal"
rel="noreferrer" target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">https://lists.osgeo.org/mailman/listinfo/pdal</a><br>
</blockquote>
</div>
<br clear="all">
<div><br>
</div>
-- <br>
<div dir="ltr" class="gmail_signature">Andrew Bell<br>
<a href="mailto:andrew.bell.ia@gmail.com" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">andrew.bell.ia@gmail.com</a></div>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
pdal mailing list
<a class="moz-txt-link-abbreviated" href="mailto:pdal@lists.osgeo.org">pdal@lists.osgeo.org</a>
<a class="moz-txt-link-freetext" href="https://lists.osgeo.org/mailman/listinfo/pdal">https://lists.osgeo.org/mailman/listinfo/pdal</a>
</pre>
</blockquote>
<br>
</body>
</html>