Comments (20)
Class 19 has been reserved for Overhead Structure
in R14 (#26). I'm considering that discussion closed and off-topic in this thread.
I haven't seen further discussion for classes 20-22 except to note that they have been added to the USGS LBS 1.3 as follows:
- 20 β Ignored Ground (typically breakline proximity)
- 21 β Snow (if present and identifiable)
- 22 β Temporal Exclusion (typically nonfavored data in intertidal zones)
Is there any reason not to integrate these into the LAS 1.4 specification to keep the two in sync? @jdnimetz @jstoker74 @gadomski
from las.
From Karl:
Based on prior communications I have had with Lewis, I have included 20-22 in the USGS LBS v13, which is still in Draft review.
If there is any uncertainty about the use of these class codes as Lewis has noted, I need to know immediately, as we do not want the LBS to contradict the LAS specification.
from las.
Up for discussion: Is this the sort of change we are willing to incorporate as a revision, or should classes only be dedicated in major/minor version updates (i.e., 1.5/2.0)?
from las.
I think a revision will do as long as the newly defined classes do not override any previous definition.
from las.
If snow is being added, it might make sense to add ice as well? Many users who care about snow classifications also care about ice and discriminating between the two. This suggestion comes from @jsdeems of NSIDC, who deals with and use a lot of snow+ice point clouds and works with many other people who do as well.
from las.
@gadomski Intriguing request. Is there a class that multiple parties have been using for Ice?
from las.
Not that I know of, but @jsdeems knows more than I do. I'll check with him when he gets back from his ski trip (I don't know if he checks Github) and let you know if he has a suggestion.
from las.
I see no reason not to integrate these classes into LAS 1.4 spec., but Iβm biased π
FWIW, there are no plans to change definition for these three classes within the 3DEP LBS.
from las.
Indeed, it would help to include classes 20-22 π
from las.
PDF with Classes 20-21 added: https://s3.amazonaws.com/asprs-las/LAS-specification-1abcef858b913371d3caf987e97297122a664916.pdf
from las.
Thank you Evon :) Would you please also add
22 β Temporal Exclusion
Also, are there any immediate objections to adding the following classes:
40 Bathymetric bottom / Bathymetric point /Submerged topography / Seafloor or riverbed
41 Water surface
42 Derived water surface /synthetic
43 Submerged object (unspecified)
44 International Hydrographic Organization object (unspecified)
45 Water column /No bottom found at bathy point/ Neither surface nor bottom
From my (subjective) perspective it would be helpful to have these classes formally standardized. Please let me know :)
from las.
from las.
I definitely concur with adding/formalizing topo-bathy domain profile classes 40-45, as defined in Milena's post, and 46, as defined by Kirk. I'm not quite sure what 22 (temporal exclusion) is. Would this refer to a point excluded, due to being inside or outside a defined time window?
from las.
a) Kirk, I see your point, I think class 46 (submerged aquatic vegetation) would be a useful addition.
b) Does anyone have any preferences in terms of naming classes 40-45?
c) Within the USGS specification class 22 is currently defined as "typically nonfavored data in intertidal zones (https://pubs.usgs.gov/tm/11b4/pdf/tm11-B4.pdf p. 24)". However, it seems that, in some cases, folks also used it to signify temporal difference within a floodplain, or to call attention to an area where, during the data collection, a significant event resulted in an elevation difference (with the most recent data within the identified area being used). Josh, please comment if this interpretation is incorrect.
from las.
@milenajaniec That's how we've used Temporal Exclusion (22) in the past. For example, a water surface might get moved to this class if a later survey recorded it at a different height. Or the old ground surface might get classed 22 if it experienced a landslide between two acquisition dates.
Basically, the idea is that it captures terrain features that did exist but we have reason to believe no longer exists in their prior position, and removing them significantly improves the ground model.
Regarding incorporating the topobathy LDP classes, I'm reluctant to formalize classifications that only serve a single domain. I know there's already some reserved classifications for the utility sector, but I think that was a mistake and it's too late for me to change it. I'd rather promote usage of LDPs.
I acknowledge that the topobathy LDP is badly in need of updating. Personally, I think that's a separate issue. I haven't figured out yet what the best publication method for that will be (wiki, standalone PDF, LAS spec).
from las.
@esilvia I understand your reluctance; however, since we are receiving an increased number of the topo-bathymetric projects, it would be worth to accommodate them somehow in the revision. Currently, the classification seems to be open. It would be helpful if we could standardize it. Especially, since we are already making changes. We could endeavor to formally incorporate the above-mentioned classes (which are already in use) at the same time.
from las.
It sounds like we're all in favor of the addition of Temporal Exclusion (class 22), so I'll integrate that as a pull request. One question I wasn't sure about... is Temporal Exclusion only for ground points that are being excluded, or is it for any features? I believe that ground is the norm, but I'm not sure.
It didn't make sense to me to include the parentheticals from the LBS in the class names, so I added a Notes column for PDRF 6 like this:
If there are no objections, I'll close this issue.
Finally, I've migrated the topobathy LDP class discussion over to #72 and limited this issue to 19-22 since we seem to be agreed on those. Perhaps the topobathy classes can be part of R15. Hope that doesn't cause too much confusion.
from las.
Closed with #73
from las.
from las.
Removing non-permanent objects is one possibility, but it was intended more for terrain features that changed over time. Consider the following:
- Flightlines 1012-1014 collected in January on a hillside.
- Landslide in February.
- Adjacent flightlines 1015-1020 collected in March.
So now the terrain within the project area has changed. What do you do with the ground from 1012-1014 that no longer exists as a result of the landslide in February? You don't want to switch it to class 1 because that'd make it look like vegetation, but you don't want it to be class 2 because it no longer exists.
The idea is that you'd select the set of terrain you're interested in and use the standard classes, then classify the other terrain to 22 as Temporal Exclusion. Most of the time the January (older) flight would end up as Class 22 and the newer flight would be kept in the standard classes.
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.