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
>
>
>