OASIS Emergency Management TC

 View Only

Geospatial issues (was Re: [emergency] CAP-related Comments)

  • 1.  Geospatial issues (was Re: [emergency] CAP-related Comments)

    Posted 10-16-2003 01:19
     MHonArc v2.5.0b2 -->
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    

    emergency message

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


    Subject: Geospatial issues (was Re: [emergency] CAP-related Comments)


    In addition to supporting Carl's comments below, I should point out 
    that both the lat/lon order and digital-degree format questions are 
    addressed in the Implementation Notes, which currently appear as 
    Section 3.3 within the specification document.
    
    - Art
    
    
    At 11:56 AM -0600 10/15/03, Carl Reed wrote:
    >Walid -
    >
    >In terms of your identified issues WRT geospatial:
    >
    >Issue 1: Well, treat it as it is - no data. Could return an 
    >exception to the sender, but it is possible the sender does not have 
    >either geocode information or the ability to process geometry.
    >
    >Issue 2. In an informal correspondence with Art, I spoke a bit about 
    >the use of WGS 84 and EPSG code (in terms of section 3.3.1). In the 
    >mapping and geospatial industry, the de-facto default for expressing 
    >coordinates in WGS 84 is lat/long (y,x). If the EPSG code and 
    >normative database is used, the coordinate order is explicitly 
    >specified by the EPSG database as lat/long. Perhaps we simply need a 
    >note in the document in section 3.3.1.
    >
    >Issue 3. Why restrict in any way? As long as it is not mandatory, 
    >one can always insert a <null> for this field. Just need to clarify 
    >this in the document (a sentence or two). I would actually like it 
    >see it as very flexible as there are many normative vocabularies for 
    >geocodes/gazetteer in the world. FYI, in the GIS world, geocode 
    >typically means an address and geocoding is the process of 
    >transforming an address into an (ax,y) coordinate. A 
    >gazetteer takes as input a place name or landmark and returns 
    >metadata and at a minimum a point geometry. I am not suggesting 
    >major changes now - just some clarification in the current document 
    >and perhaps increased flexibility in the future.
    >
    >Issue 4: I am not sure this is an issue. If the server provides a 
    >geocode but the client cannot process, is there really an issue? If 
    >the geometry (polygon/circle etc) is known to be WGS 84 and lat/long 
    >a client could still accept this data, process it, and render it on 
    >some device. Now, if the client cannot process either a geocode or 
    >the geometry, well that is different situation. I am not sure we can 
    >solve that one!
    >
    >Issue 5: As I mentioned above, if EPSG is used as your normative 
    >reference, then the coordinate order AND coordinate expression are 
    >specified in the EPSG database.  There are 2 EPSG codes (database 
    >entries) for WGS 84. The original database entry specified DD MM 
    >SS.SS. The new version of the database (out soon) will also specify 
    >a second entry for WGS 84 that has a coordinate expression of 
    >decimal degrees. This was done to meet the requirements of the OGC 
    >membership.
    >
    >Regards
    >
    >Carl
    >
    >
    >