[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[IDV #GDP-431455]: Shape file challenges
- Subject: [IDV #GDP-431455]: Shape file challenges
- Date: Fri, 29 Jun 2012 15:09:28 -0600
> 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