Towards Efficient Implementation of an Octree for a Large 3D Point Cloud

sensors

Article Towards Efﬁcient Implementation of an Octree for a Large 3D Point Cloud

Soohee Han Department of Geoinformatics Engineering, Kyungil University, Gyeongsan 38428, Korea; [email protected]

Received: 22 October 2018; Accepted: 11 December 2018; Published: 12 December 2018

Abstract: The present study introduces an efficient algorithm to construct a file-based octree for a large 3D point cloud. However, the algorithm was very slow compared with a memory-based approach, and got even worse when using a 3D point cloud scanned in longish objects like tunnels and corridors. The defects were addressed by implementing a semi-isometric octree group. The approach implements several semi-isometric octrees in a group, which tightly covers the 3D point cloud, though each octree along with its leaf node still maintains an isometric shape. The proposed approach was tested using three 3D point clouds captured in a long tunnel and a short tunnel by a terrestrial laser scanner, and in an urban area by an airborne laser scanner. The experimental results showed that the performance of the semi-isometric approach was not worse than a memory-based approach, and quite a lot better than a file-based one. Thus, it was proven that the proposed semi-isometric approach achieves a good balance between query performance and memory efficiency. In conclusion, if given enough main memory and using a moderately sized 3D point cloud, a memory-based approach is preferable. When the 3D point cloud is larger than the main memory, a file-based approach seems to be the inevitable choice, however, the semi-isometric approach is the better option.

Keywords: octree; 3D point cloud; terrestrial laser scanning; memory-based octree; ﬁle-based octree

1. Introduction Advances in 3D terrestrial laser scanning technology and its various applications have increased the size of 3D point clouds enormously. Unlike elements stored in conventional spatial database management systems (SDBMS), a 3D point cloud has even more entities—points, up to billions in number, however, each entity is not topologically related to the others. Thus, it is necessary to use relevant methods to handle the data. The methods can be categorized into two: lossy compression or abbreviation, and lossless indexing. The former category eliminates less meaningful points from the 3D point cloud. Several relevant approaches have reported that the reduced data still exhibits consistent results with half or even less point density [1–3]. The latter category retains and uses the original coordinate information of all points, and then uses special data structures to store and retrieve the data efficiently. For example, as a dynamic partitioning algorithm, R-tree is commonly utilized in SDBMS with its derivatives, and might be applicable for this purpose. However, R-tree is based on minimum bounding rectangles (MBR) and points are apt to be enclosed by overlapping nodes, making it a poor solution [4]. K-d tree, which is also a dynamic partitioning algorithm is more efficient and has been officially implemented in the point cloud library (PCL) [5]. However, in the worst case, all of the child nodes should be retrieved to traverse from a node to its child node where the 3D boundary satisfies a positional query [6]. Thus, a large 3D point cloud necessitates proper methods to re-organize or index itself efficiently. Among the known methods, octree is popular for its memory efficiency, query speed and structural simplicity [7]. In octree, only one child node in each depth is traversed because the 3D boundary of each node is implicitly known by positional query. Thus, a leaf node can be advantageously retrieved in this approach. Octree is now being exploited by a number of

Sensors 2018, 18, 4398; doi:10.3390/s18124398 www.mdpi.com/journal/sensors Sensors 2018, 18, 4398 2 of 14 applications for segmentation and visualization of 3D point clouds [8–14], and also in PCL. However, octree, as a static partitioning algorithm, has a potential weakness, that is, memory waste because eight child nodes are always declared, even when not all of them bear point(s) within themselves. To address this weakness, a schema was presented to avoid declaration of child nodes that bear no points, and to terminate subdivision if the number of points goes below a threshold after further subdivision [15,16]. A memory efficient encoding method was also employed to minimize the size of a node in octree. The present study uses a native octree, which means that derivations of octree, as introduced in the relevant approaches [15,16] are not considered. Instead, it deals with other issues that influence the performance of octree. These include how to make a compact node in a native octree, how to design functions (methods) applicable to the node, where to store and retrieve the 3D point cloud itself (main memory or HDD), and what the shape of octree should be. From preliminary tests, several influencing factors were found: 1) the size of a node is very flexible but does not have much influence on query speed, and 2) dynamic declaration of nodes in the octree construction process claims more memory than expected, thus, array declaration is preferable after a pseudo octree construction [17]. The present study is based on the array-based approach and this will not be further mentioned in this paper. The paper is structured as follows: implementation of a compact node and relevant methods are outlined in Section 2.1.1, implementation of a file-based octree to reduce main memory usage is described in Section 2.1.2, more efforts to enhance the performance of octree are discussed in Sections 2.1.3 and 2.1.4, and its application is shown in Section 2.2. Results along with the discussion and conclusions follow in Sections3 and4.

2. Material and Methods

2.1. Algorithm Development

2.1.1. Implementation of Octree for a 3D Point Cloud An octree is defined as a tree data structure in which each internal node has exactly eight children, where a three dimensional space is created by recursively subdividing it into eight octants [18]. To index a 3D point cloud using octree the 3D boundary is divided into eight octants, which are further subdivided recursively only when they bear point(s) within themselves until the sequence reaches a given threshold value, namely depth. The final subdivision results in eight leaf nodes that store points within their archives. In the present study, the basic steps used to implement octree from a 3D point cloud were: 1. An axially-aligned minimum bounding hexahedron (hereafter, MBH) is defined to tightly enclose the whole 3D point cloud and assigned to a head node. 2. Eight new MBHs are defined by halving the MBH along the x-, y- and z-axes, and are assigned to eight child nodes. 3. A child node, of which MBH encloses an input point, is chosen and the input point is passed over a child node in further depth. 4. Step 2 and Step 3 are continued until the depth reaches a given threshold value (hereafter, Depth) and the final child node (hereafter, the leaf node) stores the input point. 5. Every point in the 3D point cloud is assigned to the head node and undergoes Step 2 to Step 4. A larger Depth creates more subdivision and allows leaf nodes to have fewer points, and a smaller Depth has the opposite effect. Having fewer points in a leaf node reduces computational overhead in point retrieval, but also increases the traversing route from head to leaf node. Thus, Depth should be experimentally adjusted to minimize the overall point retrieval time. Pseudo codes to implement the steps in C++ language based on the standard template library (STL) are given in Figure1. The Addpoint method selects a child node of which octant encloses an input point, and updates the MBH of the selected child node. The input point is recursively passed over selected child nodes until the depth of the current node (curDepth) equals the final depth (finalDepth). Sensors 2018, 18, x FOR PEER REVIEW 3 of 14 SensorsSensors 20182018,, 1818,, 4398x FOR PEER REVIEW 33 of 1414 (finalDepth). The final selected leaf node pushes back the pointer (pt) of the input point to a vector archive(finalDepth). (pVector). The finalThe GetPointListselected leaf nodemethod pushes recursively back the retrieves pointer child (pt) ofnodes the inputenclosing point the to positiona vector Theofarchive interest final (pVector). selected by a similar leaf The node mechanism,GetPointList pushes back and method the points pointer recursively can (pt)be retrieved of retrieves the input from child point the nodes topVector a vector enclosing of archive the selectedthe (pVector). position leaf Thenode.of interest GetPointList The sizeby a ofsimilar method the node mechanism, recursively class in Figureand retrieves points 1 is child detcanermined nodesbe retrieved enclosing by the from type the the positionof pVectorvariable of interest ofused the inselected by the a similar MBH. leaf mechanism,Thenode. size The of size CNode and of pointsthe is 60node canbytes class be (= retrieved inmbh(6 Figure × from8 1 bytes) is det the ermined+ pVector curDepth(4 by of thethe bytes) selectedtype +of pVector(4 variable leaf node. usedbytes) The in + size the pChild(4 ofMBH. the nodebytes))The size class using of inCNode Figuredouble is1 precision60is determinedbytes (= or mbh(6 36 bybytes the× 8 (=mbh(6 typebytes) of + variable curDepth(4× 4 bytes) used + bytes)depth(4 in the + MBH. pVector(4bytes) The + pVector(4 sizebytes) of + CNode pChild(4 bytes) is + 60pChild(4bytes)) bytes using (= bytes)) mbh(6 double using× 8 precision bytes)single +precision. curDepth(4or 36 bytes In both bytes)(=mbh(6 cases, + pVector(4 × a4 greatbytes) deal bytes) + depth(4 of +memory pChild(4 bytes) is bytes))required+ pVector(4 using during bytes) double tree + precisionconstruction—estimatedpChild(4 orbytes)) 36 bytes using (=mbh(6 single to be precision.× up4 bytes) to 60 In + depth(4both 8 orcases, 36 bytes) a great 8 + pVector(4bytes deal afterof memory bytes) n-subdivisions, + is pChild(4 required bytes))in during the usingworst tree singlecase.construction—estimated precision. In both cases, to be a greatup to deal 60 of 8 memory or 36 is required 8 bytesduring after n-subdivisions, tree construction—estimated in the worst n n tocase. be up to 60 × 8 or 36 × 8 bytes after n-subdivisions, in the worst case.

Figure 1. Pseudo codes of a basic form CNode. FigureFigure 1.1. Pseudo codescodes ofof aa basicbasic formform CNode.CNode. To reduce the size of a node class, most of the variables are omitted and the methods are revised to passToTo reducethereduce necessary thethe sizesize parameters ofof aa nodenode class,class, over most mostto the ofof ch thetheild variablesvariables nodes. A areare compact omittedomitted form andand theofthe a methods node class are declares revisedrevised toonlyto passpass a variable thethe necessarynecessary pChild, parametersparameters as shown in overover Figure toto thethe 2. A childch voidild nodes.nodes. pointer AA pChild compactcompact can formform designate ofof aa nodenode both classclass a child declaresdeclares node onlyinonly a normal aa variablevariable node pChild,pChild, and a as asvector shownshown instance inin FigureFigure in 2a 2.. leaf A A void void node. pointer pointer The AddPoint pChild pChild can can and designate designate GetPointList both both a methodsa child child node node are inrevisedin aa normalnormal accordingly nodenode andand to aa pass vectorvector over instanceinstance more inparameters,in aa leafleaf node.node. as TheTheshown AddPointAddPoint in Figure andand 3. GetPointListGetPointList AddPoint selects methodsmethods a child areare revisednoderevised by accordinglyaccordingly using the 3D to to passcoordinates pass over over more more of parameters,an parameters, input po asint shown asand shown calculates in Figure in Figure 3a. new AddPoint 3. MBHAddPoint selectsfor a selectsselected a child a nodechild bynode using inby furtherusing the 3D the depth. coordinates 3D coordinatesThe new of an MBH, inputof an along input point with andpoint Depth calculates and calculatesand athe new input a MBH new point, MBH for a are selectedfor passed a selected child over nodechild to a inchildnode further innode further depth. recursively depth. The new Theuntil MBH,new a leaf MBH, along node along with is reached Depthwith Depth and in which the and input the an input point,input point, arepoint passed areis stored. passed over toLikewise,over a child to a nodeGetPointListchild recursivelynode recursively operates until ausing leafuntil node aa similar leaf is reachednode mechanism, is in reached which however anin inputwhich it point selectsan input is stored.a child point Likewise,node is stored. not GetPointListby Likewise,an input operatespointGetPointList but using by operatesa aposition similar using mechanism,of interest a similar and however mechanism, passes it an selects howeveradditional a child it parameterselects node not a child by(ptlist) an node input over not point to by obtain an but input by the a positionqueriedpoint but ofresults. by interest a positionEither and passesway, of interest the an additionalsize and of apasses node parameter anis reducedadditional (ptlist) to over theparameter to size obtain of (ptlist)a the pointer queried over which results.to obtain occupies Either the way,8queried bytes the in sizeresults. 64-bit of a system.Either node isway, reduced the size to the of sizea node of a pointeris reduced which to the occupies size of 8 bytesa pointer in 64-bit which system. occupies 8 bytes in 64-bit system.

Figure 2. Pseudo codes of a compact form CNode. Figure 2. Pseudo codes of a compact form CNode.

Sensors 2018, 18, 4398 4 of 14 SensorsSensors 2018, 18 2018, x FOR, 18, xPEER FOR REVIEWPEER REVIEW 4 of 144 of 14

FigureFigureFigure 3. Pseudo 3.3. PseudoPseudo codes codescodes of the ofof AddPoint thethe AddPointAddPoint and GetPointList andand GetPointListGetPointList methods. methods.methods.

2.1.2.2.1.2.2.1.2. Implementation ImplementationImplementation of File-Based ofof File-BasedFile-Based Octree OctreeOctree The TheperformanceThe performanceperformance of an ofof octree anan octreeoctree is strongly isis stronglystrongly influenced influencedinfluenced by the byby media thethe mediamedia where wherewhere the 3D thethe point 3D3D pointpoint cloud cloudcloud practicallypracticallypractically exists. exists.exists. For theFor bestthe bestperformance, performance, the 3D the point 3D point cloud cloud should shouldshould be loaded bebe loadedloaded into intotheinto main thethe mainmain memorymemorymemory and stored and stored in an inarray in an an array of array Point3D of of Point3D Point3D struct, struct, as struct, in asFigure asin Figure in 1. Figure A pointer 1. A1. pointer A to pointer the to struct, the to struct, the instead struct, instead of insteadthe of the 3D coordinatesof3D the coordinates 3D coordinatesthemselves themselves should themselves should be put shouldbe into put the into be he putthead he intonodead the nodeand head passed and nodepassed over and toover the passed to child the over childnodes to nodes until the child until it cannodesit be can stored be until stored in it cana leaf in be a node. leaf stored node. However, in a However, leaf node.the 3D the However, point 3D point cloud the cloud itself 3D point itselfrequires cloudrequires a great itself a great requiresdeal ofdeal memory— a of great memory— deal of sometimesmemory—sometimessometimes more more than thanthe main more the main thanmemo thememory. main Tory. avoid memory.To avoid defects, Todefects, avoid octree octree defects, can be can octreeconstructed be constructed can be based constructed based on file- on based file- pointersonpointers file-pointers which which directly whichdirectly refer directly referto 3D to referpoints 3D points to stored 3D pointsstored in a storedhardin a harddisk in a drivedisk hard drive disk(HDD) drive(HDD) or a (HDD) solid-stateor a solid-state or a solid-statedrive drive (SSD).drive(SSD). The (SSD). AddPointThe AddPoint TheAddPoint method method is method revised is revised is to revised pass to passover to pass overa new over a new afile-pointer new file-pointer file-pointer (pos) (pos) which (pos) which which refers refers refers to the to thethe addressaddressaddress of an of ofinput anan inputinput point point point in an in inHDD an an HDD HDD or a orSSD or a a SSD andSSD andis and finally is is finally finally stored stored stored to a toleaf to a a leafnode, leaf node, node, as shown as as shown shown in Figures in in Figures Figures 4 4 andand4 5.and 5GetPointList. GetPointList5. GetPointList is also is is also revisedalso revised revised to substitute to to substitute substitute a new a newa parameternew parameter parameter (poslist) (poslist) (poslist) for an for for old an an oldone old one(ptlist) one (ptlist) (ptlist) to to to obtainobtainobtain the queried thethe queriedqueried results resultsresults in the inin file-pointer thethe file-pointerfile-pointer format. format.format.

FigureFigureFigure 4. Pseudo 4.4. Pseudo codes codescodes of a revised ofof aa revisedrevised form formCNodeform CNodeCNode using using usinga file-pointer. aa ﬁle-pointer.file-pointer.

Sensors 2018, 18, 4398 5 of 14 Sensors 2018, 18, x FOR PEER REVIEW 5 of 14 Sensors 2018, 18, x FOR PEER REVIEW 5 of 14

Figure 5. Pseudo codes of the revised AddPoint and GetPointList methods. Figure 5. Pseudo codes of the revised AddPoint and GetPointList methods. Figure 5. Pseudo codes of the revised AddPoint and GetPointList methods. The Theformer former method, method, hereafter hereafter referred referred to toas asthe the memory-based memory-based method, method, is is enormously fasterfaster than The former method, hereafter referred to as the memory-based method, is enormously faster thanthe the latter, latter, hereafter hereafter referred referred to to as as the the file-based file-based method, method, during during octree-construction octree-construction and and point-retrieval. point- than the latter, hereafter referred to as the file-based method, during octree-construction and point- retrieval.The latter The latter can save can save the main the main memory memory by omitting by omitting loading loading of the of 3D the point 3D point cloud cloud to the to main the main memory, retrieval. The latter can save the main memory by omitting loading of the 3D point cloud to the main memory,thus, thus, it is applicable it is applicable when when the size the of size the of 3D th pointe 3D point cloud cloud is larger is larger than thethan main the main memory. memory. However, memory, thus, it is applicable when the size of the 3D point cloud is larger than the main memory. However,the average the average time to time retrieve to retrieve arbitrary arbitrary data using data ausing file-pointer a file-pointer in an HDD in an is HDD 100 times is 100 slower times than However, the average time to retrieve arbitrary data using a file-pointer in an HDD is 100 times slowerusing than a normalusing a normal pointer pointer in the main in the memory. main memory. This means This thatmeans the that file-based the file-based method method may suffer may from slower than using a normal pointer in the main memory. This means that the file-based method may sufferslow from octree-construction slow octree-construction and point-retrieval and point-retrieval speed. Nevertheless, speed. Nevertheless, the file-based the file-based approach approach is preferable suffer from slow octree-construction and point-retrieval speed. Nevertheless, the file-based approach is preferablebecause itbecause can expand it can theexpand volume the ofvolume the 3D of point the 3D cloud point to cloud be indexed to be inindexed an octree. in an octree. is preferable because it can expand the volume of the 3D point cloud to be indexed in an octree. 2.1.3.2.1.3. Implementation Implementation of an of Anisometric an Anisometric Octree Octree 2.1.3. Implementation of an Anisometric Octree An octreeAn octree is commonly is commonly implemented implemented in an isometric in an isometric shape; that shape; is, the that MBH is, theof an MBH octree of is an cubic- octree is shapedcubic-shaped regardlessAn octree regardless ofis commonlythe original of the implemented shape original of shapethe in 3Dan of isometricpoint the 3D cloud. point shape; cloud.If thethat 3D Ifis, the thepoint 3DMBH pointcloud of an cloud is octree severely is severelyis cubic- imbalancedimbalancedshaped inregardless the in x the-, yx- -,andofy -the andz-axes, originalz-axes, it is itshapepreferable is preferable of the to tightly3D to tightlypoint fit the fitcloud. the MBH MBHIf tothe tothe 3D the point point point cloud. cloud cloud. As is As seen severely seen in in FigureFigureimbalanced 6a,6a, an an isometric in isometric the x-, implemen y- implementation and z-axes,tation it ofis ofoctreepreferable octree to cover to to cover tightly an anov al-shapedfi oval-shapedt the MBH 3D to 3Dpoint the point pointcloud cloud cloud. can canyield As yield seen emptyemptyin nodes.Figure nodes. Point6a, an Point concentrationisometric concentration implemen in fewer intation fewer nodes of nodes octree results results to in cover load-unbalance in load-unbalancean oval-shaped and 3D andquery point query performance cloud performance can yield degradation.degradation.empty nodes. To avoid To Point avoid this concentration defect, this defect, an octree an in octree fewer can be cannodes implemented be implementedresults in in load-unbalance an in anisometric an anisometric andshape query shape in which performance in which the the pointspointsdegradation. are better are better distributed To distributedavoid this to more defect, to more nodes an nodesoctree (Figure (Figurecan 6b). be 6implemented b). in an anisometric shape in which the points are better distributed to more nodes (Figure 6b).

FigureFigure 6. Comparison 6. Comparison of octrees: of octrees: (a) an ( aisometric) an isometric octree; octree; (b) an (b anisometric) an anisometric octree. octree. Figure 6. Comparison of octrees: (a) an isometric octree; (b) an anisometric octree. However, even an anisometric octree can have a negative effect on point retrieval performance. This is becauseHowever, a leaf even node an inherits anisometric the shape octree of canan octree, have a and negative an anisometric effect on point leaf can retrieval increase performance. query overheads.This is Forbecause example, a leaf ifnode we inheritsretrieve the points shape within of an aoctree, distance and froman anisometric a position leaf of interestcan increase in an query overheads. For example, if we retrieve points within a distance from a position of interest in an

Sensors 2018, 18, 4398 6 of 14

However, even an anisometric octree can have a negative effect on point retrieval performance. This is because a leaf node inherits the shape of an octree, and an anisometric leaf can increase query Sensors 2018, 18, x FOR PEER REVIEW 6 of 14 overheads. For example, if we retrieve points within a distance from a position of interest in an isometricisometric octree,octree, fourfour leavesleaves areare queriedqueried andand fourfour pointspoints areare examinedexamined (Figure(Figure7 7a).a). In In an an anisometric anisometric octree,octree, fourfour leavesleaves areare alsoalso queriedqueried butbut eighteight pointspoints areare examined,examined, causingcausing doubledouble queryquery overheadoverhead (Figure(Figure7 b).7b). AsAs notednoted earlier,earlier,point pointquery queryis is very very slow slow in in a a ﬁle-based file-based octree, octree, and and query query increment increment resultsresults inin severesevere performanceperformance degradation.degradation.

FigureFigure 7.7. ComparisonComparison ofof leafleaf nodes:nodes: (aa)) inin anan isometricisometric octree;octree; ((bb)) inin anan anisometricanisometric octree.octree.

2.1.4.2.1.4. ImplementationImplementation ofof aa Semi-IsometricSemi-Isometric OctreeOctree GroupGroup TheThe tradeofftradeoff betweenbetween isometricisometric andand anisometricanisometric octreesoctrees cancan bebe complementedcomplemented byby implementingimplementing anan isometricisometric octreeoctree group. group. An An isometric isometric octree octree group grou isp composedis composed of isometricof isometric octrees octrees which which cover cover the 3Dthe point3D point cloud cloud tightly, tightly, but eachbut each octree octree along along with with its leaf its nodeleaf node still maintainsstill maintains an isometric an isometric shape. shape. For example,For example, the octreethe octree group group in Figure in Figure8a resembles 8a resemble thes anisometricthe anisometric octree octree shown shown in Figure in Figure6b, but 6b, itsbut leafits leaf nodes nodes resemble resemble those those of the of the isometric isometric octree octree in Figure in Figure7a. 7a. AnAn isometricisometric octreeoctree groupgroup isis preferablepreferable toto achieveachieve betterbetter performanceperformance inin pointpoint retrieval.retrieval. InIn mostmost cases,cases, however,however, a a perfect perfect isometric isometric octree octree group group is is not not possible possible because because the the length length of of the the larger larger axis axis of theof the MBH MBH is notis not always always an an integer integer multiplication multiplication of of minor minor one. one. Even Even if if possible, possible, an an isometricisometric octreeoctree groupgroup suchsuch asas inin FigureFigure8 8aa can can require require three three times times more more memory memory thanthan aa singlesingle octree,octree, asas inin FigureFigure6 6b.b. AsAs anan alternative,alternative, aa semi-isometricsemi-isometric octreeoctree groupgroup isis introducedintroduced inin FigureFigure8 8b.b. It It occupies occupies less less memory memory thanthan anan isometricisometric octreeoctree groupgroup andand performsperforms betterbetter thanthan aa singlesingle anisometricanisometric octree.octree. TheThe shapeshape ofof anan octreeoctree inin a a semi-isometric semi-isometric octree octree group group can can be adjustedbe adjusted by controlling by controlling a threshold a thresholdti which 𝑡is which a number is a notnumber smaller not than smaller one than (Equation one (Equation (1)). (1)). 𝑙 =argmin𝑙 ,𝑙 ,𝑙 , 𝑙 ls = argmin lx, l𝑙y, lz , 𝑙 𝑛 =floor lx ,𝑛 =floor ly ,𝑛 =floorlz nx = floor , ny = floor , nz = floor 𝑡ti𝑙×ls 𝑡ti×𝑙ls ti𝑡× l𝑙s (1) lx𝑙 l𝑙y l𝑙z (1) dx = , dy = , d z = 𝑑 =nx ,𝑑 =ny ,𝑑 = nz 𝑛 𝑛 𝑛 where argmin() gives the minimum value among inputs, lx, ly, lz denote the lengths of the MBH of the 3D point cloud, nx, ny, nz give the numbers of octrees in the octree group, floor() denotes the 𝑙 ,𝑙 ,𝑙 largestwhere argmin( integer number ) gives the not minimum larger than value an input among value, inputs, and dx,dy, d denotez give thethe lengthslengths ofof thethe MBHMBH ofof the 3D point cloud, 𝑛 ,𝑛 ,𝑛 give the numbers of octrees in the octree group, floor() denotes the an octree. One of dx, dy, dz is equal to ls and the others cannot be larger than ls × ti by two times. 𝑑 ,𝑑 ,𝑑 Whenlargestt iinteger= 1, for number example, not itlarger means than that an anyinput axial value, length and of a single give octree the is lengths not two of times the MBH larger of thanan octree. the others One of and 𝑑 the,𝑑 shape,𝑑 is equal of a single to 𝑙 octree and the is others most similar cannot to be an larger isometric than one.𝑙 𝑡 Given by two the times. state ofWhen the computational𝑡 =1, for example, resources, it means a user that can any put axial more length weight of a onsingle memory octree efficiency is not two or times point larger retrieval than performancethe others and by the adjusting shape of the a threshold.single octree is most similar to an isometric one. Given the state of the computational resources, a user can put more weight on memory efficiency or point retrieval performance by adjusting the threshold.

Sensors 2018,, 1818,, 4398x FOR PEER REVIEW 77 of of 14 Sensors 2018, 18, x FOR PEER REVIEW 7 of 14 Sensors 2018, 18, x FOR PEER REVIEW 7 of 14

Figure 8. Comparison of octree groups: (a) an isometric octree group; (b) a semi-isometric octree group.

FigureFigureFigure 8. 8.8. Comparison ComparisonComparison of of octree octree groups: groups: (( aa))) anan an isometric isometric octree octree group; group;group; ( (b(bb)) )a aa semi-isometric semi-isometricsemi-isometric octree octree octree group. group. group. 2.2. Application to Real Point Clouds 2.2. Application to Real Point Clouds 2.2.2.2. ApplicationThe Application three to approaches—memory-basedto Real Real Point Point Clouds Clouds octree, file-based octree, and semi-isometric octree The three approaches—memory-based octree, file-based octree, and semi-isometric octree groups— groups—wereTheThe three three implemented approaches—memory-based approaches—memory-based using three 3D point octree, clouds ffile-basedile-based captured octree,octree, in a long andand tunnel semi-isometric semi-isometric (Figure 9), octree aoctree short were implemented using three 3D point clouds captured in a long tunnel (Figure9), a short tunnel tunnelgroups—weregroups—were (Figure implemented10), implemented and an urban using using area threethree (Figure 3D3D point 11), cloudsrespectively. capturedcaptured The in in firsta a long long and tunnel tunnel second (Figure (Figure 3D point 9), 9), a shortaclouds short (Figureweretunneltunnel captured (Figure 10 (Figure), and 10),by 10), an terrestrial and urbanand an an areaurban urban laser (Figure area areascanners, (Figure(Figure 11), respectively.and 11), the respectively. third The by firstan The The airborne and first first second and and laser second second 3D scanner. point 3D 3D point point cloudsThe clouds first clouds were 3D capturedpointwerewere capturedcloud captured by terrestrialwas by by terrestrialcomposed terrestrial laser scanners,laser laserof 300.5 scanners,scanners, and million the and third thepoints bythirdthird anand byby airborne ananoccupied airborne airborne laser 6878laser scanner.laser scanner.MB, scanner. Thethe The first secondThe first 3D first point 3Dhad 3D cloud18.4pointpoint million wascloud cloud composed points was was composedandcomposed of 300.5420 MB, million ofof and 300.5300.5 the points thirdmillionmillion and had occupiedpoints 267.5 millionandand 6878 occupiedoccupied MB, points the secondand 68786878 6122 MB, hadMB, MB. 18.4the the The millionsecond second computing pointshad had andsystem18.418.4 420million million was MB, composedpoints and points the and thirdand of420 420 hada 64-GBMB, MB, 267.5 and and main million thethe memory thirdthird points had and and 267.5 a 6122 512-GB millionmillion MB. SSD. Thepoints points computing More and and 6122detailed 6122 systemMB. MB. specificationsThe The was computing computing composed are ofshownsystemsystem a 64-GB inwas was Tables main composed composed memory1 and 2.of of anda a 64-GB 64-GB a 512-GB mainmain SSD. memorymemory More and detailed aa 512-GB512-GB specifications SSD. SSD. More More aredetailed detailed shown specifications specifications in Tables1 and are are2 . shownshown in in Tables Tables 1 1and and 2. 2.

Figure 9. 3D point cloud of a long tunnel. FigureFigure 9. 3D 9. 3D point point cloud cloud of of a longa long tunnel. tunnel. Figure 9. 3D point cloud of a long tunnel.

Figure 10. 3D point cloud of a short tunnel. FigureFigure 10. 10.3D 3D point point cloud cloud of aof short a short tunnel. tunnel. Figure 10. 3D point cloud of a short tunnel.

Sensors 2018, 18, 4398 8 of 14 Sensors 2018, 18, x FOR PEER REVIEW 8 of 14

Figure 11. 3D point cloud of an urban area. Figure 11. 3D point cloud of an urban area.

Table 1. SpeciﬁcationsSpecifications of data.

DataData 1 1 DataData 2 2 DataData 3 3 C10,C10, Leica ScanScan station station 2 2,, Leica LaserLaser scanner scanner ALTMALTM 3070, 3070, Optech Optech LeicaGeosystems Geosystems LeicaGeosystems Geosystems ScannedScanned object object AA long long tunnel tunnel A Ashort short tunnel tunnel An An urban urban area area ∆x = 569.16 m ∆x = 56.05 m ∆x = 10708.77 m ∆x = 569.16 m ∆x = 56.05 m ∆x = 10708.77 m Dimension ∆y = 1442.58 m ∆y = 25.57 m ∆y = 3380.64 m Dimension ∆y = 1442.58 m ∆y = 25.57 m ∆y = 3380.64 m ∆z = 19.05 m ∆z = 11.98 m ∆z = 290.26 m ∆z = 19.05 m ∆z = 11.98 m ∆z = 290.26 m Number of points 300,525,406 18,376,726 267,490,366 Number of points 300,525,406 18,376,726 267,490,366 Data file size Data ﬁle size 6878 MB 420 MB 6122 MB (in double precision float) 6878 MB 420 MB 6122 MB (in double precision ﬂoat)

Table 2. Specifications of the computing environments. Table 2. Speciﬁcations of the computing environments. Item Description Item Description CPU Intel Core i7-6700K @ 4.00 GHz RAMCPU Intel Core 64.0i7-6700K GB DDR4 @ 4.00 GHz RAM 64.0 GB DDR4 SSD 512 GB SSD 512 GB OS OS Windows Windows 7 64 7 bit64 bit CodingCoding language language C++,C++, compiled compiled inin 64-bit 64-bit release release mode mode in Visual in Visual studio studio 2017 2017

3. Results and Discussion As the long tunnel (Data 1) is 1.5 km long horizontally and only 19 m long long vertically, vertically, the lengths of thethe MBHMBH areare seriously seriously unequal unequal in in the thex-, xy-,- andy- and z-directions z-directions (Table (Table1). Memory-based 1). Memory-based and ﬁle-based and file- octreesbased octrees were constructed were constructed in single in single octrees. octrees. The lengths The lengths in the in x- the and x- y-directions and y-directions of a leaf of a node leaf node were 29.87were 29.87 and 69.97and 69.97 times times larger larger than than in the in the z-direction z-direction (Table (Table3). 3). A A semi-isometric semi-isometric octree octree group group was was implemented usingusing three three thresholds. thresholds. The The group grou wasp composedwas composed of 171 (=of 9 ×17119 ×(=1, 9 threshold × 19 × = 3)1, tothreshold 1711 (= = 29 3) ×to 591711× (=1, 29 threshold × 59 × 1, th =reshold=1) 1) octrees, octrees, where the where ratio the of ratio the x of- tothez -directionx- to z-direction ranged ranged from 3.32from (threshold 3.32 (threshold = 3) to = 3) 1.03 to (threshold1.03 (threshold = 1) (Table= 1) (Table3). On 3). the On contrary, the contrary, the lengths the lengths of the of MBH the MBH of the of shortthe short tunnel tunnel (Data (Data 2) were2) were 56 56 m m and and 26 26 m m horizontally horizontally and and 12 12 m m vertically, vertically, which which areare notnot seriously unequal (Table 1 1).). TheThe lengthlength inin thethe x- and y-directions of a leaf node were only 4.68 and 2.13 times larger, respectively,respectively, thanthan thethe lengthlength inin thethe z-directionz-direction (Table(Table4 4).). A A semi-isometric semi-isometric octreeoctree groupgroup waswas implemented usingusing threethree thresholds thresholds and and the the group group was was composed composed of of 1 (=1 (= 1 × 1 2× ×2 ×1, 1, threshold threshold = = 3) 3) to to 8 8 (= 4 × 2 × 1, threshold = 1) octrees (Table 4). The lengths of the MBH of the urban area (Data 3) are 10.7 km and 3.4 km horizontally and 0.3 km vertically, which are very unequal (Table 1). The lengths

Sensors 2018, 18, 4398 9 of 14

(= 4 × 2 × 1, threshold = 1) octrees (Table4). The lengths of the MBH of the urban area (Data 3) are 10.7 km and 3.4 km horizontally and 0.3 km vertically, which are very unequal (Table1). The lengths in the x- and y-directions of a leaf node were 36.89 and 11.65 times larger than the length in the z-direction (Table5). A semi-isometric octree group was implemented using three thresholds and the group was composed of 36 (= 12 × 3 × 1, threshold = 3) to 396 (= 36 × 11 × 1, threshold = 1) octrees (Table5).

Table 3. Comparison of leaf node dimensions of Data 1.

Memory- and File-Based Octree Semi-Isometric Octree Group Ratios Ratios No. of octrees ti x y z x y z x y z 1 1.03 1.02 1.00 29 59 1 229.87 59.97 1.00 2.13 2.07 1.00 14 29 1 3 3.32 3.16 1.00 9 19 1

Table 4. Comparison of leaf node dimensions of Data 2.

Memory- and File-Based Octree Semi-Isometric Octree Group Ratios Ratios No. of octrees ti x y z x y z x y z 1 1.10 1.07 1.00 4 2 1 24.68 2.13 1.00 2.34 2.13 1.00 2 1 1 3 4.68 2.13 1.00 1 1 1

Table 5. Comparison of leaf node dimensions of Data 3.

Memory- and File-Based Octree Semi-Isometric Octree Group Ratios Ratios No. of octrees ti x y z x y z x y z 1 1.02 1.06 1.00 36 11 1 236.89 11.65 1.00 2.05 2.33 1.00 18 5 1 3 3.07 3.88 1.00 12 3 1

The main memory occupancy and time duration were measured during octree construction. To evaluate the performance, a proximity operation was conducted as introduced in [6]. This operation aims to query and retrieve neighboring points within a searching sphere from the sample points (Figure 12). Such an operation is known as fixed distance neighbors (FDN) [19] and can be applied to k-NN [20] if supplemented by distance sorting. The operation is necessary in normal estimation and noise filtering [19,21]. A total of 3005 sample points, or 1/100,000 of the data, were selected from Data 1 and neighboring points within a 5 cm (radius of the searching sphere) were queried. In all methods, the same 1,735,755 points were retrieved, and thus, no faults were detected in the proximity operation. Likewise, the same operation was conducted using Data 2 and Data 3 (Table6). Octrees were constructed in Depth 8 to 13 for the memory-based approach and in Depth 8 to 9~11 for the file-based and semi-isometric approaches to avoid memory occupancy exceeding any of the memory-based approach (Tables7–9). Memory usage, along with construction time increased accordingly. As is the precondition, main memory occupancy includes the size of the 3D point cloud itself in the memory-based approach (for example, 6878 MB for Data 1). The memory-based approach exhibited enormous speed in the proximity operation. The result is credible because the performance of the main memory can never be exceeded by a file-based operation, even using SSD. Nevertheless, the semi-isometric approach using Data 1 resulted in a performance that was a little better than the memory-based approach, and quite a lot better than the file-based one. The semi-isometric approach Sensors 2018, 18, 4398 10 of 14 in Depth 8 was defeated once by a file-based one in Depth 13, but the main memory occupancy was almost half. A little more memory occupancy quickly enabled enough performance improvement in the semi-isometric approach in Depth 9. Similar results were observed using Data 2 and Data 3. However, the semi-isometric approach using Data 2 did not result in dramatically better performance than the file-based one because the lengths of the MBH are not seriously unequal in the x-, y- and zSensors-directions. 2018, 18, x FOR PEER REVIEW 10 of 14

Figure 12. Proximity operation. Figure 12. Proximity operation. Table 6. Specifications of proximity operation. Table 6. Specifications of proximity operation. Data 1 Data 2 Data 3 Data 1 Data 2 Data 3 Number of sample points 3005 3063 2675 (ratioNumber to the of wholesample data) points (1/100,000)3,005 (1/6,000)3,063 (1/100,000)2,675 Number(ratio ofto retrievedthe whole points data) 1,735,755(1/100,000) 1,319,435(1/6,000) (1/100,000) 1,528,718 RadiusNumber of searchingof retrieved sphere points 1,735,755 5 cm 1,319,435 5 cm 1,528,718 5 m Radius of searching sphere 5cm 5cm 5m The best performance for the semi-isometric approach using Data 1 was achieved in Depth 10 withOctrees threshold were = 1 constructed (Table 10). in In Depth this case, 8 to the13 for main the memory memory-based occupancy approach was 72.76% and in thatDepth of 8 the to memory-based9~11 for the file-based approach and in semi-isometric Depth 8, but performance approaches to increased avoid memory to 81.82%. occu Inpancy the grey-highlighted exceeding any of cases,the memory-based the semi-isometric approach approach (Tables achieved 7–9). Memory better performance usage, along than with the construction file-based approach time increased in the sameaccordingly. Depth. InAs the is the green-highlighted precondition, main cases, memory the semi-isometric occupancy approachincludes the achieved size of betterthe 3D performance point cloud thanitself thein the best memory-based of the file-based approach approach (for example, with less 6878 memory MB for occupancy. Data 1). The In memory-based the yellow-highlighted approach cases,exhibited the semi-isometricenormous speed approach in the proximity resulted operatio in evenn. better The result performance. is credible The because results the in performance the cases of thresholdof the main = 3memory using Data can never 3 were be almost exceeded the sameby a file as-based the file-based operation, approach even us (Tablesing SSD.8 and Nevertheless, 11). This canthe besemi-isometric easily understood approach by theusing fact Data that 1 the resulted two approaches in a performance share the that same was leafa little node better dimensions than the (Tablememory-based4). Nevertheless, approach, it is and clear quite that a the lot performancebetter than the of file-based the semi-isometric one. The semi-isometric approach is better approach than thein Depth file-based 8 was one defeated in the same once Depth by a file-based in all cases. one Thus, in Depth it can 13, be but said the that main the semi-isometricmemory occupancy approach was isalmost a good half. alternative A little more compared memory to the occupancy other approaches. quickly enabled enough performance improvement in the semi-isometricTheoretically,a approach better performance in Depth 9. of Similar the semi-isometric results were approach observed should using beData achieved 2 and Data with 3. a smallerHowever, threshold the semi-isometricti and a larger approach Depth. using This Data is because 2 did not query result candidate in dramatically points are better more performance delicately selectedthan the if file-based a leaf node one gets because more cubic-shapedthe lengths of andthe smaller.MBH are Accordingly, not seriously all unequal results usingin the Datax-, y- 1 and meet z- thedirections. expectation (Table 10). However, the best performance was achieved in Depth 9 with threshold = 1 using Data 2, and in Depth 8 with threshold = 2 using Data 3 (Tables 11 and 12). This is because of over-subdivisionTable of7. Performance the octree, in comparison which a route among to octree reach implementing a leaf node is methods so long using that it Data overwhelms 1. the effect of the more delicate selection of query candidate points. For this reason, an optimal parameter is Semi-Isometric Octree hard to determine Memory-Based before an experiment,Octree and File-Based thus, several Octree configurations should be investigated to Group (𝒕 =𝟐) find the best one. 𝒊 Proxi Proxim Proxim Memor mity Memor Constr Memor Constr ity Constr ity y operat y Depth uction y usage uction operati uction operati usage ion usage. time (s) (MB) time (s) on time time (s) on time (MB) time (MB) (s) (s) (s) 8 9500 49.30 1.62 2607 51.01 290.32 3025 58.41 9.47 9 9617 55.19 0.76 2725 57.03 127.02 3477 66.80 4.24 10 9765 61.53 0.31 2874 63.40 48.63 4784 78.56 2.45

Sensors 2018, 18, 4398 11 of 14

Table 7. Performance comparison among octree implementing methods using Data 1.

Memory-Based Octree File-Based Octree Semi-Isometric Octree Group (ti=2) Memory Construction Proximity Memory Construction Proximity Memory Construction Proximity Depth usage (MB) time (s) operation time (s) usage (MB) time (s) operation time (s) usage. (MB) time (s) operation time (s) 8 9500 49.30 1.62 2607 51.01 290.32 3025 58.41 9.47 9 9617 55.19 0.76 2725 57.03 127.02 3477 66.80 4.24 10 9765 61.53 0.31 2874 63.40 48.63 4784 78.56 2.45 11 10065 68.92 0.19 3174 70.72 22.34 8240 99.67 2.14 12 10868 78.23 0.16 3978 80.03 11.25 13 12968 91.26 0.17 6077 92.81 5.71

Table 8. Performance comparison among octree implementing methods using Data 2.

Memory-Based Octree File-Based Octree Semi-Isometric Octree Group (ti=2) Memory Construction Proximity Memory Construction Proximity Memory Construction Proximity Depth usage (MB) time (s) operation time (s) usage (MB) time (s) operation time (s) usage. (MB) time (s) operation time (s) 8 606 3.12 0.05 185 3.26 7.66 187 3.68 5.54 9 625 3.65 0.05 204 3.79 4.07 223 4.29 2.65 10 713 4.37 0.09 293 4.51 2.59 364 5.15 2.20 11 997 5.43 0.30 576 5.52 2.59 12 1593 7.21 1.44 13 2491 10.06 8.27

Table 9. Performance comparison among octree implementing methods using Data 3.

Memory-Based Octree File-Based Octree Semi-Isometric Octree Group (ti=2) Memory Construction Proximity Memory Construction Proximity Memory Construction Proximity Depth usage (MB) time (s) operation time (s) usage (MB) time (s) operation time (s) usage. (MB) time (s) operation time (s) 8 8718 44.63 0.30 2584 46.82 36.47 3370 58.70 3.46 9 8890 51.47 0.14 2756 53.57 11.79 5299 76.17 3.67 10 9392 60.61 0.19 3258 62.68 7.24 11 10962 74.01 0.61 4828 75.96 7.07 12 15048 94.72 2.64 13 22289 131.93 13.68 Sensors 2018, 18, 4398 12 of 14

Table 10. Performance comparison among isometric octree groups using Data 1.

ti=1 ti=2 ti=3 Memory Construction Proximity Memory Construction Proximity Memory Construction Proximity Depth usage (MB) time (s) operation time (s) usage (MB) time (s) operation time (s) usage. (MB) time (s) operation time (s) 8 3324 59.80 4.18 3025 58.41 9.47 2913 57.97 12.87 9 4272 69.92 2.70 3477 66.80 4.24 3242 65.47 7.29 10 6912 84.83 1.98 4784 78.56 2.45 4115 76.35 2.82 11 8240 99.67 2.14 6515 95.63 2.36

Table 11. Performance comparison among isometric octree groups using Data 2.

ti=1 ti=2 ti=3 Memory Construction Proximity Memory Construction Proximity Memory Construction Proximity Depth usage (MB) time (s) operation time (s) usage (MB) time (s) operation time (s) usage. (MB) time (s) operation time (s) 8 211 3.84 2.59 187 3.68 5.54 183 3.65 7.64 9 301 4.60 2.08 223 4.29 2.65 205 4.18 4.07 10 598 5.65 2.25 364 5.15 2.20 292 4.91 2.60 11 574 5.94 2.62

Table 12. Performance comparison among isometric octree groups using Data 3.

ti=1 ti=2 ti=3 Memory Construction Proximity Memory Construction Proximity Memory Construction Proximity Depth usage (MB) time (s) operation time (s) usage (MB) time (s) operation time (s) usage. (MB) time (s) operation time (s) 8 4893 65.04 3.67 3370 58.70 3.46 3007 56.41 4.48 9 5299 76.17 3.67 4101 70.67 3.53 10 7289 91.43 4.15 11 Sensors 2018, 18, 4398 13 of 14

4. Conclusions In the present study, a basic algorithm to construct an octree for a 3D point cloud is introduced. The algorithm can be improved in terms of memory efficiency by using a compact form of node and revised parameter passing methods, and even further by using a file-based approach. However, the query speed of a file-based approach is very poor and becomes even worse when dealing with very longish 3D point clouds scanned in tunnels and corridors. The defects can be somewhat addressed by avoiding point concentration on fewer nodes using an anisometric approach, but this also brings about the problem of query overhead increment. Finally, the semi-isometric approach was introduced to improve query performance by implementing several semi-isometric octrees in a group. In the experiments, query performance and memory efficiency could be significantly improved in the case of a 3D point cloud captured in a long tunnel. When applied on a 3D point cloud captured in a short tunnel, the semi-isometric approach resulted in better performance (though not dramatically improved) than the file-based approach. Airborne laser scanning data was also tested and the semi-isometric approach resulted in acceptable enhancement of performance. By using media such as HDD of SDD, known to be much slower than main memory, a file-based approach and its derivations can never exceed the performance of a memory-based approach. Therefore, given enough main memory and using a moderately sized 3D point cloud, the memory-based approach is the best choice. When a 3D point cloud is larger than the main memory, as is quite common today, a file-based approach is the inevitable choice. In this case, however, the semi-isometric approach is a better choice no matter whether the 3D point cloud is longish or not. In all of the above approaches, however, every insertion of a point to a leaf node increases the main memory usage because a pointer to the point is pushed back to a vector archive of the leaf node. Eventually, the maximum number of points is limited to the size of the main memory. In future work, a more advanced approach is being planned to address this limitation.

Funding: This research was funded by Foundation of Korea (NRF) grant funded by the Korea government (MSIP), grant number NRF-2016R1C1B1013973. Conﬂicts of Interest: The author declares no conﬂict of interest.

References

1. Balsa Barreiro, J.; Avariento Vicent, J.P.; Lerma García, J.L. Airborne light detection and ranging (LiDAR) point density analysis. Sci. Res. Essays 2012, 7, 3010–3019. [CrossRef] 2. Balsa-Barreiro, J.; Lerma, J.L. Empirical study of variation in lidar point density over different land covers. Int. J. Remote Sens. 2014, 35, 3372–3383. [CrossRef] 3. Singh, K.K.; Chen, G.; McCarter, J.B.; Meentemeyer, R.K. Effects of LiDAR point density and landscape context on estimates of urban forest biomass. ISPRS J. Photogramm. Remote Sens. 2015, 101, 310–322. [CrossRef] 4. Schön, B.; Bertolotto, M.; Laefer, D.F.; Morrish, S. Storage, manipulation, and visualization of LiDAR data. In 3rd ISPRS International Workshop 3D-ARCH 2009; International Society of Photogrammetry and Remote Sensing: Trento, Italy, 2009. 5. Point Cloud Library (PCL): Module Octree. Available online: http://docs.pointclouds.org/1.8.1/group_ _octree.html (accessed on 12 October 2018). 6. Han, S.; Kim, S.; Hoon Jung, J.; Kim, C.; Yu, K.; Heo, J. Development of a hashing-based data structure for the fast retrieval of 3D terrestrial laser scanned data. Comput. Geosci. 2012, 39, 1–10. [CrossRef] 7. Han, S.-H.; Lee, S.-J.; Kim, S.-P.; Kim, C.-J.; Heo, J.; Lee, H.-B. A Comparison of 3D R-tree and Octree to Index Large Point Clouds from a 3D Terrestrial Laser Scanner. J. Korean Soc. Surv. Geod. Photogramm. Cartogr. 2011, 29, 39–46. [CrossRef] 8. Woo, H.; Kang, E.; Wang, S.; Lee, K.H. A new segmentation method for point cloud data. Int. J. Mach. Tools Manuf. 2002, 42, 167–178. [CrossRef] 9. Schnabel, R.; Wahl, R.; Klein, R. Efﬁcient RANSAC for Point-Cloud Shape Detection. Comput. Graph. Forum 2007, 26, 214–226. [CrossRef] Sensors 2018, 18, 4398 14 of 14

10. Hornung, A.; Wurm, K.M.; Bennewitz, M.; Stachniss, C.; Burgard, W. OctoMap: An efficient probabilistic 3D mapping framework based on octrees. Auton. Robots 2013, 34, 189–206. [CrossRef] 11. Schnabel, R.; Klein, R. Octree-based Point-cloud Compression. In 3rd Eurographics/IEEE VGTC Conference on Point-Based Graphics; SPBG’06; Eurographics Association: Aire-la-Ville, Switzerland, 2006; pp. 111–121. 12. Vo, A.-V.; Truong-Hong, L.; Laefer, D.F.; Bertolotto, M. Octree-based region growing for point cloud segmentation. ISPRS J. Photogramm. Remote Sens. 2015, 104, 88–100. [CrossRef] 13. Maréchal, L. Advances in Octree-Based All-Hexahedral Mesh Generation: Handling Sharp Features. In Proceedings of the 18th International Meshing Roundtable; Clark, B.W., Ed.; Springer: Berlin/Heidelberg, Germany, 2009; pp. 65–84. 14. Wang, M.; Tseng, Y.H. Automatic segmentation of Lidar data into coplanar point clusters using an octree-based split-and-merge algorithm. Photogramm. Eng. Remote Sens. 2010, 76, 407–420. [CrossRef] 15. Elseberg, J.; Borrmann, D.; Nüchter, A. One billion points in the cloud – an octree for efficient processing of 3D laser scans. ISPRS J. Photogramm. Remote Sens. 2013, 76, 76–88. [CrossRef] 16. Elseberg, J.; Borrmann, D.; Nüchter, A. Efficient processing of large 3D point clouds. In 2011 XXIII International Symposium on Information, Communication and Automation Technologies; IEEE: New York, NY, USA, 2011; pp. 1–7. 17. Han, S. Design of Memory-Efficient Octree to Query Large 3D Point Cloud. J. Korean Soc. Surv. Geod. Photogramm. Cartogr. 2013, 31, 41–48. [CrossRef] 18. Octree. Available online: https://en.wikipedia.org/w/index.php?title=Octree&oldid=853700715 (accessed on 12 October 2018). 19. Rabbani Shah, T. Automatic reconstruction of industrial installations: Using point clouds and images. Doctoral Thesis, Delft University of Technology, Delft, The Netherlands, 2006. 20. k-nearest Neighbors Algorithm. Available online: https://en.wikipedia.org/w/index.php?title=K-nearest_ neighbors_algorithm&oldid=860439224 (accessed on 18 October 2018). 21. Schall, O.; Belyaev, A.; Seidel, H.-P. Robust Filtering of Noisy Scattered Point Data. In Proceedings of the Second Eurographics/IEEE VGTC Conference on Point-Based Graphics; SPBG’05; Eurographics Association: Aire-la-Ville, Switzerland, 2005; pp. 71–77.

© 2018 by the author. Licensee MDPI, Basel, Switzerland. This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution (CC BY) license (http://creativecommons.org/licenses/by/4.0/).