[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

20050610: IDV - Visualizing IP-Addresses

>From: =?ISO-8859-15?B?VG9yc3RlbiBN/GxsZXI=?= <address@hidden>
>Organization: privat
>Keywords: 200506092254.j59Ms7Zu015925 IDV station data

Hi-

>US> Wow, what an inventive use of the IDV.
>
>We feel honored ;o)

You should!

>US> We are totally reworking the netCDF underpinnings for point data in
>US> the IDV for the next release, so your question is timely.
>
>Any time schedule for this? (we have to finish our project until
>mid-july, so maybe  it won't help.)

We will have a release candidate of sorts available later this week
which will be announced on the idv-users and idv-developers list.  
If you are not on those lists, I can send you a pointer to the
release.  Since we reworked a lot of the netCDF stuff, we are 
not making this available through the downloads, but through
some other web links.  The full release will be out in August.

>Station data seems to do the job (i will try this tomorrow). Today I
>experimented with Jython/Visad, so maybe this will do everything we need 
>(we inform you on success).

>I attached some Screenshots of dumpType and CDF for an example file
>(also attached) with dummy-data (we have more info to put into ...), 
>maybe this sheds light on our issue.
>
>We analyzed the Geon IDV package to see how modifications to IDV can be
>used. Based on their earthquake locations, our idea was using Point-Plots to p
> ut our monitored servers(called
>trackers by bittorrent) on the globe, sizing them by the number of
>connected clients (called peers by bittorrent), and collecting data
>about trackers over time.
>At different timestamps there a different numbers of peers, which also
>should be displayed at their geographical position (display of
>connections to trackers should be resolved by a station-model which
>connects them via lines (both in 2D and 3D)).
>Other dimensions (other than recNum) could be safely included in our
>file and were thought to be used as additional information. Maybe
>structs will do this also.

>Problems: Point-Data-Models can read more dimensional-files, but show
>only the (single)dimensioned variables of recNum. So we got our data
>into IDV, but could not access all of them to manipulate them further
>(visualize some informations like countries from which data were
>downloaded or which files were the most downloaded in different
>catageries, or which Tracker serves a lot of one type, ..)
>[maybe jython will solve this, see above).
>
>The Visad foundation of IDV and the inclusion of jython as well as the use of
>shared data and a lot of sources for maps were seen as a good starting
>point for future improvements of our monitoring-software.
>
>Hope my english was good enough ;)

Extremely good.  Much better than my German (which is 
non-existent). ;-)

>Another question has evolved: How can I access my main display in
>jython/java to draw some lines in it?

There is a drawing control in the IDV and you can save off the
drawings in an XML file.  Perhaps you could use that structure to
define your lines and display it that way.

Otherwise, there is not that type of connection between Jython
and the IDV to get that info.

>And some more: I don't think it's possible to access my main display
>with jython. Proposal: include selection of existing displays in the
>display chooser when using formulas

Thanks for the suggestion.  I'll have to think about that first.
Right now, it is selected manually by choosing the last selected
window.

>I think the best approach to this is to write a new
>netcfdPointData.subclass, maybe you can tell me how and where to
>register this class (an XML-File maybe??).

You could read in the data using visad.data.netcdf.Plain which
will give you a generic structure for the netCDF file (which
is what we do now).  Then we convert the the resulting 
VisAD data object into a FieldImpl of 
ucar.unidata.data.point.PointObTuple-s.  You could use Jython
to open the file, and create the various PointObs you need for
your application, including the multi-dimesioned field.

If you want to write your own subclass, you would just need
to add a reference to it in datasources.xml.  You could
put this in your ~/.metapps/DefaultIdv directory.  The file
would look like:

<?xml version="1.0" encoding="UTF-8"?>
<datasources>
  <datasource
     id="FILE.BITSONAR"
     factory="my.package.MyOverriddenClass"
     patterns=".*trackerlist_gps.nc$"
     fileselection="true"
     label="Modified BitSonar Data"/>
<datasources>

Then the IDV will pick that up as a valid data source and you
will see it in the list of Data Source Types.

>By further delving into the classes of IDV I recognized the following:
>By using a variable called "time" in a netcdffile, while loading this
>as Point Data, this variable is transformed into "Time" (so the later
>check for timeVal:"time" has no chance to resolve it).
>I am not sure if this is a bug or a feature.

A feature, of course. ;-)  Once it finds one of the predefined
time values, it does not look any further.  The new station data
format lets you list which time should be used.

I'm not sure I've addressed your multi-dimension question, but
hopefully the information above will help.  If you have more
questions, please ask.

Don Murray
NOTE: All email exchanges with Unidata User Support are recorded in the
Unidata inquiry tracking system and then made publicly available
through the web.  If you do not want to have your interactions made
available in this way, you must let us know in each email you send to us.