Comments (8)
A while back we had an extensive discussion in LASroom regarding the data types of min
, max
, and nodata
in the EXTRA_BYTES
structure:
https://groups.google.com/d/msg/lasroom/thdrEOeAUvc/rpS7dDDNAwAJ
(note: this post also includes some discussion history regarding #1)
In it we concluded that min
and max
should both be type double
instead of anydata
, whereas the type of nodata
should match the up-cast version of the data itself. The reasoning was as follows:
- Using a
double
for min-max here would be consistent with the usage in the LAS header for XYZ min/max values. That is, ExtraByte min/max values should not require the application of the scale and offset to retrieve the actual value and are therefore the transformed values. nodata
values must remain byte-compatible with the raw data, which requires that no mathematical operations (i.e., scale and offset) should be applied. For example, for an extrabyte descriptor of an unsigned short integer, NODATA value of 65535, and scale value of 0.001, thenodata
value stored in the descriptor should be 65535 and not its transformed value, 65.535.
I intend to proceed for R14 as if that decision still stands, but I'll leave this open for a couple days in case there's further discussion required.
from las.
It seems the "most popular" implementation of Extra Bytes (namely the RIEGL exporter) does not use floats but follows the current specification (see this white paper).
from las.
Where do you see that? As far as I can tell, most implementations seem to store a 64-bit double
.
from las.
@manfred-brands correctly pointed out in #76 that because this has already been implemented in existing software packages, we can't change the data type for the existing ExtraByte min/max VLR, regardless of the original intent or what "makes sense" moving forward. This change will be deferred to LAS 1.5, probably as a part of #37 or a future alternative ExtraByte definition.
@rapidlasso Do I correctly understand that the min/max should actually be an untransformed value? If so, I'll add a new commit with that clarification.
from las.
Unfortunately all the "extra bytes" discussions happened long before the LWG adopted the record keeping and the decision-making transparency of usual standardization bodies. I will have to dig up the email threads from 2010 / 2011 to see who (most likely me) decided on the design of the min/max values and what the intended meaning is. I seem to remember yes, the untransformed values. @lgraham-geocue or @hobu may also still have those cc-ed email discussion threads. I'll get back to you on that if they don't, but now it's happy hour time here in Costa Rica ... (-;
from las.
I went back through my emails. On Aug 25, 2011, I proposed to the LWG via email the following:
"The LAS format already allows to store n "extra bytes" for every LAS point simply by specifying a point size in the LAS header that is n bytes larger than minimally required by the point type. These extra bytes can be used to store user specific data. I am proposing an "Extra Bytes" LASF_Spec VLR (see attached PDF) that users can use to - optionally - describe these "extra bytes".
This could also be seen as first step towards a self-describing LAS format. It will provide us a with a no-cost real-world “test-run” for self-describing content that is completely risk-free but will give us user feedback and insights for designing LAS 2.0."
This was sent to LWG chair Lewis Graham (GeoCue) and cc-ed to Howard Butler (Hobu Inc.), Michael Watry (Qcoherent), Paul Conrad (Optech), Paul Galla (LeicaUS), Jim van Rens (RIEGL), Arttu Soininen (Terrasolid), Ramesh Sridharan (Virtual Geomatics), Michael Umansky (Applied Imagery), Randy Rhoads (Network Mapping),,Andre Koestli (Trimble), Craig Glennie (University of Houston), Michael Rosen (Lizardtech), Karl Heidemann (USGS), and Wanning Peng (ESRI).
from las.
A few months later, on Nov 12, 2011, after lots of private email exchanges with various parties, including Howard Butler (Hobu Inc), Gottfried Mandelburger (TU Vienna), and others I sent a revised document by private email to Lewis Graham that he then integrated into the then current revision of the evolving LAS 1.4 draft (R10 from 11 November 2011) to produce the next revision (R11 from 12 November 2011). I was able to find all these documents for some "extra bytes" VLR history:
LAS 1 4 - Extra Bytes Update.docx
from las.
@rapidlasso Thanks Martin! I think that confirms my suspicion that the min/max should match the raw data_type
but upcast to 8 bytes. I modified this comment to §4.3 as follows:
Interesting that your original proposal for the ExtraBytes as singles (not triples) matches where we ended up after all.
from las.
Related Issues (20)
- Investigate ReadTheDocs to replace ad-hoc Sphinx implementation
- Standard System Identifiers downloads contain incorrect informat HOT 1
- List of all recognized LAS classes HOT 2
- Reserve LASF_Projection:4224 for 1.5 WKT2 HOT 2
- Detailed change documents for LAS 1.1 & 1.2 HOT 2
- Fully deprecate PDRFs 0-5 for LAS 1.5 HOT 10
- Epoch description support for 1.5 HOT 3
- Update spec links to permalinks
- Editorial updates for LAS 1.5
- Using LASZIP and requirement to set “Reserved” value to Zero(0) HOT 7
- Ambiguity of Creation Day of Year and Creation Year HOT 8
- Various Kinds of Point Clouds HOT 3
- Update OGC LAS community standard
- Add an optional MIME types VLR that describes other VLRs in the file HOT 1
- Clarify specification of X, Y, and Z Scale Factors HOT 4
- Clarification about backwards compatibility HOT 1
- Add External Standards VLR HOT 1
- Clarification about File Creation Day of Year HOT 2
- General question about undocumented extra bytes HOT 6
- Is it valid to have several extrabytes VLR? HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from las.