es are visible in public C++ API.
The C API stays untouched. On
Both changes target upcoming libLAS 1.2.
Ff these changes will cause any problems, please report them here or
as ticket comments, so I can fix quickly.
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo
2 is
> the synopsis of things that have changed since the 1.0.1 release.
Hobu,
I have submitted two additional improvements:
http://liblas.org/ticket/99
http://liblas.org/ticket/117
IMHO, it's ready!
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
Char
;
> That presumes it is printable, but it could easily not be.
As user data can be a binary content as well.
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org
___
Liblas-devel mailing list
Liblas
ng to?
Recently, Point Source ID access has been implemented:
http://liblas.org/ticket/87
http://liblas.org/ticket/115
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
___
Liblas-devel mailing list
Liblas-devel@lists.osgeo.org
http://lists.osge
Howard Butler wrote:
>
> On Mar 30, 2009, at 12:07 PM, Mateusz Loskot wrote:
>
>> Volker Wichmann wrote:
>>> Hi,
>>> I've a question regarding the handling of the point source id:
>>> I just realized that neither txt2las nor las2txt support psid, t
to filter N number of
classifications or range(s) of intensities at once.
las2las --eliminate-class 0,5,7
las2las --eliminate-intensity 0-32,128-255
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org
___
used to manage (read, write) all properties of classification.
I'm going to implement all relevant parts of this enhancement.
First, I'd like to know your comments about this idea.
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
Howard Butler wrote:
>
> On Apr 15, 2009, at 8:16 AM, Mateusz Loskot wrote:
>
>> Folks,
>>
>> Handling classification is not as easy as it may seem. There are number
>> of elements like lookup table stored is variable-length record (LAS 1.0)
>> or defin
Mateusz Loskot wrote:
Howard Butler wrote:
On Apr 15, 2009, at 8:16 AM, Mateusz Loskot wrote:
Folks,
Handling classification is not as easy as it may seem. There are number
of elements like lookup table stored is variable-length record (LAS 1.0)
or defined in spec (LAS 1.1+) as well as
ly if both conditions are true: 1) libLAS is explicitly
configured with libgeotiff and 2) geotiff header is included.
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org
___
Liblas-devel mailing list
Li
Howard Butler wrote:
On Apr 20, 2009, at 10:17 AM, Mateusz Loskot wrote:
Hobu,
"LIBGEOTIFF_VERSION is never defined by any of our configuration
stuff. What was the thought here?"
I know LIBGEOTIFF_VERSION is never defined anywhere in libLAS, but
it is defined by libgeotiff. N
Howard Butler wrote:
On Apr 21, 2009, at 3:44 AM, Mateusz Loskot wrote:
So, may be we can just restrict that if user wants GDAL, he must include
libgeotiff to avoid such clashes.
That's not a bad idea.
http://liblas.org/ticket/132
Very good. Ticket updated.
Best regards,
--
Ma
PI wrapper and make the core higher
priority but the wrapper following (slow, fast or very slow) what
happens in the core. See GTK+ (C) and Gtkmm (C++).
Regardless of my personal disappointment about the C++ vs C API in GDAL,
I'm not going to force any other approach in libLAS
nt data format 0 is duplicated in
liblas::v10::ReaderImpl and liblas::v11::ReaderImlpl, etc.
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org
___
Liblas-devel mailing list
Liblas-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/liblas-devel
clude, but not to ./detail.
I mean, that's basically the idea of this include vs detail structure.
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org
___
Liblas-devel mailing list
Liblas-devel@list
--
VLR Summary
---------
User: 'LASF_Projection' - Description: ''
ID: 34735 Length: 72
User: 'LASF_Projection' - Description: ''
ID: 34736 Leng
suffering from significant
lack of power recently.
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org
___
Liblas-devel mailing list
Liblas-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/liblas-devel
he autotools gang, see what tools are being called:
http://liblas.org/browser/trunk/autogen.sh
It looks like the doc update request has been forgotten :-)
http://liblas.org/ticket/90
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org
Mateusz Loskot wrote:
I have tested libLAS from current SVN trunk on FreeBSD 7.2 (amd64)
Here is complete log: http://osgeo.pastebin.com/d6a6344cd
I don't remember which version of compiler I used (I can check it
tomorrow), though I'm quite sure it's 4.x line.
Following it up, I
ke FreeBSD is more strict and does not accept double slash
in paths, that's why temporary test files can't be removed. Need to be
fixed.
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
___
Liblas-devel mailing list
Liblas-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/liblas-devel
gr is not at all in OGR's code style and would likely
have to be rewritten a bit to satisfy the OGR style gods.
It would be a bit silly to make libLAS a dependency for GDAL/OGR just
for this utility, as there are no other places in GDAL/OGR where libLAS
is used.
Best regards,
--
Mateusz Lo
ayer
lookup as in ogr2ogr.
However, there are number of issues that make the task more
complex to make it user friendly :-)
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
___
Liblas-devel mailing list
Liblas-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/liblas-devel
two above:
http://liblas.org/browser/trunk/src/detail/writer.cpp#L130
http://liblas.org/browser/trunk/src/detail/reader.cpp#L156
I'd be happy to provide you with simpler or even Java-oriented
explanation, but I am not aware of any. I hope this will help.
Best regards,
--
Mateu
try to find GeoTIFF
implementation in Java or perhaps there is Java binding for libgeotiff
available.
Best regards,
--
Mateusz Loskot
http://mateusz.loskot.net
___
Liblas-devel mailing list
Liblas-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/liblas-devel
s more related to how LAS files are generated.
IMHO, it's more a creator's responsibility to generate consistent dataset.
Disclaimer: I'm a programmer, not RS/GIS analyst, so I may have little
knowledge how the industry works with data.
Best regards,
--
Mateusz Loskot
http://mateusz.
unding:
http://liblas.org/browser/trunk/apps/lascommon.c#L281
This 6 decimal points is a reasonable choice of precision
used to present float-point value for data inspection purpose.
The libLAS, the library, does not (should not) do any rounding.
Best regards,
Howard?
Otherwise, it's impossible to identify what is what, and what is wrong.
[1] http://lists.osgeo.org/pipermail/liblas-devel/2009-July/000558.html
--
Mateusz Loskot
http://mateusz.loskot.net
___
Liblas-devel mailing list
Liblas-dev
I'd go for it.
> b) should this constitute a major release (I would propose to call it
> 1.4 so as to not confuse with the LAS spec due to no 1.3 support in
> trunk currently).
Good point. The fix is substantial as you've pointed.
I have no problem with new major release.
Best
on Linux.
But first, you need to learn how to use MinGW, in general.
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
___
Liblas-devel mailing list
Liblas-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/liblas-devel
Howard Butler wrote:
>
> On Jul 29, 2009, at 7:52 PM, Mateusz Loskot wrote:
>>
>> What's the default behavior if a user does not set the offset?
>>
>
> The behavior we had before -- required 227 header bytes + any space
> required for the VLRs + (2 byt
,
--
Mateusz Loskot, http://mateusz.loskot.net
___
Liblas-devel mailing list
Liblas-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/liblas-devel
[1] http://lists.osgeo.org/pipermail/gdal-dev/2008-July/017697.html
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org
___
Liblas-devel mailing list
Liblas-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/liblas-devel
o it more, when the reader
> crashes, it has been near the malloc call of the new operator. Just more
> evidence of memory allocation problems.
Possibly, heap corruption occurs.
Tomorrow, I'll try to run the code from the tutorial and see myself.
Best regards,
--
Mateusz Loskot, http://
Mateusz Loskot wrote:
> Gary Robinson wrote:
>> I can work around the problem by running in release mode only, but it is
>> somewhat inconvenient. Either way, there are probably memory bugs in the 1.2
>> release. If you run your c++ tutorial code in the visual studio
, please sound off.
+1
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
___
Liblas-devel mailing list
Liblas-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/liblas-devel
Howard Butler wrote:
>
> On Aug 26, 2009, at 9:29 AM, Mateusz Loskot wrote:
>
>> Howard Butler wrote:
>>> All,
>>> I would like to migrate our source repositories from subversion to
>>> mercurial. We will continue to use Trac with plugin support for
&
nt.SetCoordinates(10,20,30);
writer.WritePoint(point);
}
}
catch (std::exception const& e)
{
std::cerr << e.what() << std::endl;
}
catch (...)
{
std::cerr << "unknown error" << std::endl;
}
own error" << std::endl;
}
return 0;
}
/// end of mloskot version /
It would be best to try to build debug version and test the program with it.
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
__
me that a reader knows how to apply all the rest in C++.
Anyway, your program works for me with libLAS from the repository.
I'll try to check your screens over the weekend
and see if I can find the problem.
Best regards,
--
Mateusz Loskot
http://mate
Mateusz Loskot wrote:
> I'll try to check your screens over the weekend
> and see if I can find the problem.
I tried to reproduce this problem using libLAS 1.2.0
from .tar.bz2 source package as well as from the 1.2.0 tag
in the repo, but without success.
Shortly, the test program do
Mateusz Loskot wrote:
> Mateusz Loskot wrote:
>> I'll try to check your screens over the weekend
>> and see if I can find the problem.
>
> I tried to reproduce this problem using libLAS 1.2.0
> from .tar.bz2 source package as well as from the 1.2.0 tag
>
inaries, you may want to build
libLAS on your own. It's not difficult, just take a look at nmake.opt file.
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org
___
Liblas-devel mailing list
Libl
/2008-May/037726.html
(you may want to walk through the whole thread).
Basically, what is LiDAR data?
IMO, it's more of raster nature in form of vector.
p.s. Please, post to liblas-devel so others have chance to participate.
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
Chart
#x27;s see if this [1] improvement will catch what's the
real HAVE_BOOST value.
[1] http://liblas.org/changeset/1260%3A69fab7799e56
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org
___
Liblas-de
n the main:
http://liblas.org/changeset/1275%3A8cdb184b92e7
Simply, the [ and ] quoting can not be nested as it was in the old
version of help string. Instead, special "generators" need to be used:
@<:@ for [ and @:>@ for ].
Interesting is that I didn't get any er
~isenburg/lastools/
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org
___
Liblas-devel mailing list
Liblas-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/liblas-devel
Volker Wichmann wrote:
> On 09/08/2009 11:10 PM, Mateusz Loskot wrote:
>> Pete Gadomski wrote:
>>> Hello
>>>
>>> I can verify the Volker's
>>> error...I don't have boost installed and I used a checkout with the
>>> http://liblas.or
Pete Gadomski wrote:
> Mateusz (et al),
> I can confirm both ./autogen.sh and make are now working on my system. The
> library compiles and installs a-ok!
> Thank you for the fix!
Thanks for reporting and confirming!
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
Chart
Folks,
I've just noticed that our Buildbot [1] instance hasn't been
re-configured after migration to new repository.
FYI, I'm going to take care of it tonight.
[1] http://buildbot.osgeo.org:8507/waterfall
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
Charter Member
st regards,
--
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org
___
Liblas-devel mailing list
Liblas-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/liblas-devel
Mateusz Loskot wrote:
> Folks,
>
> Personally, I have an impression that building instructions available
> on website are quite ascetic. Also, the list of libLAS dependencies
> has grown recently. This information may be insufficient for users.
> So, I would like to pu
ke will help to get rid of the hassle of
maintaining build configurations for Windows and Unix.
Tests, comments, fixes are welcome!
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org
___
Liblas-devel mail
7;re processing.
Any chance to provide us with sample file so we can try to
reproduce the problem?
Also, please verify if you're suffering of this known issue:
http://liblas.org/ticket/147
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
_
classifications
> and tagged the bulk as unclassified, 2 created, never classified and 3
> overlapping points.
but no error, right?
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org
___
M S wrote:
> The problem is for all the same .las files of a given provider. It
> writes out odd elevations. The one I can provide is the same problem
> for all it seems upon initial inspection.
It's impossible to tell what's wrong without data sample.
Best regards,
--
M
to All" otherwise your message does not reach
back the thread on the liblas-devel mailing lists, instead it goes
exclusively to myself.
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org
___
Liblas-deve
M S wrote:
> It is on its way. The file is "LID2006_86525.las.gz". should be
> there before 4PM.
>
> Much thanks,
> Mark
>
> On Tue, Sep 29, 2009 at 2:54 PM, Mateusz Loskot wrote:
>> M S wrote:
>>> The problem is for all the same .las fil
Mateusz Loskot wrote:
> M S wrote:
>> It is on its way. The file is "LID2006_86525.las.gz". should be
>> there before 4PM.
Mark,
Would it be possible to grant libLAS with permission to add your
file to http://liblas.org/sample - as Howard has asked already?
We
for such an incredible set of tools
> to work with las files in an open source environment.
On behalf of the team, thank you for your kind words!
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org
___
onically.
Mark,
Thank you very much for the details.
I will leave it to Howard to decide if these data are usable as samples.
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org
___
Liblas-devel mail
re.
Just drop a note that new file is there, so we can grab it.
Cheers,
--
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org
___
Liblas-devel mailing list
Liblas-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/liblas-devel
td::istream& ifs, LASHeader const& header)
as long as I understand it correctly that it's input-only parameter,
should be anyway.
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org
___
Howard Butler wrote:
>
> On Oct 6, 2009, at 2:13 PM, Mateusz Loskot wrote:
>
>> Howard Butler wrote:
>>> I propose that we provide a
>>>
>>> LASReader(std::istream& ifs, LASHeader& header)
>>>
>>> constructor, and if thi
; Fantastic! Thanks for the effort Francesco.
Great indeed!
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org
___
Liblas-devel mailing list
Liblas-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/liblas-devel
t is on C: drive, the DLL probably is inin C:\OSGeo4W\bin
Now, try to add C:\OSGeo4W\bin to PATH environment variable, open
console and issue this command:
C:\> set PATH=C:\OSGeo4W\bin;%PATH%
C:\>python
>>>> import liblas
Does it work?
Best regards,
--
Mateusz Lo
>
> it gives me the following error while compiling...
>
> undefined reference to 'LASReader_Create'
> undefined reference to 'LASReader_Destroy'
>
> can you help me to solve the problem?
No, it's not possible, unless you give command how you compile an
Black, Michael (IS) wrote:
> I already communicated with Riki and solved his problem.
OK, thanks.
> He's running Linux
>
> cc -o myprog mprog.c -llas
Yes, this command is not enough.
This links only against C++ API, but C API is a separate library.
Best regards,
--
Mat
my confusion.
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
___
Liblas-devel mailing list
Liblas-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/liblas-devel
help:
http://liblas.org/wiki/ConvexHull
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org
___
Liblas-devel mailing list
Liblas-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/liblas-devel
es: liblas.lib
>
> However, if I change that dependency to the Windows import library
> (liblas_i.lib) for the liblas1.dll, the linker reports unresolved symbol
> errors:
> [...]
> Is there something else that's needed to link with the libLAS dll?
James,
If you
t/export) included. See LAS_DLL tag:
http://liblas.org/browser/include/liblas/capi/las_config.h#L58
http://liblas.org/browser/include/liblas/capi/liblas.h#L128
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org
_
,
Etienne,
There seem to be a problem with libLAS package for OSGeo4W.
We are going to fix it soon.
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org
___
Liblas-devel mailing list
Liblas-devel@lists.o
compiler you use where it can find libLAS header files as well as libLAS
library (static library if you use C++ API and import library for C API
DLL).
Best regards,
--
Mateusz Loskot
http://mateusz.loskot.net
___
Liblas-devel mailing list
Libl
E and makefile.vc files
or Visual C++ projects, everything should be set correctly.
p.s. Please, post your replies to liblas-devel mailing list too
so others have chance to track the discussion.
Best regards,
--
Mateusz Loskot
http://mateusz.loskot.net
_
ow to enable
or compile extensions to get them working with libLAS core.
In near future, I hope to get things better documented on the Wiki
(somewhere at http://liblas.org/wiki/Bindings/NET)
Perhaps new maintainer will emerge in the meantime.
Best regards,
--
Mateusz Loskot, http://mateusz
use of C API but just wrap libLAS
C++ native API with C++/CLR. So, no generators hell like SWIG,
but smooth interoperability between C++ and CLR through C++/CLR.
However, in case current bindings are in usable shape, such rework as
reimplementation does not make much sense.
p.s. I CC'ed the
orizontal, eVertical
};
LASSpatialReference::GetWKT(SpatialReferenceType type) { ... }
The latter is self-describing and less logical error prone, IMHO.
Best regards,
--
Mateusz Loskot
http://mateusz.loskot.net
___
Liblas-devel mailing list
Liblas-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/liblas-devel
Mateusz Loskot wrote:
> Howard Butler wrote:
>> On Jan 11, 2010, at 12:45 PM, Frank Warmerdam wrote:
>>
>>> Folks,
>>>
>>> I have been working on adding support for reading and writing vertical
>>> datums
>>> with liblas in .las files.
nd kudos!
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
___
Liblas-devel mailing list
Liblas-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/liblas-devel
rd for me to
>understand, as it used a lot of commands I don't quite understand. I am
>wondering is there any simple ways I can make use of the .NET binding of
>libLAS?
I can't help myself. I'm going to update .NET bindings and maintain it a
bit at some point aft
ports but not the other.
Great news! Martin, welcome on board.
Best regards,
--
Mateusz Loskot
http://mateusz.loskot.net
___
Liblas-devel mailing list
Liblas-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/liblas-devel
ell as with
std::min(v) -> (std::min)(v)
std::max(v) -> (std::max)(v)
I will commit these fixes to libLAS code later tonight.
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
___
Liblas-devel mailing list
Liblas-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/liblas-devel
> In fact I get also the following error:
>
> utility.hpp(253): warning C4003: not enough actual parameters for macro 'min'
As promised today, I committed the fix to libLAS repository:
http://liblas.org/changeset/1514%3A09b9b4ed037a
Best regards,
--
Mateusz Loskot,
G=YES
or select Debug configuration in Visual Studio.
IOW, if you build your program in Debug, links against libLAS debug too.
But, if you build your program in Release mode, link against libLAS
built as Release too.
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
Charter Membe
act.
> nmake.opt must be modified with the following lines for VS10 support
>
> !ELSEIF "$(_NMAKE_VER)" == "10.00.21003.01" MSVCVER = 10.0
Thanks, I'll commit this update.
> One last thing. The lib names in debug mode are:
>
> LAS_LIB = liblas_d.lib
>
Howard Butler wrote:
> All,
>
> Consider this your notice that the LASFile class is to be removed
> from the C++ API for the next release.
I'm fine with it.
> Was anyone using this class?
I wasn't and I don't know any uses of it.
Best regards,
--
Mateusz Los
ldLAS
Best regards,
p.s. please post your questions to the mailing list
http://lists.osgeo.org/mailman/listinfo/liblas-devel
--
Mateusz Loskot
http://mateusz.loskot.net
___
Liblas-devel mailing list
Liblas-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/liblas-devel
u team first:
https://launchpad.net/ubuntu/+source/liblas
If they find it's a bug in libLAS, we will get notified
and fix it here. Now, there is not much we can do
other than suggest you to build and install libLAS
from sources.
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
Char
> concerns or comments about this idea, I would be excited to hear about
> them.
And LAS mnemonic will become redundant and confusing.
To keep my usually long stories short, I would leave libLAS alone
as it is and develop new library with a proper and extensible
data model and bunch of driver
e for Boost libraries.
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
___
Liblas-devel mailing list
Liblas-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/liblas-devel
573/>
Cool! I want one too. It even grabbed sketches on the boar, brilliant.
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
___
Liblas-devel mailing list
Liblas-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/liblas-devel
Howard Butler wrote:
> On Feb 25, 2010, at 12:01 PM, Mateusz Loskot wrote:
>> Howard Butler wrote:
>>> LGPL wouldn't be the end of the world, but I think something like
>>> this needs to be BSD to ensure wider proprietary software
>>> uptake. Individua
egards,
--
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org
___
Liblas-devel mailing list
Liblas-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/liblas-devel
uthor.
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org
___
Liblas-devel mailing list
Liblas-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/liblas-devel
Testing liblas-devel archive @ Nabble
-
--
Mateusz Loskot
http://mateusz.loskot.net
--
View this message in context:
http://n3.nabble.com/Nabble-Test-tp431276p431276.html
Sent from the libLAS Developers mailing list archive at Nabble.com
Folks,
The mailing list is also available through Nabble now
http://n3.nabble.com/libLAS-Developers-f431198.html
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org
___
Liblas-devel mailing list
us time putting makeup on every new
head of growing monster.
[1] http://lists.osgeo.org/pipermail/liblas-devel/2009-April/000478.html
[2] https://lidarbb.cr.usgs.gov/index.php?showtopic=6385&st=0&p=7712
Best regards,
--
Mateusz Loskot, ht
Mateusz can give us the bits of cmake script that would do
> that.
Dan, Hobu,
I'll try to find out how to fix it.
I remember I tried to test all possible combinations of dependencies,
but some cases might have got missing.
Best regards,
Mateusz Loskot, http://mateusz.loskot.net
Cha
7;s going on here. I tried to specify MSVCRT.LIB
explicitly in liblas linker input(s) but it doesn't solve the problem.
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org
___
Liblas-devel mailing list
L
y users. I don't use these projects
myself anymore. Let's remove and see if any users will raise alarm :-)
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
___
Liblas-devel mailing list
Liblas-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/liblas-devel
1 - 100 of 155 matches
Mail list logo
