This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
> Yuan: > > That's great news. This is a prime example of reducing "data > friction." Nice work. > > Jim > Jim, You can try the nightly release now. I think I have fixed all your problem. Otherwise, Let us know. Yuan > On 6/26/12 4:21 PM, Unidata IDV Support wrote: > >> Yuan: > >> > >> Thanks for looking into all these issues. This kmz/shape file > >> stuff is more complicated than I would have thought! > >> > >> Are these changes that you will eventually implement into the IDV? > >> Is there anything I can do from my end? > > Jim, > > I have checked in all the changes and I am waiting for John's CDM > > release. You don't need to do anything. I will let you know when it is > > ready in the nightly release. > > > > > > Yuan > >> With regards to lift tickets, when you come to Utah, give me a call. > >> > >> Jim > >> > >> On 6/26/12 11:57 AM, Unidata IDV Support wrote: > >>>>> 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 > >>>>> 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 > >>> > >> > >> > > > > Ticket Details > > =================== > > Ticket ID: GDP-431455 > > Department: Support IDV > > Priority: Normal > > Status: Open > > > > > Ticket Details =================== Ticket ID: GDP-431455 Department: Support IDV Priority: Normal Status: Closed