NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
> > > Yuan: > > > > > > Here are some answers to your questions, but it might get confusing! > > > > > > With regards to why I am loading the zip, it's because I cannot get > > > some of the .shp file to plot at all. I'm not sure why this particular > > > shape file is so problematic. I have others from other sources that > > > plot just fine. That being said, I have used .zip files in the past > > > because it allows for filtering, etc. > > > > Jim, > > In many .shp files, the attribute format (.dbf) and index format (.shx) are > > included. They can also be separated. Those shp files you were loading into > > the IDV obviously have separated style. > > > > Jim, > See the attached image, the rad boundary line is from the KMZ file, and the > green is from the shapefile. The problem of the position of the shape file is > due to the projection. The CDM library uses the Transverse_Mercator > projection which has the fix earth radius. After checking with John and Jeff, > we move to use the UTM, and the position is corrected. > Another mystery is why the SkiLifts shape file not working. According to > Jeff, the IDV only parse some shape from the .shp file and causing the > mismatch with .dbf file. One quick solution is to remove the .dbf file inside > the zip file. But I am going to explore the other solution to make it easier > for user like you. > > Now, with all these answers and efforts I put in, are you going to send us > free lift tickets? :) > > > Yuan I forgot the attached file. Y > > > > > > In the case of the attached with IDV3.0u3, the SkiAreaBoundries > > > plot (in the wrong location) if I go to Data>Choose Data and load in the > > > zip file. > > > > This likely be a bug in the IDV, I still try to rule out the possibility of > > the precision of the data itself. > > > > If I instead try to load in just the .shp file, I cannot get > > > it to plot successfully either via Data>Choose Data or if I try to add > > > it as a map. > > > > > > As you know, the data here is plotted in the wrong location. In the > > > attached, I used the kmz file I sent earlier to plot the data using > > > IDV2.9u2 (note that IDV3.0u3 cannot read the kmz file) and the shapes > > > are plotted in the correct location. I've used terrain shading so you > > > can get an idea of where they should be. > > > > IDV 2.9 and 3.0 should behavior the same. There is no changes since 2.8 in > > this portion of the source code. I figure out the problme, the IDV tried > > to write a file named doc.xml in the location it has no permission. I will > > check in a fix soon. > > > > > > > > For what it is worth, I've downloaded .shp and .zip files from > > > other sites whereby IDV has struggled and is unable to plot the data. > > > Download the lesson at > > > http://edcommunity.esri.com/arclessons/lesson.cfm?id=397 and see if you > > > can plot the various data for Colorado. Perhaps this is like netCDF > > > where not all netCDF files are "created equal." > > > > > > > I will give it a try. > > > > > > Yuan > > > Jim > > > > > > > > > > > > Ticket Details =================== Ticket ID: GDP-431455 Department: Support IDV Priority: Normal Status: Open
Attachment:
jim.png
Description: PNG image
