|
阅读:3238回复:8
求arcinfo 的grid数据格式相关资料
<P>我现在想读取grid高程数据并在globecontrol中显示,但是搞了很久都没有成功,大家有什么解决办法吗?</P>
|
|
|
1楼#
发布于:2008-01-09 02:43
使用ao的 IGxDialog接口 可轻易实现<BR>
|
|
|
2楼#
发布于:2006-07-17 14:10
<P>数据在w001001.adf,binary grid 读起来挺麻烦的,一个象素占的字节数,有没有压缩存储,以及采用哪种压缩,都要搞清楚。</P>
|
|
|
3楼#
发布于:2006-07-04 14:43
请问,我的grid数据的文件夹里,怎么没有vat.adf文件,这个文件里面是不是放值的?grid数据的值在哪个文件里的阿?
|
|
|
4楼#
发布于:2005-09-14 20:07
<P>好的!</P>
<P>下面就是我最初的尝试代码,大家帮忙看看有啥问题。</P> <P>'add elevation data to the active globe viewer , as the base height layer<BR> Private Sub mnu_addelev_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles mnu_addelev.Click<BR> OpenFileDialog1.Filter = "ESRI GRID(<GRID>)|<GRID>|USGS DEM(*.dem)|*.dem"<BR> OpenFileDialog1.Title = "select the elevation data to add"<BR> OpenFileDialog1.Multiselect = True<BR> OpenFileDialog1.InitialDirectory = "c:\"<BR> OpenFileDialog1.ShowDialog()<BR> If OpenFileDialog1.ShowDialog() = DialogResult.OK Then 'when the user event happen<BR> Dim m_prwsf As IWorkspaceFactory<BR> m_prwsf = New RasterWorkspaceFactory<BR> Dim m_pfiledr As String<BR> m_pfiledr = StrReverse(OpenFileDialog1.FileName)<BR> Dim i As Integer<BR> Dim j As Integer<BR> Dim a As Char<BR> For i = 1 To Len(m_pfiledr)<BR> a = GetChar(m_pfiledr, i)<BR> If a = "\" Then<BR> j = i<BR> Exit For<BR> End If<BR> Next<BR> Dim m_prdr As String<BR> Dim p_dir As String<BR> p_dir = Mid(m_pfiledr, j)<BR> m_prdr = StrReverse(p_dir)<BR> Dim m_prfilename As String<BR> m_prfilename = StrReverse(Mid(m_pfiledr, 1, j - 1))<BR> ' m_prfilename = Mid(OpenFileDialog1.FileName, Len(OpenFileDialog1.FileName) - j + 2)<BR> Dim m_Prws As IRasterWorkspace<BR> m_Prws = DirectCast(m_prwsf.OpenFromFile(m_prdr, 0), IRasterWorkspace)<BR> Dim m_prdts As IRasterDataset<BR> m_prdts = m_Prws.OpenRasterDataset(m_prfilename)<BR> If m_prdts Is Nothing Then 'check whether the raster dataset is existing or not <BR> MsgBox("please select the correct dataset!", MsgBoxStyle.RetryCancel, "error of adding elevation data")<BR> End If<BR> Dim m_pglobe As IGlobe<BR> m_pglobe = AxGlobeControl1.Globe<BR> Dim m_prlyr As IRasterLayer<BR> Dim m_pr As IRaster<BR> m_prlyr = New RasterLayer<BR> m_prlyr.CreateFromRaster(m_prdts)<BR> Dim m_prbands As IRasterBandCollection<BR> m_prbands = m_prdts<BR> Dim m_prband As IRasterBand<BR> m_prband = m_prbands.Item(0)<BR> Dim m_pdt As IDataset<BR> m_pdt = m_prband.RasterDataset<BR> m_prlyr.Name = m_pdt.BrowseName<BR> Dim m_plyr As ILayer<BR> m_plyr = New RasterLayer<BR> m_plyr = m_prlyr<BR> Dim m_Pelevlyrprop As IGlobeLayerProperties<BR> m_Pelevlyrprop = New GlobeLayerProperties<BR> m_Pelevlyrprop.Type = esriGlobeDataType.esriGlobeDataElevation<BR> Dim m_Plyrex As ILayerExtensions<BR> m_Plyrex = m_plyr<BR> m_Plyrex.AddExtension(m_Pelevlyrprop) 'i can not see what effect this does!<BR> Dim m_Pelevhprop As IGlobeHeightProperties<BR> m_Pelevhprop = New GlobeHeightProperties<BR> m_Pelevhprop.BaseOption = esriGlobeLayerBaseOption.esriGlobeLayerBaseSelf<BR> m_Pelevlyrprop.HeightProperties = m_Pelevhprop<BR> m_Pelevhprop.Apply(m_pglobe, m_plyr)<BR> If Not m_plyr Is Nothing Then<BR> m_pglobe.AddLayerType(m_plyr, esriGlobeLayerType.esriGlobeLayerTypeElevation, True)<BR> m_pglobe.GlobeDisplay.RefreshViewers()<BR> Else<BR> MsgBox("the elevation data is null!please retry!")<BR> End If<BR> Else<BR> Exit Sub<BR> End If<BR> End Sub</P> <P>调试的时候,出现“未指定错误”信息。在局部变量窗口察看,rasterdataset和raster layer都为空。</P> <P>那位高手做过向globecontrol或者scene viewer中加载grid栅格高程数据这方面的工作,请指教一下!</P> |
|
|
5楼#
发布于:2005-09-14 15:55
<P>应该和添加tin文件等都差不多的喽</P>
<P>现在没办法,你怎么试的啊?贴出来,大家才好说哈</P> |
|
|
|
6楼#
发布于:2005-09-13 15:05
<P>谢谢gis!</P>
<P>我要做的是在globecontrol中显示grid高程数据,需要用户选择要添加的数据,但是由于grid数据比较特殊,他不是一个单独的文件,而是以一个文件夹的形式出现,所以不知道如何实现加载,你说的利用irasterlayer和ilayer方法,我都已经试过了,但是还是不可以!</P> <P>希望大家有什么好的建议,畅所欲言!</P> |
|
|
7楼#
发布于:2005-09-12 20:27
dblbnd.adf - Georef BoundsFields: <br>
<P>Start Byte <br># of Bytes <br>Format <br>Name <br>Description <br>0 8 MSB double D_LLX Lower left X (easting) of the grid. Generally -0.5 for an ungeoreferenced grid. 8 8 MSB double D_LLY Lower left Y (northing) of the grid. Generally -0.5 for an ungeoreferenced grid. 16 8 MSB double D_URX Upper right X (northing) of the grid. Generally #Pixels-0.5 for an ungeoreferenced grid. 24 8 MSB double D_URY Upper right Y (northing) of the grid. Generally #Lines-0.5 for an ungeoreferenced grid. This file is always 32 bytes long. The bounds apply to the portion of the grid that is in use, not the whole thing. <br> <P>w001001x.adf - Tile IndexThis is a binary dump of the first 320 bytes of a w001001x.adf file. <br> <P> 0: 0000270A FFFFFC14 00000000 00000000 ~~'~~~~~~~~~~~~~<br> 16: 00000000 00000000 00000BFA 00000000 ~~~~~~~~~~~~~~~~<br> 32: 00000000 00000000 00000000 00000000 ~~~~~~~~~~~~~~~~<br> 48: 00000000 00000000 00000000 00000000 ~~~~~~~~~~~~~~~~<br> 64: 00000000 00000000 00000000 00000000 ~~~~~~~~~~~~~~~~<br> 80: 00000000 00000000 00000000 00000000 ~~~~~~~~~~~~~~~~<br> 96: 00000000 00000032 00000202 00000235 ~~~~~~~2~~~~~~~5<br> 112: 000001D4 0000040A 00000000 0000040B ~~~~~~~~~~~~~~~~<br> 128: 00000000 0000040C 00000000 0000040D ~~~~~~~~~~~~~~~~<br> 144: 00000000 0000040E 00000000 0000040F ~~~~~~~~~~~~~~~~<br> 160: 00000000 00000410 00000202 00000613 ~~~~~~~~~~~~~~~~<br> 176: 000001D4 000007E8 00000000 000007E9 ~~~~~~~~~~~~~~~~<br> 192: 00000000 000007EA 00000000 000007EB ~~~~~~~~~~~~~~~~<br> 208: 00000000 000007EC 00000000 000007ED ~~~~~~~~~~~~~~~~<br> 224: 00000000 000007EE 00000202 000009F1 ~~~~~~~~~~~~~~~~<br> 240: 000001D4 00000BC6 00000000 00000BC7 ~~~~~~~~~~~~~~~~<br> 256: 00000000 00000BC8 00000000 00000BC9 ~~~~~~~~~~~~~~~~<br> 272: 00000000 00000BCA 00000000 00000BCB ~~~~~~~~~~~~~~~~<br> 288: 00000000 00000BCC 00000202 00000DCF ~~~~~~~~~~~~~~~~<br> 304: 000001D4 00000FA4 00000000 00000FA5 ~~~~~~~~~~~~~~~~<br>Fields: <br> <P>Start Byte <br># of Bytes <br>Format <br>Description <br>0 8 Magic Number (always hex 00 00 27 0A FF FF FC 14). 8 16 zero fill 24 4 MSB Int32 Size of whole file in shorts (multiply by two to get file size in bytes). 28 72 zero fill 100 + t*8 4 MSB Int32 Offset to tile t in w001001.adf measured in two byte shorts. 104 + t*8 4 MSB Int32 Size of tile t in 2 byte shorts. sta.adf - Raster StatisticsFields: <br> <P>Start Byte <br># of Bytes <br>Format <br>Name <br>Description <br>0 8 MSB double SMin Minimum value of a raster cell in this grid. 8 8 MSB double SMax Maximum value of a raster cell in this grid. 16 8 MSB double SMean Mean value of a raster cells in this grid. 24 8 MSB double SStdDev Standard deviation of raster cells in this grid. This file is always 32 bytes long. <br> <P>w001001.adf - Raster DataThis is a binary dump of the first 320 bytes of a w001001.adf file. <br> <P> 0: 0000270A FFFFFC14 00000000 00000000 ~~'~~~~~~~~~~~~~<br> 16: 00000000 00000000 00016DAE 00000000 ~~~~~~~~~~m~~~~~<br> 32: 00000000 00000000 00000000 00000000 ~~~~~~~~~~~~~~~~<br> 48: 00000000 00000000 00000000 00000000 ~~~~~~~~~~~~~~~~<br> 64: 00000000 00000000 00000000 00000000 ~~~~~~~~~~~~~~~~<br> 80: 00000000 00000000 00000000 00000000 ~~~~~~~~~~~~~~~~<br> 96: 00000000 02020800 00373D42 5C5A4D31 ~~~~~~~~~7=B\ZM1<br> 112: 200A0108 0E1D4F89 9C9A9392 8C7E6653 ~~~~~O~~~~~~~fS<br> 128: 5151596D 83919290 868A8B87 807A7A7B QQYm~~~~~~~~~zz{<br> 144: 7C7A766F 64481D00 0406305F 6B6C6A5B |zvodH~~~~0_klj[<br> 160: 5D53513C 2D2D2732 24293F54 40354C55 ]SQ<--'2$)?T@5LU<br> 176: 67686258 514E4943 5859534A 41394D70 ghbXQNICXYSJA9Mp<br> 192: 75665659 66625A63 737A848E 9090979F ufVYfbZcsz~~~~~~<br> 208: 9F908C8F 8F96998E 8778685B 53536274 ~~~~~~~~~xh[SSbt<br> 224: 747B838A 8A8C8F92 8D979B94 8C8D9294 t{~~~~~~~~~~~~~~<br> 240: 8D8D8D8D 8C8B8989 8B8E908F 8E8E9092 ~~~~~~~~~~~~~~~~<br> 256: 90929394 989C9891 92939698 9B9B9C9C ~~~~~~~~~~~~~~~~<br> 272: 8E8E8F8F 8E8E8F90 898E918F 8B8A8E93 ~~~~~~~~~~~~~~~~<br> 288: 8B8D9093 94918C86 838DA1BC B7CEC9B0 ~~~~~~~~~~~~~~~~<br> 304: D4B0BB96 A0929E99 9797999B 9D9C9C9B ~~~~~~~~~~~~~~~~<br>Fields: <br> <P>Start Byte <br># of Bytes <br>Format <br>Name <br>Description <br>0 8 RMagic Magic Number (always hex 00 00 27 0A FF FF FC 14). 8 16 zero fill 24 4 MSB Int32 RFileSize Size of whole file in shorts (multiply by two to get file size in bytes). 28 72 zero fill 100, ... 2 MSB Int16 RTileSize Size of this tiles data measured in shorts. This matches the size in the index file, and does not include the tile size itself. The next tile starts 2*n+2 bytes after the start of this tile, where n is the value of this field. 102, ... 1 byte RTileType Tile type code indicating the organization of the following data (integer coverages only). 103, ... 1 byte RMinSize Number of bytes following to form the minimum value for the tile (integer coverages only). 104, ... (RMinSize bytes) MSB Int (var size) RMin The minimum value pixels for this tile. This number is added to the pixel values for each pixel in this tile (integer coverages only). I must stress that if RMinSize is less than 4 this is still a signed quantity. For instance, if RMinSize is 2, the value is 65536 - byte0*256 - byte1 if byte0 is > 127. 104+RMinSize, ... RTileSize*2 - 3 - RMinSize variable RTileData The data for this tile. Format varies according to RTileType for integer coverages. <P>The fields RTileSize, RTileType, RMinSize, RMin, and RTileData occur in the file for each tile of data present. They are usually packed one after the other, but this isn't necessarily guaranteed. The index file (w001001x.adf) should be used to establish the tile locations. Note that tiles that appear in the index file with a size of zero will appear as just two bytes (zeros) for the RTileSize for that tile. <br> <P>Raster SizeThe size of a the grid isn't as easy to deduce as one might expect. The hdr.adf file contains the HTilesPerRow, HTilesPerColumn, HTileXSize, and HTileYSize fields which imply a particular raster space. However, it seems that this is created much larger than necessary to hold the users raster data. I have created 3x1 rasters which resulted in the standard 8x512 tiles of 256x4 pixels each. <br> <P>It seems that the user portion of the raster has to be computed based on the georeferenced bounds in the dblbnd.adf file (assumed to be anchored at the top left of the total raster space), and the HPixelSizeX, and HPixelSizeY fields from hdr.adf. <br> <P>#Pixels = (D_URX - D_LRX) / HPixelSizeX <br> <P>#Lines = (D_URY - D_LRY) / HPixelSizeY <br> <P>Based on this number of pixels and lines, it is possible to establish what portion out of the top left of the raster is really of interest. All regions outside this appear to empty tiles, or filled with no data markers. <br> <P>RTileType/RTileDataEach tile contains HBlockXSize * HBlockYSize pixels of data. For floating point blocks The data is just the tile size (in two bytes) followed by the pixel data as 4 byte MSB order IEEE floating point words. For all integer tiles it is necessary to interpret the RTileType to establish the details of the tile organization: <br>RTileType = 0x00 (constant block)All pixels take the value of the RMin. Data is ignored. It appears there is sometimes a bit of meaningless data (up to four bytes) in the block. <br> <P>RTileType = 0x01 (raw 1bit data)One full tile worth of data pixel values follows the RMin field, with 1bit per pixel. <br> <P>RTileType = 0x04 (raw 4bit data)One full tiles worth of data pixel values follows the RMin field, with 4 bits per pixel. The high order four bits of a byte comes before the low order four bits. <br> <P>RTileType = 0x08 (raw byte data)One full tiles worth of data pixel values (one byte per pixel) follows the RMin field. <br> <P>RTileType = 0x10 (raw 16bit data)One full tiles worth of data pixel values follows the RMin field, with 16 bits per pixel (MSB). <br> <P>RTileType = 0xCF (16 bit literal runs/nodata runs)The data is organized in a series of runs. Each run starts with a marker which should be interpreted as: <br>Marker < 128: The marker is followed by Marker pixels of literal data with two MSB bytes per pixel. <br><br>Marker > 127: The marker indicates that 256-Marker pixels of no data pixels should be put into the output stream. No data (other than the next marker) follows this marker. RTileType = 0xD7 (literal runs/nodata runs)The data is organized in a series of runs. Each run starts with a marker which should be interpreted as: <br>Marker < 128: The marker is followed by Marker pixels of literal data with one byte per pixel. <br> <br>Marker > 127: The marker indicates that 256-Marker pixels of no data pixels should be put into the output stream. No data (other than the next marker) follows this marker. RTileType = 0xDF (RMin runs/nodata runs)The data is organized in a series of runs. Each run starts with a marker which should be interpreted as: <br>Marker < 128: The marker is followed by Marker pixels of literal data with one byte per pixel. <br> <p>Marker > 127: The marker indicates that 256-Marker pixels of no data pixels should be put into the output stream. No data (other than the next marker) follows this marker. This is similar to 0xD7, except that the data size is zero bytes instead of 1, so only RMin values are inserted into the output stream. <br> <P>RTileType = 0xE0 (run length encoded 32bit)The data is organized in a series of runs. Each run starts with a marker which should be interpreted as a count. The four bytes following the count should be interpreted as an MSB Int32 value. They indicate that count pixels of value should be inserted into the output stream. <br> <P>RTileType = 0xF0 (run length encoded 16bit)The data is organized in a series of runs. Each run starts with a marker which should be interpreted as a count. The two bytes following the count should be interpreted as an MSB Int16 value. They indicate that count pixels of value should be inserted into the output stream. <br> <P>RTileType = 0xFC/0xF8 (run length encoded 8bit)The data is organized in a series of runs. Each run starts with a marker which should be interpreted as a count. The following byte is the value. They indicate that count pixels of value should be inserted into the output stream. <br> <P>The intepretation is the same for 0xFC, and 0xF8. I believe that 0xFC has a lower dynamic (2 bit) range than 0xF8 (4 or 8 bit). <br> <P>RTileType = 0xFF (unknown)I have yet to deduce how this is organized, though it seems to be used for data with one bit of dynamic range. and presumably uses some sort of run length encoding. But it's operation is not obvious despite many hours, productions of hundreds of test files, and attempts to develop a dictionary of binary strings for different run values. <br> <P>hdr.adf - HeaderThis is a binary dump of the first 308 bytes of a hdr.adf file. <br> <P> 0: 47524944 312E3200 00000000 FFFFFFFF GRID1.2~~~~~~~~~<br> 16: 00000001 00000000 0000164E 3F800000 ~~~~~~~~~~~N?~~~<br> 32: 00000F00 F6180000 90060000 3603D601 ~~~~~~~~~~~~6~~~<br> 48: 6403E301 01000000 7620F808 43012B03 d~~~~~~~v ~~C~+~<br> 64: D6019903 E3012B03 D6019903 E301F7BF ~~~~~~+~~~~~~~~~<br> 80: 00007406 6E1FC2A4 7A370D00 0B004200 ~~t~n~~~z7~~~~B~<br> 96: 4E1654A4 00000000 00000000 00000000 N~T~~~~~~~~~~~~~<br> 112: 34A5A89D FF0414A5 A70F0002 00000000 4~~~~~~~~~~~~~~~<br> 128: 00000000 3C0B5F06 A8C05F06 08005AC0 ~~~~<~_~~~_~~~Z~<br> 144: 0A00E101 36035AC0 72085F06 FAA42F3C ~~~~6~Z~r~_~~~/<<br> 160: 0A001667 02000E00 A80B0200 08370200 ~~~g~~~~~~~~~7~~<br> 176: 0CA00200 9C0B0200 04370200 36A0E436 ~~~~~~~~~7~~6~~6<br> 192: 84000000 36A00200 5F063EA5 0883FF04 ~~~~6~~~_~>~~~~~<br> 208: 00008400 00000010 BD810200 5F010000 ~~~~~~~~~~~~_~~~<br> 224: 670E0000 5F01560E 4C4F0001 84008CA5 g~~~_~V~LO~~~~~~<br> 240: 28008F01 1000E00A 6628F7BF 4076FF04 (~~~~~~~f(~~@v~~<br> 256: 3FF00000 00000000 3FF00000 00000000 ?~~~~~~~?~~~~~~~<br> 272: C08FFC00 00000000 C0A1BF00 00000000 ~~~~~~~~~~~~~~~~<br> 288: 00000008 00000200 00000100 00000001 ~~~~~~~~~~~~~~~~<br> 304: 00000004 ~~~~ <br>Fields: <br> <P>Start Byte <br># of Bytes <br>Format <br>Name <br>Description <br>0 8 Char HMagic Magic Number - always "GRID1.2\0" 8 8 assorted data, I don't know the purpose. 16 4 MSB Int32 HCellType 1 = int cover, 2 = float cover. 20 236 assorted data, I don't know the purpose. 256 8 MSB Double HPixelSizeX Width of a pixel in georeferenced coordinates. Generally 1.0 for ungeoreferenced rasters. 264 8 MSB Double HPixelSizeY Height of a pixel in georeferenced coordinates. Generally 1.0 for ungeoreferenced rasters. 272 16 MSB Double Values somehow related to georeferencing. 288 4 MSB Int32 HTilesPerRow The width of the file in tiles (often 8 for files of less than 2K in width). 292 4 MSB Int32 HTilesPerColumn The height of the file in tiles. Note this may be much more than the number of tiles actually represented in the index file. <br> <p>296 4 MSB Int32 HTileXSize The width of a file in pixels. Normally 256. 300 4 MSB Int32 Unknown, usually 1. 304 4 MSB Int32 HTileYSize Height of a tile in pixels, usually 4. AcknowledgementsI would like to thank Geosoft Inc. for partial funding of my research into this format. I would also like to thank: <br> <P>Kenneth R. McVay for providing the statistics file format. <br>Noureddine Farah of ThinkSpace who dug up lots of datasets that caused problems. <br>Luciano Fonseca who worked out RTileType 0x01. <br>Martin Manningham of Global Geomatics for additional problem sample files. <br>Harry Anderson of EDX Engineering, for showing me that floating point tiles don't have RTileType. <br>Ian Turton for supplying a sample files demonstrating the need to be careful with the sign of "short" RMin values. </P> [此贴子已经被作者于2005-9-12 20:28:05编辑过]
|
|
|
|
8楼#
发布于:2005-09-12 20:27
<P>我想这个还不必用到数据格式的资料,呵呵,你利用irasterlayer等接口获取到一个ilayer,在map中打开就是了</P>
<P>不过你要看,偶这里有个Arc/Info Binary Grid Format的文件格式说明</P> <H2>File Set</H2> <P>A grid coverage actually consists of a number of files. A grid normally lives in it's own directory named after the grid. For instance, the grid <B>nwgrd1</B> lives in the directory <B>nwgrd1</B>, and has the following component files: </P> <P><PRE>-rwxr--r-- 1 warmerda users 32 Jan 22 16:07 nwgrd1/dblbnd.adf -rwxr--r-- 1 warmerda users 308 Jan 22 16:07 nwgrd1/hdr.adf -rwxr--r-- 1 warmerda users 32 Jan 22 16:07 nwgrd1/sta.adf -rwxr--r-- 1 warmerda users 2048 Jan 22 16:07 nwgrd1/vat.adf -rwxr--r-- 1 warmerda users 187228 Jan 22 16:07 nwgrd1/w001001.adf -rwxr--r-- 1 warmerda users 6132 Jan 22 16:07 nwgrd1/w001001x.adf </PRE> <P>Sometimes datasets will also include a prj.adf files containing the projection definition in the usual ESRI format. Grids also normally have associated tables in the info directory. This is beyond the scope of my discussion for now. </P> <P>The files have the following roles: <UL> <LI><a>dblbnd.adf</A>: Contains the bounds (LLX, LLY, URX, URY) of the portion of utilized portion of the grid. <br> <LI><a>hdr.adf</A>: This is the header, and contains information on the tile sizes, and number of tiles in the dataset. It also contains assorted other information I have yet to identify. <p> <LI><a>sta.adf</A>>: This contains raster statistics. In particular, the raster min, max, mean and standard deviation. <p> <LI><B>vat.adf</B>: This relates to the value attribute table. This is the table corresponding integer raster values with a set of attributes. I presume it is really just a pointer into info in a manner similar to the pat.adf file in a vector coverage, but I haven't investigated yet. <p> <LI><a>w001001.adf</A>: This is the file containing the actual raster data. <p> <LI><a>w001001x.adf</A>: This is an index file containing pointers to each of the tiles in the w001001.adf raster file.</LI></UL> |
|
|