From mateusz at loskot.net Tue Jan 1 11:09:03 2008 From: mateusz at loskot.net (Mateusz Loskot) Date: Tue Jan 1 11:12:48 2008 Subject: [Liblas-devel] Number of points by return Message-ID: <477A73AF.80201@loskot.net> Hi, One of the LAS file header members is array of "number of points by return". The LAS 1.x specifications do explain it in a few short sentences and a few details are not clear to me, especially about requirements/conditions. Is it correct to assume that total of values of "number of points by return" must be equal to "number of point records" ? Simple tests seem to give answer Yes, for example: number of point records: 213093 number of points by return: 128621, 84472, 0, 0 128621 + 84472 + 0 + 0 = 213093 Is it safe to assume it as a rule or not? Cheers -- Mateusz Loskot http://mateusz.loskot.net From Pete.Kollasch at dnr.iowa.gov Wed Jan 2 08:21:34 2008 From: Pete.Kollasch at dnr.iowa.gov (Kollasch, Pete [DNR]) Date: Wed Jan 2 08:25:22 2008 Subject: [Liblas-devel] Number of points by return Message-ID: That rule is fully consistent with my understanding of how LiDAR data works. The only reason I would hesitate to assume it as a rule would be if making the assumption would cause reading data from a broken data set to fail. If using the assumption causes a failure to read an inconsistent dataset, that's not very robust. Pete Kollasch Iowa Department of Natural Resources -----Original Message----- From: liblas-devel-bounces@mail.hobu.net [mailto:liblas-devel-bounces@mail.hobu.net] On Behalf Of Mateusz Loskot Sent: Tuesday, January 01, 2008 11:09 AM To: liblas-devel@mail.hobu.net Subject: [Liblas-devel] Number of points by return Hi, One of the LAS file header members is array of "number of points by return". The LAS 1.x specifications do explain it in a few short sentences and a few details are not clear to me, especially about requirements/conditions. Is it correct to assume that total of values of "number of points by return" must be equal to "number of point records" ? Simple tests seem to give answer Yes, for example: number of point records: 213093 number of points by return: 128621, 84472, 0, 0 128621 + 84472 + 0 + 0 = 213093 Is it safe to assume it as a rule or not? Cheers -- Mateusz Loskot http://mateusz.loskot.net _______________________________________________ Liblas-devel mailing list Liblas-devel@mail.hobu.net http://mail.hobu.net/mailman/listinfo/liblas-devel From mateusz at loskot.net Wed Jan 2 09:35:37 2008 From: mateusz at loskot.net (Mateusz Loskot) Date: Wed Jan 2 09:39:21 2008 Subject: [Liblas-devel] Number of points by return In-Reply-To: References: Message-ID: <477BAF49.6080902@loskot.net> Kollasch, Pete [DNR] wrote: > > That rule is fully consistent with my understanding of how LiDAR data > works. Pete, Thanks for confirmation. > The only reason I would hesitate to assume it as a rule would be if > making the assumption would cause reading data from a broken data set to > fail. If using the assumption causes a failure to read an inconsistent > dataset, that's not very robust. Yes, I agree with your opinion. Perhaps only warning should be issued if verbose mode requested, so user is well-informed. Best regards -- Mateusz Loskot http://mateusz.loskot.net From hobu.inc at gmail.com Wed Jan 2 10:58:50 2008 From: hobu.inc at gmail.com (Howard Butler) Date: Wed Jan 2 11:03:36 2008 Subject: [Liblas-devel] Number of points by return In-Reply-To: <477BAF49.6080902@loskot.net> References: <477BAF49.6080902@loskot.net> Message-ID: TerraScan doesn't appear to set the point returns by header info. A file from the Iowa DNR GeoTree download shows that they aren't set... http://liblas.org/ticket/10 Maybe we can't depend on this. Howard On Jan 2, 2008, at 9:35 AM, Mateusz Loskot wrote: > Kollasch, Pete [DNR] wrote: >> >> That rule is fully consistent with my understanding of how LiDAR data >> works. > > Pete, > > Thanks for confirmation. > >> The only reason I would hesitate to assume it as a rule would be if >> making the assumption would cause reading data from a broken data >> set to >> fail. If using the assumption causes a failure to read an >> inconsistent >> dataset, that's not very robust. > > Yes, I agree with your opinion. > Perhaps only warning should be issued if verbose mode requested, > so user is well-informed. > > Best regards > -- > Mateusz Loskot > http://mateusz.loskot.net > _______________________________________________ > Liblas-devel mailing list > Liblas-devel@mail.hobu.net > http://mail.hobu.net/mailman/listinfo/liblas-devel From mateusz at loskot.net Wed Jan 2 11:43:06 2008 From: mateusz at loskot.net (Mateusz Loskot) Date: Wed Jan 2 11:46:46 2008 Subject: [Liblas-devel] Number of points by return In-Reply-To: References: <477BAF49.6080902@loskot.net> Message-ID: <477BCD2A.3020603@loskot.net> Howard Butler wrote: > TerraScan doesn't appear to set the point returns by header info. A > file from the Iowa DNR GeoTree download shows that they aren't set... > http://liblas.org/ticket/10 > > Maybe we can't depend on this. Hobu, I confirm that 'Serpent_Mound_LAS_Data.las' file from Martin's webiste does report Zeros as points by return values. Looks like there is some inconsistency. Cheers -- Mateusz Loskot http://mateusz.loskot.net From hobu.inc at gmail.com Tue Jan 8 15:18:00 2008 From: hobu.inc at gmail.com (Howard Butler) Date: Tue Jan 8 15:22:07 2008 Subject: [Liblas-devel] Re: [gdal-dev] LAS format? In-Reply-To: <4783DD35.2030900@ucdavis.edu> References: <4783DD35.2030900@ucdavis.edu> Message-ID: <09B21014-992E-44B7-B9DA-9CE98311FC25@gmail.com> Jonathan, OGR does not currently support reading/writing LAS data, but there are some activities in the works toward moving that direction. Mateusz Loskot, Phil Vachon, and myself are currently working on developing a LAS library with the intent that an OGR driver will be built atop it http://liblas.org . The work builds on a library by Martin Isenburg that supports reading and writing LAS data. We are working on reengineering it to use stl streams for i/o, add C and Python APIs, and architect things with an eye toward supporting LAS 2.0 if that insane specification actually sees the light of day. Perry has a good synopsis and short term approach described on his weblog at http://www.perrygeo.net/wordpress/?p=38 As far as lobbying for inclusion, money and/or development time are the most effective persuasive instruments :) My goal is to have an OGR driver by the end of the year, however. Howard On Jan 8, 2008, at 2:29 PM, Jonathan Greenberg wrote: > Does OGR have any support for the LAS Lidar format? If not, how do > I go about lobbying for the inclusion? Its a fairly > straightforward, binary encoded set of x,y,z points. > > --j > > -- > > Jonathan A. Greenberg, PhD > Postdoctoral Scholar > Center for Spatial Technologies and Remote Sensing (CSTARS) > University of California, Davis > One Shields Avenue > The Barn, Room 250N > Davis, CA 95616 > Cell: 415-794-5043 > AIM: jgrn307, MSN: jgrn307@hotmail.com, Gchat: jgrn307 > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev From hobu.inc at gmail.com Tue Jan 8 15:38:15 2008 From: hobu.inc at gmail.com (Howard Butler) Date: Tue Jan 8 15:42:09 2008 Subject: [Liblas-devel] Re: [gdal-dev] LAS format? In-Reply-To: <4783DD35.2030900@ucdavis.edu> References: <4783DD35.2030900@ucdavis.edu> Message-ID: <0E56262B-E131-46A1-A272-6ABE56F804B0@gmail.com> Correction... > *Matt* Perry has a good synopsis and short term approach described > on his weblog at http://www.perrygeo.net/wordpress/?p=38 Howard From mateusz at loskot.net Sat Jan 12 10:21:21 2008 From: mateusz at loskot.net (Mateusz Loskot) Date: Sat Jan 12 10:25:13 2008 Subject: [Liblas-devel] File creation date Message-ID: <4788E901.4050402@loskot.net> Hi, Could anyone clarify the difference (or no difference) between Flight Date Julian attribute defined in LAS 1.0 and File Creation Day of Year defined in LAS 1.1 Size of both attributes is 2 bytes. My senses tell me that in both versions, this attribute stores exactly the same value - Day of Year. But, if I'm correct, then the LAS 1.0 Standard is incorrect or imprecise. The Julian Day (JDN) is number of days since Jan 1, 4713 BC. The Day of Year, as ordinal date is number of day since the beginning of a year, usually current year and ranges from 1 to 365 (366 - leap years). Why I think the "Julian Day" in LAS 1.0 is not real JDN but non-Julian ordinal Day of Year? Because unsigned integer of 2 bytes is too short to hold JDN number. 2 bytes can store up to 64535 (as unsigned), but today JDN is 2454478. this value is too big. Summarizing, is it correct to assume that in both LAS 1.0 and 1.1, value of attribute number 12 (Flight Date Julian 1.0 or File Creation Day of Year in 1.1) can store only values from 1 to 365 (366) ? BTW, I've noticed that in all LAS 1.0 data I have, none of date attributes (fields 12 and 13) are set. Only LAS 1.1 data I have does include value of this attribute. Is this a common practice? Cheers -- Mateusz Loskot http://mateusz.loskot.net From hobu.inc at gmail.com Sat Jan 12 13:05:54 2008 From: hobu.inc at gmail.com (Howard Butler) Date: Sat Jan 12 13:11:29 2008 Subject: [Liblas-devel] liblas Message-ID: <1AEDE52D-D94A-4D04-BA43-D88E4F9034FF@gmail.com> Martin, I am writing you to give you an update of where things are and hope to persuade you to join the liblas-devel list so we can benefit from your expertise and experience. The first developments I will mention are that we took the lastools stuff, imported it into subversion, and then added some automake, msvc projects, and msvc makefiles to it. This can be found at http://liblas.org/browser/tags/original (or http://liblas.org/svn/tags/original for the svn version). After polishing things a little bit, we started in on reworking the reader class to use a pimpl approach http://mail.hobu.net/pipermail/liblas-devel/2007-December/000008.html We are currently in the process of fleshing out the pimpl-based reader. Two other developers besides myself are working on the library (Mateusz Loskot and Phil Vachon). We all are heavily involved with the GDAL http://www.gdal.org project, and we have various expertise in different areas of the project. For liblas, Mateusz is focused on the C++ implementation, I am focused on C API development (and a Python API) and porting your utilities to use that, and Phil is focused on SAR-related usages. We've been attempting to pull together as much LAS format-related stuff onto the wiki at liblas.org as we can in an attempt to congeal the format oriented stuff in one place. All of the articles and code are so scattered that it is challenging for someone not initiated to figure out what to do and where to go. Hopefully with enough linkage and information, the liblas wiki will end up being a highly ranked website and simple searches will point people to it and they can find what they are looking for. Finally, I know you are an extremely busy academic (my wife is a professor, so I understand the lifestyle ;) ), but I would implore you to join the liblas-devel mailing list. Your experience with the LAS specifications (and their sometimes lack of specificity) would be extremely helpful to us. We are more software development-oriented folks, and while we can dig, scratch, and claw our way to LAS format zen, imparted experience from a LAS format zen master would be highly beneficial. liblas is an opportunity for you to provide some minimal direction toward a gold-plated 2.0 version of your library. Below is a list of things we would love some direction on: - What should the API look like? We know fairly well how we would use a LAS API from a direct data format translation perspective, but how would someone expect to use the library if they were building applications atop it directly? Your experience with integrating lastools into your applications can provide us some direction here. Should we just make a straight port of what you outlined (plus some more sophisticated error handling, etc), or were there things you would have like to have had but didn't have the time to do (more convenience, syntactical sugar, alternative access methods, etc)? - In the face of ambiguity from the 1.0 and 1.1 specifications, what choices are people typically making? For example, scan angle rank is defined as unsigned byte from -90 to +90 in the 1.0 specification and as just unsigned byte in the 1.1 specification. Does this mean it is still +90/-90 in 1.1, even though it is not clearly specified, is it merely a convention for 1.1, and so on. - All three of us are very skeptical about the LAS 2.0 specification, and you had expressed some displeasure about it as well. What are some things we can do at the library level with an eye toward supporting it at some point in the future? Or rather, what things can we do to support the expected most common usages of 2.0 LAS data? My feeling is that LAS 2.0 is so wide open that LAS 2.0 from one vendor is going to be different than LAS 2.0 from another. What's your feeling on the subject? A last related point is development specific. If you are interested in participating from a software development perspective, please let me know, and I will provide you with a login that you can use on liblas.org to commit to the subversion repository and make additions/ changes on the wiki pages, file tickets, etc. Thanks for your time, and we look forward to hearing from you. Howard