📄 drv_ntf.html

📁 gdal库的学习文档
💻 HTML
字号:
<html><head><title>UK .NTF</title></head><body bgcolor="#ffffff"><h1>UK .NTF</h1>The National Transfer Format, mostly used by the UK Ordnance Survey,is supported for read access.<p>This driver treats a directory as a dataset and attempts to merge all the .NTFfiles in the directory, producing a layer for each type of feature (butgenerally not for each source file).  Thus a directory containing severalLandline files will have three layers (LANDLINE_POINT, LANDLINE_LINE andLANDLINE_NAME) regardless of the number of landline files.<p>NTF features are always returned with the British National Grid coordinatesystem.  This may be inappropriate for NTF files written by organizations otherthan the UK Ordnance Survey.<P><h3>See Also</h3><ul><li> <a href="http://home.gdal.org/projects/ntf/index.html">General UK NTF Information</a><p></ul><hr><h2>Implementation Notes</h2><h3>Products (and Layers) Supported</h3><pre>Landline (and Landline Plus):	LANDLINE_POINT	LANDLINE_LINE	LANDLINE_NAMEPanorama Contours:	PANORAMA_POINT	PANORAMA_CONTOUR	HEIGHT attribute holds elevation.Strategi:	STRATEGI_POINT	STRATEGI_LINE	STRATEGI_TEXT	STRATEGI_NODEMeridian:	MERIDIAN_POINT	MERIDIAN_LINE	MERIDIAN_TEXT	MERIDIAN_NODEBoundaryline:	BOUNDARYLINE_LINK	BOUNDARYLINE_POLY	BOUNDARYLINE_COLLECTIONS	The _POLY layer has links to links allowing true polygons to          be formed (otherwise the _POLY's only have a seed point for geometry.	The collections are collections of polygons (also without geometry	as read).  This is the only product from which polygons can be	constructed.	BaseData.GB:	BASEDATA_POINT	BASEDATA_LINE	BASEDATA_TEXT	BASEDATA_NODEOSCAR Asset/Traffic:	OSCAR_POINT	OSCAR_LINE	OSCAR_NODEOSCAR Network:	OSCAR_NETWORK_POINT	OSCAR_NETWORK_LINE	OSCAR_NETWORK_NODEAddress Point:	ADDRESS_POINTCode Point:	CODE_POINTCode Point Plus:	CODE_POINT_PLUS</pre>The dataset as a whole will also have a FEATURE_CLASSES layer containing a pure table relating FEAT_CODE numbers with feature class names (FC_NAME).  This applies to all products in the dataset.  A few layer types (such as the Code Point, and Address Point products) don't include feature classes.Some products use features classes that are not defined in the file, andso they will not appear in the FEATURE_CLASSES layer. <p>		<h3>Product Schemas</h3>The approach taken in this reader is to treat one file, or a directoryof files as a single dataset.  All files in the dataset are scanned on open.  For each particular product (listed above) a set of layers arecreated; however, these layers may be extracted from several files of thesame product. <p>The layers are based on a low level feature type in the NTF file, but willgenerally contain features of many different feature codes (FEAT_CODE attribute).  Different features within a given layer may have a variety ofattributes in the file; however, the schema is established based on theunion of all attributes possible within features of a particular type(ie. POINT) of that product family (ie. OSCAR Network).<p>If an NTF product is read that doesn't match one of the known schema'sit will go through a different generic handler which has only layers of type GENERIC_POINT and GENERIC_LINE.  The features only havea FEAT_CODE attribute.  <p>Details of what layers of what products have what attributes can be foundin the NTFFileReader::EstablishLayers() method at the end of ntf_estlayers.cpp.This file also contains all the product specific translation code. <p><h3>Special Attributes</h3><pre>FEAT_CODE: General feature code integer, can be used to lookup a name in the           FEATURE_CLASSES layer/table. TEXT_ID/POINT_ID/LINE_ID/NAME_ID/COLL_ID/POLY_ID/GEOM_ID:          Unique identifier for a feature of the appropriate type.  TILE_REF: All layers (except FEATURE_CLASSES) contain a TILE_REF attribute          which indicates which tile (file) the features came from.  Generally          speaking the id numbers are only unique within the tile and so          the TILE_REF can be used restrict id links within features from          the same file. FONT/TEXT_HT/DIG_POSTN/ORIENT:	Detailed information on the font, text height, digitizing position,         and orientation of text or name objects.  Review the OS product        manuals to understand the units, and meaning of these codes. GEOM_ID_OF_POINT:	For _NODE features this defines the POINT_ID of the point layer object        to which this node corresponds.  Generally speaking the nodes don't        carry a geometry of their own.  The node must be related to a point        to establish it's position. GEOM_ID_OF_LINK:	A _list_ of _LINK or _LINE features to end/start at a node.  Nodes,        and this field are generally only of value when establishing         connectivity of line features for network analysis.   Note that this        should be related to the target features GEOM_ID, not it's LINE_ID.        On the BOUNDARYLINE_POLY layer this attribute contains the GEOM_IDs        of the lines which form the edge of the polygon. POLY_ID:	A list of POLY_ID's from the BOUNDARYLINE_POLY layer associated with        a given collection in the BOUNDARYLINE_COLLECTIONS layer. </pre><h3>Generic Products</h3>In situations where a file is not identified as being part of an existingknown product it will be treated generically.  In this case the entire datasetis scanned to establish what features have what attributes.  Because of this,opening a generic dataset can be much slower than opening a recognised dataset.Based on this scan a list of generic features (layers) are defined from the following set:<p><pre> GENERIC_POINT GENERIC_LINE GENERIC_NAME GENERIC_TEXT GENERIC_POLY GENERIC_NODE GENERIC_COLLECTION</pre>Generic products are primarily handled by the ntf_generic.cpp module whereasspecific products are handled in ntf_estlayers.cpp.  <p>Because some data products (OSNI datasets) not from the Ordnance Surveywere found to have record groups in unusual orders compared to what theUK Ordnance Survey does, it was found necessary to cache all the records oflevel 3 and higher generic products, and construct record groups by idreference from within this cache rather than depending on convenient recordorderings.  This is accomplished by the NTFFileReader "indexing" capabilitynear the bottom of ntffilereader.cpp.  Because of this in memory indexingaccessing generic datasets can be much more memory intensive than accessingknown data products, though it isn't necessary for generic level 1 and 2products. <p>It is possible to force a known product to be treated as generic by settingthe FORCE_GENERIC option to "ON" using OGRNTFDataSource::SetOptionsList() asis demonstrated in ntfdump.cpp.  This may also be accomplished fromoutside OGR applications by setting the OGR_NTF_OPTIONS environment variable to "FORCE_GENERIC=ON".<p></body></html>
⌨️ 快捷键说明

复制代码 Ctrl + C
搜索代码 Ctrl + F
全屏模式 F11
切换主题 Ctrl + Shift + D
显示快捷键 ?
增大字号 Ctrl + =
减小字号 Ctrl + -