|
|
| GeoCommunity Mailing List |
| |
| Mailing List Archives |
| Subject: | RE: GISList: NIMA VMAP 1 request problems |
| Date: |
08/22/2002 08:03:53 AM |
| From: |
Fass, Jim |
|
|
Dear Dimitri,
I thought your diatribe against NIMA was an interesting read, and I have no
insider knowledge to refute any of your claims regarding the motivation
behind NIMA's policy.
I do, however, have some technical insight into what might make the
re-tiling of VMAP1 (or any VPF product) more than a trivial exercise in
appending and splitting by country boundary.
1) The VPF data structure was designed with robust facilities for
multi-level metadata. This means that there are places in the database to
describe data "lineage" (where the information came from and what happened
to it) at the feature level, the theme level, the tile level and the dataset
level. I imagine that metadata at the feature level would survive an purely
unsupervised re-cutting of the data, but metadata at higher levels would
need to be rewritten. Because the metadata at the tile level contains
essays about the data sources--their vintage, security classification,
distribution restrictions, etc. etc.--Rewriting the metadata requires the
attention of a relatively senior-level person with the authority to make
judgments about the sanitization of data prepared at some considerable
expense under secure conditions. It cannot be automated, as you suggest, in
a process requiring only a few minutes of anybody's software, unless we want
to make the case that the VPF metadata should be discarded.
2) Another consideration is that the tiling structure of VMAP1 is part of
the product specification. The VPF specification works on two levels: there
is a general specification for all VPF products, and then there is a series
of product specifications for things like VMAP1. The product specification
prescribes which levels are valid, what tiling scheme to use, etc. It would
be fair for any application configured to edit VMAP1 to also make
assumptions about the standard tiling scheme. Perhaps not ideal--since we
are accustomed to being empowered to change tiling schemes in other GIS
products--but "fair" in the sense that a product that violates the
prescribed tiling scheme would no longer "be" VMAP1.
I make no pretense to speak on NIMA's behalf, or even to understand their
policies. I only mention these points as a possible explanation for why the
reprocessing of the data is not a trivial matter.
--jim
James C. Fass
Program Director
Analytical Surveys, Inc.
11900 Crownpoint Dr., Suite 100
San Antonio, TX 78233
(210) 657-1500 x215
FAX (210) 657-1304
jfass@anlt.com
-----Original Message-----
From: Dimitri Rotow [mailto:dar@manifold.net]
Sent: Wednesday, August 21, 2002 8:23 PM
To: GISList: IMAGRS-L
Subject: RE: GISList: NIMA VMAP 1 request problems
> I wanted to relate my latest escapades with NIMA to see if anyone
> out there
> can provide some advice. For the last year-and-a-half I have been
> trying to
> get access to 4 CDs of VMAP1 data over Vietnam, Cambodia, and
> Laos through a
> Freedom of Information Act (FOIA) request. Most of that time consisted of
> NIMA saying those data were currently available from USGS and me telling
> them that they were not.
Yes. A typical holding pattern tactic that is a constructive denial of your
FOIA request.
> This past May they acknowledged those data could
> not be released to the public because they contain foreign-owned
> source data
> over China and Thailand with the proviso that they can only be
I'd love to see a copy of that letter, to see what their exact wording was.
To date, they had avoided pinning themselves down in writing on this
assertion.
> used by U.S.
> Dept. of Defense activities. The data for Vietnam, Cambodia, and
> Laos do not
> have these restrictions but since they are on CD with restricted data the
> entire CD is restricted.
>
>
Good for you! You are to be commended for sticking with your project in the
face of a determined bureaucratic effort to evade the requirements of FOIA.
This is a typically NIMA response, in that they are
a) lying to you
and
b) using their internal bureaucratic processes as an excuse to violate
federal law (FOIA). There is no part of FOIA that says willfully stupid
agency management is a valid excuse to ignore the law.
They are lying to you on several fronts:
1) It is deceptive for them to deny you data sets under the excuse "they
contain foreign-owned source data over China and Thailand with the proviso
that they can only be used by U.S. Dept. of Defense activities." There are
strict requirements in the law to exclude data. I've been told by NIMA
insiders that these do not apply because of the way the data was acquired,
but that NIMA is using the excuse nonetheless.
2) Even if one accepts the red herring excuse above, unless they
specifically enumerate the data that is and is not covered by the claimed
exemption they are not being responsiv
|
|
Sponsored by:
For information
regarding
advertising rates
Click Here!
|
