[IDV #GDP-431455]: Shape file challenges

> 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