OASIS Emergency Management TC

 View Only

RE: [emergency] RE: OGC UoM Best Practices guidance

  • 1.  RE: [emergency] RE: OGC UoM Best Practices guidance

    Posted 04-03-2006 15:38
     MHonArc v2.5.0b2 -->
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    

    emergency message

    [Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


    Subject: RE: [emergency] RE: OGC UoM Best Practices guidance


    Gary -
    
    I believe that we are in violent agreement! Just stating things a bit
    differently :-) This is why I suggested that the correct approach - as you
    are suggesting - is both bottom up and top down.
    
    Also, thanks for support of OGC standards. Perhaps - to help make life a
    bit easier for those implementing OGC standards, we have just released
    (not even announced yet) a new community resource called OGCNetwork.
    Anyone can register and participate. The Network vision is to help solve
    the issues you have so correctly identified.  www.ogcnetwork.net . Check
    it out. It is fledgling but collaboration is already beginning.
    
    Cheers
    
    Carl
    
    
    > Carl,
    >
    > I am not arguing against you or the need for better standards.  We, in
    > the DM program are using OGC standards for Web Map services.  We are
    > also committed to building to the standards of both the EM-TC and NIEM.
    > And we are not just "compliant."  I.e., using three tags, and claiming
    > compliance.  We are trying to build real interoperability.  But real
    > interoperability takes more than a mandate. It takes real acceptance of
    > that mandate.  And no matter who is running the show, developer
    > acceptance will be required for real acceptance. It is all a matter of
    > morale.  Just like in the military, where Generals run the show, but
    > troop morale and the fit of the equipment to the capability and training
    > of the troops is a major factor in success.
    >
    > Top down mandates can work, but only if they are CLEARLY EXPLAINED and
    > marketed effectively.  And then, they must actually work as advertised
    > and not be so complicated that long-term costs are actually increased.
    > Commercial firms use internal standards because they keep costs down.
    > They use external standards if they can make more money by doing so. If
    > the government mandates a standard, one of two conditions are required
    > before the firm will start implementation:
    >
    > 1. They can bill cost plus. Even if it does not work, they make money.
    > This is the normal practice of the Federal integrators. For them,
    > failure is no big problem, since real success in Federal systems usually
    > about a 50-50 situation anyway (and often that success has less do with
    > the technology than politics, so technology risk is often ignored). As a
    > result, there has been a lot of money frittered away (I am thinking
    > personally of a couple of programs for the Army Reserve, but there are
    > lots of others. Think of all of the systems that "built" using the DoD
    > data model.)
    >
    > 2. They think they can sell more of their packaged software because
    > standards compliance can expand their marketplace. In this case a
    > mandate can motivate a vendor into doing standards to maintain or
    > increase market share or enter new markets, so long as complications
    > from the standard do not increase costs or competition to the point that
    > profits are reduced in spite of the mandate.
    >
    > So, my mission is to keep the costs of interoperability down in order to
    > widen the playing field and encourage more and more vendor
    > participation.  For that reason, anything that appears complicated
    > scares me a bit.  That said, the world is complicated, and many of our
    > systems are complicated. So, many of our system-to-system communication
    > has to be complicated.  But, the more complicated it is, or even appears
    > to be, the slower true interoperability will happen.  If we do not keep
    > that fact in mind as we go about our work, we will be far less
    > successful than we could otherwise be.  I know I sound like a broken
    > record on this issue. But, since my talents are closer to yours than the
    > people you actually need to convince, I sincerely think that my "simple
    > solution first" approach has merit. I am not against complication, I am
    > just against starting with it.
    >
    > That said, I have no quarrel GML.  I am going to take a couple of the
    > GML examples you sent me in the document and work them into content
    > object in the DE as illustrations of how it can be done. (I already have
    > a GML point example, but need to do some documentation.)
    >
    >
    > Gary A. Ham
    > Senior Research Scientist
    > Battelle Memorial Institute
    > 540-288-5611 (office)
    > 703-869-6241 (cell)
    > "You would be surprised what you can accomplish when you do not care who
    > gets the credit." - Harry S. Truman
    >
    >