Geekly Articles each Day
📜 ⬆️ ⬇️

Translation of the ESRI Interior Building Data Model Concept (BISDM)

The data model of the internal space of buildings (rooms) provides templates for feature classes and tables that represent building information. While the focus is on planning and managing premises, there is also a goal to provide the basis for additional data related to buildings and structures to support a variety of applications. The model has incorporated the best practices in the field, which is rapidly developing in many areas in various organizations.

This document contains reference information and a description of the data model.

purpose


In October 2007, ESRI organized a discussion between representatives of standardization organizations, GIS users and software vendors to build a model for these premises.

The resulting model intends to:

Beyond the boundaries of the model


In order not to lose concentration and avoid discussions that relate to the objectives of the room model, it is important to determine what the model is not going to do:

Manual


Technological processes and data for managing the premises are complex and often seemingly not amenable to processing. However, there are several guidelines developed in various organizations that can be used to implement a successful application.
')

Service-oriented approach


Most of the justifications for using premises in GIS are related to the creation of geographic data that is available for deployment across the enterprise. Therefore, the model is structured in such a way that it can be integrated into a typical enterprise stack. This topic deserves some insight because this approach simplifies the model, speed of deployment, and makes it obvious that the model is positioned in large workflows in which GIS applications will work.

This approach is more important when processing in GIS data about the premises, and not in other GIS applications. In most other GIS applications, such as hydrology, GIS systems are themselves the core of workflows. In this case, the construction of data on the premises is often carried out outside the GIS. Even when information is generated using geodetic techniques in a GIS, many of the information consumers such as A / E / C consultants and suppliers require that the information be delivered in such a way that it can be integrated into their own tools.

Faced with similar workflow requirements and information exchange, many IT organizations are moving to a service-oriented approach that allows them to achieve the goal without replacing existing enterprise applications, which will avoid the need to centralize all data and processes, sharing information and logic along the natural limits of responsibility. A vivid example of such practices in terms of GIS is the function of accounting. It is not required to invent ERP (Enterprise Resource Management) accounting systems for systems within GIS to integrate them. Accounting functions and GIS practice require only the establishment of interfaces that will transfer data and tasks.

The same principles apply when working with data on real estate, architecture, maintenance and operation of buildings, or with data stored in IWMS (Integrated Workspace Management System) and CAFM (Real Estate Infrastructure Management Automation System). This data is already managed by systems with a long history, established norms and a strong industrial impulse - each of which can try to strengthen the GIS instead of reinventing the invention. To improve efficiency, even if GIS systems provide unique data, you only need to associate GIS with these systems.

For example, a maintenance management system will have sophisticated schemes for tracking equipment, preventive procedures and steps, requests for work, work orders, information about labor, and other aspects of current maintenance. GIS can add tremendous value to this business function by providing location information, driving a route, and creating a context for making equipment decisions. To provide these capabilities, the data model should only connect with existing hardware information. The data model does not need to be imported or attempted to manage a complete array of equipment data.

This approach eliminates the need to rewrite existing standards, or duplicate data, or data models that are already sufficiently managed in BIM (Building Information Model), CAD (Computer Aided Design) systems, ERP (Enterprise Resource Management), Real Estate Management System, IWMS ( Integrated Workspace Management System), CAFM (Real Estate Infrastructure Management Automation System), or CMMS (Computerized Maintenance Management System).

Using logical object identifiers


Ways of connecting systems with each other are in the center of attention of enterprises, since Many elements of the data model require the use of identifiers that are generated by systems external to the GIS.

Consider equipment that is often identified by a bar code received when it is accepted as part of an asset management program. This bar code identifies equipment throughout its life cycle and is used for various purposes: for easy management of moving and physical placement tasks, for solving maintenance tasks and for financial tasks such as tracking its cost and depreciation, and auditing.

Within this context, a GIS can provide tremendous added value in locating equipment across the enterprise without regard to whether it is inside or outside the building. However, for this data item — hardware — GIS is only responsible for location. Other data elements and the fact of equipment existence are controlled by other systems, and GIS applications must design their identifiers in accordance with the identifiers of external systems. Property, buildings, apartments and other elements follow the same pattern.

In these cases, primary keys are used that identify the elements that provide the best data connection. Combined with the fact that in many cases additional information is external to a GIS, this structure often means that the spatial GIS data is stored in a set of tables that includes logical identifiers (such as equipment bar codes) as a link or foreign key. The rest of the data is stored in separate tables of the external system (such as an asset management system) or imported from the tables of the external system. In some circumstances, a multitude of foreign keys may be required for the connection between the spatial GIS data and the associated but independent external information system. This involves using a technique whereby the primary key is stored in the feature table as an attribute, and the feature table and the table with additional information are combined using the ArcSDE view (View) or the map “Join” tool.

Definition of the source system of graphic data


Objects with strong graphic connections are guided by other principles. For example, the identification of walls and doorways is generated from their graphic representation and location. No other presentation including cost exists without reference to graphic identity. In addition, the key properties of elements are their relationships with each other: such as connecting walls to each other. In this case, the connection with existing systems is possible only through mass import or export of whole parts of the model such as the floor or wing of the building.

Please note that you can not just use both approaches. You cannot establish a correspondence between walls generated by GIS based on measurement data (external data) with walls generated in the BIM architectural model (internal data) without manual processing.

You cannot reliably reimport data about elements, such as walls, because unlike rooms or equipment, walls do not have a unique identifier that tells you which individual elements should be added, deleted, or recreated.

Observe the data generation processes.


Because of these properties, technological processes for graphics are one-way. You can repeat the import of building walls from the BIM (Building Information Model) model, but you must replace these walls in the GIS each time.

You can also re-import premises from a BIM (Building Information Model) model, but all the turning points for individual buildings, rooms or apartments must be recreated. You cannot economically compare the data created in the BIM model (Building Information Model) and the data created in the GIS at the same place.


However, you can define different source systems for different areas. For example, you can determine that the graphical location of all objects located inside the building comes from a BIM (Building Information Model) model or from a CAD system. On the other hand, you can claim that the location of all external equipment such as transformers or telephone poles comes from the geodetic measurements obtained from within the GIS systems. There is no conflict in this, since only one source of information is established for each piece of equipment. Again, this is only a recommendation, not a limitation.

As mentioned above, the data model of the premises is only important inside large workflows that generate or consume data. Ensure that GIS data remains associated with “live” workflows, because This will ensure that the data is accurate, current and relevant to the enterprise.



Scalability


One of the key advantages of GIS is their ability to replicate and scale, so the model must take into account the problems of scalability and performance. To this end, the data model is focused on the relational basis of GIS systems; that is, the room model is not an object-oriented project. This approach does not preclude the use of object-oriented methods, but assumes that the object-oriented code must be located at the logical level or at the level of the application processing the information, instead of the data level storing the model.

From the point of view of describing standardized objects, relationships reflect compliance with the standard, but do not implement it. For example, in the room data model, the walls will be mapped to the elements inside the buildingSmart element (family of standards) IFCWall (wall); however, they will not implement the entire hierarchy of objects placed within IFCWall .

Include only valid data


It is not standardized what elements and attributes are included in the data model, there is only hope that the collection of information will provide a return on investment. This is especially true at the design stage of data collection, commissioning and data processing, as the construction engineering personnel does not know what data the followers will use and whether they will be saved.

All data causes costs throughout the life cycle, whether they will be transformed, revised or maintained. Even if you do a field survey, every additional attribute you decide to collect in any case creates costs for data entry, validation and import. In addition, any data cut off from the process that produces it becomes dangerously obsolete and reduces the value of data that is accurate and reliable.

These considerations lead to the need to focus in the data model on a minimum set of elements that support short-term usage scenarios, instead of a wide data set that supports “foggy” goals. Such an approach, together with pragmatic workflows, is likely to speed up the practical implementation compared to a naive method demonstrating that it is not possible to reasonably provide constant accuracy for the data that it claims to process.

Focusing only on best practices of enterprise scale.


Avoid any recommendations that work well for demonstration purposes only, but do not scale for corporate use. For example, it is possible to include status evaluation information in a hardware record. But in the enterprise, assessment tasks are tracked separately, since they can be performed multiple times for each piece of equipment, can be downloaded to a PDA and assigned to a master, and subsequently can be transformed into a request for work. Therefore, the evaluation elements in the equipment table should be avoided.

Focusing on GIS-directed elements


Use cases that justify the short-term implementation of GIS-technologies for premises are those that clearly need to be enhanced with properties unique to GIS.

These cases are those that:

Thus, the data model begins with GIS-directed content.


Link to existing standards


The considered data model intends to refer, rather than reinvent existing standards for related areas.


buildingSmart IFC Model


http://www.iai-na.org/bsmart/

This standard is used by some members of the AEC industry (architecture, design and construction) and standardizes geometric elements, connections and constraints for building elements such as walls, doors, pillars and equipment. These elements in the model of these premises are the internal elements of buildings and have a one-to-one mapping to the elements of the IFC (Industry Foundation Classes) model.

The IFC (Industry Foundation Classes) model is designed for desktop systems, not for deployment in an enterprise environment. This model is also created without the fact that different parts of the data can be created by different groups within the enterprise. For example, equipment data is developed not only by the architect and engineer, but also by people in finance, procurement, operation, and maintenance. Theoretically, they can be stored in a single IFC (Industry Foundation Classes) facility. But in practice, these parts of the data are managed in various systems that are interconnected using web services, since information on depreciation, location and maintenance is more strongly associated with the process-owner, and not with other parts of the data. In essence, the IFC (Industry Foundation Classes) is an abstract standard that serves more as a reference, in particular for data exchange, but not a structure or model that can be deployed at the enterprise level “as is”.

CityGML


http://www.citygml.org/

CityGML belongs to the urban scale GIS. Basically coincides with the model of the premises when rendering buildings. To this end, the 3D buildings in the internal model are mapped to CityGML.

OSCRE


http://www.oscre.org/

This standard refers to the data of the portfolio of real estate level of buildings and refers to the internal level of the standards BOMA (Association of owners and managers of real estate), IFMA (Association of professionals in the field of operation and maintenance of real estate), FICM (Facilities Inventory and Classification Manual). The elements described by him are usually managed within the framework of the IWMS (Integrated Workspace Management System) applications.

The relevant elements within the GIS room model do not include elements related to the OSCRE standards (Open Standards Consortium for Real Estate). For example, the GIS model of the premises includes the location of the property as a point object with one attribute representing a unique property code (PROPERTY_ID). For example, the code EO13327 is a unique identifier of the property used in the existing real estate registry. Thus, the internal GIS model stores the location, and the external system stores other properties and their hierarchies.



BOMA / IFMA / FICM / DIN277


http://www.boma.org/AboutBOMA/

http://www.ifma.org/

http://nces.ed.gov/pubs2006/2006160.pdf (FICM)

These standards regulate the classification of premises and, to a large extent, support the distribution between units of direct or indirect costs aimed at generating income. For premises, these standards determine how the boundaries of apartments and rooms will be identified within BIM (Building Information Model) or CAD, and how these spaces will be classified according to equipment level and type. The considered model stores references to records external to the GIS spatial tables, and these external records are located in the IWMS (Integrated Workspace Management System) or CAFM (Real Estate Infrastructure Management Automation System) covered by these standards.

COBIE - Exchange of information on the design and operation of buildings


http://www7.nationalacademies.org/ffc/Bill_Brodt_NASA_COBIE_Oct_06_WP.pdf

http://www.bfrl.nist.gov/PSSIWG/presentations/COBIE1.pdf

This standard regulates operational procedures in work orders and data on service planning in work applications. The standard focuses on the exchange of items such as warranties, maintenance manuals, spare parts, and special tools. The space data model in question refers to this information instead of including it. Thus, as long as the associated maintenance system complies with the COBIE standard, it is compatible with this model.

Integration methods


When analyzing buildings in the real world, you cannot express your opinion even about the basic architectural concept of a building, without knowing about the method of its structure implementation in concrete or steel. It is also hard to express your opinion about the data model without some idea of ​​how to implement applications built on it.

Web Services / Service Oriented Architecture


In this case, the application itself is responsible for transforming the initial data of the model into the logic of the application. The application is also responsible for coordination with GIS.



The figure shows an example of such an application. The model uses points (longitude and latitude) for buildings and applies this information to the spatial reference of lease agreements concluded for the premises in this building. The application uses web services to connect to the GIS and provides the actual data display, in this case, the inventory data.

Direct connection to the database




In this case, the application's data model and the room data model are connected at the database level. One way to do this is to use separate tablespaces within a single database instance and connect them using ArcSDE views. The first advantage of this approach is that application and GIS data can be queried as if they were part of a single unified model. The second advantage is that these queries have very high performance. The third is that connections can be made using composite keys - an indispensable element for working with room data.

This design approach keeps the geodatabases as specialized as possible and supports separate attribute assignment if it can be done better in an interconnected system containing workflows and corresponding relationships. The composite key problem illustrates some of the limitations of a geodatabase in terms of application support, and this approach avoids these limitations completely.



The figure shows an example of database integration. Data on roads, utilities, and land plots come from traditional sources of GIS data. Building data and inscriptions come from the property management application, and equipment data and equipment labels come from the asset management application. However, data from all sources are available and displayed seamlessly in a GIS environment.

Database extension


When deploying some sites, enterprises will prefer to expand the model under consideration instead of integrating it with an external system. For example, instead of using a commercial asset management system to account for equipment, they may prefer their own implementation using a new table in the geodatabase.

This can be done by following the above convention. For example, data on the spatial location of the equipment, identified by the equipment code, may be located in one table. And the remaining asset data will be placed in another table related to the feature class. Although this internal solution does not rely on any external system, it follows best practices in data structuring that facilitate their maintenance. For example, without loss of data or their integrity, GIS can create and delete spatial data, and an asset management system can create data about assets. The only limitation is that when the graphics are created, the GIS application must track the equipment code.

Import and export


The model elements of these premises reflect, rather than implement or rethink, existing standards.For example, applications can create data model elements from the BIM (Building Information Model) model or export them to the BIM model without the additional loss typical of such data movements.

However, the space model is not going to become a standard and therefore the export of elements into intermediate formats becomes optional. This approach allows the model to concentrate on creating direct transformation of elements from key packages such as Revit ™, Bentley ™ or ArchiCAD ™ - practical and ready for production.

This approach also allows the model to strengthen the existing API's of these packages in terms of managing key aspects of this transfer and to maintain broad compatibility with existing standards. For example, you can create walls using the Revit API simply using the necessary materials, thickness and height of elements. Then Revit itself can export the model to a format compatible with buildingSmart IFC. Alternatively, you can create elements in ESRI and use a data conversion program, such as Safe Software's FME ™, to create an industry compatible format IFC (Industry Foundation Classes). This approach satisfies all the desired usage scenarios: you can quickly and efficiently convert data created in commercial software packages to rich capabilities.vendor-independent format.

This approach also avoids any dependence on how the graphic data is stored. The data will be created in an environment that is dictated by technological processes, but they can move into any other environment that needs it.

Elements of the initial coverage of the model


, .

, . , , . , ESRI 1 (, , , ). .


, , . , EO13327 , , , Federal Real Property Council (, , ). , , .

Use cases


, , , .

, ( ESRI Parcels and Cadastre data model).

.

“”


( ) .

Property_Point




PROP_ID


String


.



— .

“ ”


IWMS ( ) CAFM ( ) , . . “” “ ” --. “ ”, “”.

, OSCRE ( ), . “” , --: 1 “ ”.

. .

Property_Info




PROP_ID


String


.


PROP_NAME


String



DESCRIPTION


String



ADDRESS1


String


1


ADDRESS2


String


2


STREET


String



CITY


String



STATE


String


Subject Identifier or USPS State Code


ZIP


String


Postcode


Zoning


String


Functional Area Code


BOOK_VALUE


Double


Book value


MARKET_VALUE


Double


Market price



It is tempting to unify property addresses with other types of addresses located in GIS. However, the addresses belong to the application that created them and have an application-specific meaning in this context. The delivery agency has one definition for an address, the public safety application is another. Establishing a link between an address and property, as well as between an address and a building, is not a simple matter.

If the address must be associated with the cadastre or with the system of building routes, the addressing will be supported by a special technological process. The organization creates a structure that receives permission to issue addresses. The result is a model in the form of points associated with a street network, so that you can build routes. In the case of registered property, corporate users manually enter the address without following the formal process of determining it.

Columns with longitude-latitude coordinates.Buildings, depending on how they use the information, have more than one feature class associated with them. As an alternative method for storing location data, you can add longitude-latitude coordinates to an asset table. Property management systems will often set the location as an address, rather than as a point. Sites wishing to use location information may use longitude and latitude to navigate to a particular location. This is a fast and efficient way to display real estate on maps. It can also help with geocoding the location of a building from their addresses. The result of adding this column is a method for determining the location of buildings and any of their contents in the broadest sense: rental agreements, tenants, equipment, etc.giving a high return on investment.

Spatial building data


Building information has two levels of geometric detail:

Each geometry type has its own feature class, which can be tied to the entries in the Building Information table.

The “Point Buildings” feature class


Building_Point


The point feature class represents the location of buildings.


PROP_BLDG_ID


String


Unique identifier combining property ID and building ID




The feature class “Areal buildings”


Building_Footprint


The polygonal feature class represents the area under the building.


PROP_BLDG_ID


String


Unique identifier combining property ID and building ID



, , , , , . , .

, . . ( ESRI 3D ).

“ ”


This related table contains application information. An example of a table illustrating this relationship is shown below.

Building_Info


Detailed building information


PROP_ID


String


Unique identifier of the property. Property may consist of many buildings.


BLDG_ID


String


The unique identifier of the building within the property.


PROP_BLDG_ID


String


Unique identifier combining property ID and building ID


BLDG_NAME


String


Building name


BLDG_USE


String


Building use code


DATE_BUILT


Date


Date of construction


ADDRESS1


String


Address Line 1


ADDRESS2


String


Address Line 2


STREET


String


Street name


CITY


String


City ID or Name


STATE


String


Subject Identifier or USPS State Code


ZIP


String


Postcode




Controls for the internal structure of buildings


Use cases


These items are suitable for:


Floors and groups. Intermediary objects, such as floors or groups for real estate or real estate management, can be useful. In these cases, the “Floor” may simply be a confirmation code or a graphic element.

Building_Floor


The table contains information about the floors of the building


PROP_BLDG_ID


String


Unique identifier combining property ID and building ID


FLR_ID


String


Floor ID


BLDG_FLR_ID


String


Unique identifier combining the building ID and floor ID




“”


Building_Room


,


BLDG_FLR_RM_ID


String


, ,


CEILING_HEIGHT


Double


, ,


ACTUAL_ELEVATION


Double




Like other elements, the geometric properties are in a table with spatial data; The assignment and functional group are in a related table. They can be implemented as a related view. Ceiling height is used for 3D visualization. This attribute is in a spatial table, because this greatly simplifies the extrusion of a 3D object. This attribute should be stored in each room, since some rooms on the same floor (such as a lecture hall, cafeteria) will have their own height.

The actual height is used to analyze line of sight and zoning studies.

Key geometric properties such as area can be calculated based on the geometric boundaries of the room.

Table “Room Information”


IWMS ( ) CAFM ( ) , . . , , .

Room_Info




BLDG_FLR_ID


String


,


RM_ID


String



RM_NAME


String



BLDG_FLR_RM_ID


String


, ,


RM_CAT


String



RM_TYPE


String



DESCRIPTION


String


“ ”


DV_ID


String



DP_ID


String




(BOMA ( ), IFMA ( ), FICM (Facilities Inventory and Classification Manual), DIN277 ( )). .

“”


Building_Zone
, . HVAC (, ),

BLDG_FLR_ZONE_ID


String


, ,
CEILING_HEIGHT
Double

, ,


ACTUAL_ELEVATION


Double




, , , .

“ ”


, HVAC (, ), , , , , .

Building_Zone_Info




BLDG_FLR_ID


String


,


ZONE_ID


String


. .


BLDG_FLR_ZONE_ID


String


, ,


DESCRIPTION


String


“ ”


SYSTEM_ID


String


, . HVAC (, ), , , ..




“”


Equipment




EQUIP_ID


String





Equipment can be positioned by a point object (for example, the latitude and longitude of the telephone pole on which the transformer is located).

The equipment communicates with the details using an equipment code that you can think of as a bar code that personalizes it in the asset management and maintenance system.

It is difficult to find a use case that needs actual equipment height instead of conditional height.

Table “Equipment Information”


Equipment_Info


Table “Information about the equipment” information about the equipment located inside the building


EQUIP_ID


String


Unique equipment identifier


EQUIP_STD


String


Equipment classification or standard description


DESCRIPTION


String


Description of “Equipment Information”


BLDG_FLR_RM_ID


String


Unique identifier combining the building ID, floor and room ID



The “Equipment Information” table contains information about the purpose and functional group of equipment. In most cases, this information will be stored in an asset management system (for example, an IWMS (Integrated Workspace Management System) system) or a maintenance system (CMMS).

The equipment table contains these items, which will be cataloged for an inventory of assets or for maintenance. The equipment table does not contain other elements, such as elements of communication systems: panels, ports, connectors, network devices, and so on. They will need their own tables with unique attributes.

Internal modeling and analysis of buildings


Supported Use Cases


The set of elements allows:


These data allow, but by themselves are not sufficient for:



, , , CityGML LOD 2 ( ). , . , , , , , , , .


All internal building elements use the same linear feature classes to represent their boundaries as a collection of lines.

Walls, for example, consist of 5 lines, where the fifth is an axis. Internal walls, external walls, columns, doors and windows - all will be subtypes of the same class.

3D mapping should use multipatch (ESRI spatial class for 3D visualization) to display the corresponding height of openings and shapes. This kind of 3D representation is beyond the scope of this data model phase, with the exception of the representation, usually created by extruding 2D features.

Boundary_Line


, . , ,


BLDG_FLR_ID


String


.


BOUNDARY_SUBTYPEID


Integer


: , ..


NOTES


String



SPACE_CATEGORY


String



CEILING_HEIGHT


Double


, ,


BASE_ELEVATION


Double







— BOUNDARY_SUBTYPEID


Boundary Line



Centrline



Door



Exterior Door Line



Exterior Wall Line



Phantom



Wall



Window




, .

IFC's (Industry Foundation Classes). .

Walls


, :
http://www.iai-international.org/Model/documentation/IfcR2x_Final/IFCSHAREDBLDGELEMENTS/lexical/IfcWall.html

IFC (Industry Foundation Classes):
http://www.blis-project.org/private/proposals/IFCR2_WallGeometry_991107_jh.pdf

:
http://www.steptools.com/support/stdev_docs/express/ifc2x3/html/t_ifcwall.html


:

http://www.iai.fhm.edu/how-to-implement-ifc/Implementer-Agreements/ifc2x3-coordview-agreements/cv-06-134/


Doors, lexical description:

http://www.iai-international.org/Model/documentation/IfcR2x_Final/IFCSHAREDBLDGELEMENTS/lexical/IfcDoor.html

Window


Windows, lexical description:
http://www.iai-international.org/Model/R2x3_final/ifcsharedbldgelements/lexical/ifcwindow.htm

Conclusion


Future elements of model coverage - visualization of real estate elements


Use cases


This part of the model is suitable for:

Building visualization


For these purposes, buildings are created in the form of polymesh objects (polyhedral networks) with photos displayed on their outer side that reflect their appearance. The same feature of the building is used, but only the layout elements of the architectural masses used. These elements are mapped to CityGML LOD 1 (level of detail).


This use case is consistent with the current level of technology in terms of visualization. This view plays an important role in workflows where people try to understand the relationship between the artificial and the natural environment. The development team of the model will move on this topic in later phases.

Item


Type of


Purpose


Building code


Alphanumeric


Contains a unique building identifier


The layout of the architectural masses of the building


Polymesh (polyhedral networks)


Contains geometric data on the layout of architectural building masses


Photos of the outside of the building


Raster


Contains a collection of the exterior of the building





Drawings from gbXML.org

Future model coverage elements — other features


Use cases suitable for future phases include:



Dictionary of highly specialized terms


Bim


Building Information Modeling


Building Information Model


CAD


Computer aided design


CAD system


CAFM


Computer Aided Facility Management


Automation system for managing real estate infrastructure


CRE


Corporate Real Estate


Corporate Property


CMMS


Computerized Maintenance Management Systems


Computerized maintenance management system


ERP


Enterprise Resource Planning


Enterprise Resource Management


Feature


An object that has a geographic location or georeferenced shape stored as one of its properties. Features can be points, lines, polymeshes and other shapes.


A spatial object is an object that has a geographic location or georeferenced geometry stored as one of its attributes. A spatial object can be a point, line, Polymesh (multi-faceted network), etc.


Feature Class


The same type of geographic representation


The set of features that have the same type of geometry view and the same attributes


GIS


Graphical Information System


GIS. Geographic Information System


Iwms


Integrated workplace management system


Integrated Workspace Management System


Polymesh


A GIS feature


Multifaceted networks. A GIS feature that is used to represent complex 3D objects using tessellation (tiling, an automated process of adding new convex polygons to a polygonal mesh in order to increase mesh detail) of the surface with triangular faces.


Source: https://habr.com/ru/post/322588/

More articles:


All Articles