Geographical Extent

[wznira]

There seems to be a consensus that "Geographical Extent" can be specified either as a thing (e.g. an airport or an FIR) or a shape (e.g. a polygon). For example,

• From the draft SWIM Manual - "Guidance: Geographical coverage may be expressed in terms of ICAO region, FIR, Aerodrome, polygon/geobox, etc."
• Similarly, W3C defines two related concept: Geospatial Thing and Geometry

It seems the first approach ("Geographical Extent" as a Thing) can be accomplished easily by treating it as another Service Category Taxonomy. For example, in JSON,

"service-description": {
   "profile": {
      "service-id": "http://nsrr.faa.gov/services/fps",
      "name": "Flight Plan Service (FPS)",
      "description": "(This fictitious service is for instructional use only and cannot be consumed) A service for filing, updating, or canceling an IFR (Instrument Flight Rules) flight plan.",
      "version": "1.0.0",
      "service-category": [
         {
            "taxonomy": "http://semantics.aero/service-category",
            "code": "http://semantics.aero/service-category#flight"
         }
      ],
"geographical-extent": [
   {
       "taxonomy": "http://semantics.aero/geographical-extent",
       "code": "http://semantics.aero/icao-region/nam"
   },
   {
       "taxonomy": "http://semantics.aero/geographical-extent",
       "code": "http://semantics.aero/icao-region/asia"
   }
],
... ...

For the second approach, the easiest way seems to be referencing the "Geometry" class defined in OGC GML as shown in the UML diagram below-

[wznira]

From Carol Uri - I agree that there can be one or more taxonomies based on such standards as ICAO Region (https://semantics.aero/icao-region), ISO 3-letter country code, ICAO Flight Information Region (FIR), or other standard lists that are maintained by some authority. There are any number of other features that could theoretically be captured (cities, airports, etc.) If the purpose is to help consumers find services, maybe this is a question to pose to the SWIFT community; what do you think? They might be flattered to help.

[wznira]

From @mkaplun -

At conceptual level I would suggest:

Geographical Extent is a service attribute and is a part of a Service Profile.

It probably Abstract and may be either an Identifiable Area, or a Geometry.

Both attributes should be associated with some standards. Those standards could be either predefined lists of values (e.g. ICAO list of airports) or specifications describing how the Geometry is coded (e.g. GeoGSON).

So at a high conceptual level it may look like the attached. (I was thinking about defining a Bounding Box instead of Geometry – what else could it be? But then I thought about a Weather Coverage.)

[wznira]

I like @mkaplun's approach. However, I would still think it would be good to have the "Identifiable Area" values from predefined taxonomies instead of just a list of values. In fact, there may even be redefined "Geometry" for certain geographical areas. For example, Washington DC Air Defense Identification Zone (ADIZ). So, would the following work?

[wznira]

From @mkaplun - When I said “predefined list of values”, I meant a taxonomy, an ICAO or ISO dataset (which is not usually referred as a taxonomy), and similar (for example “USA”, standard “ISO-3166-1”). I use the term “standard”, the way it is used in APAC governance papers: anything that approved by consensus or a standard-producing body.

I see identifying those sets as the next step after defining conceptual model.

(Maybe we should replace “Protocol” class by “Standard” in SDCM.)

[wznira]

From Carol Uri - I like @mkaplun's Identifiable Area and Geometry concepts for Geographical Extents. Also, I wouldn't limit them to 0 or 1. As Mark says, there are many classification schemes for geographical areas or locations that are maintained as a "standard" by some authority. For FAA SWIM purposes, we could allow service publishers to specify the standard(s) they are using and classify their services' geographical extent by any or all of them: e.g., the service operates in the USA as defined by ISO3166, NAM region as defined by ICAO, airports DCA/BWI/IAD as defined by IATA Location ID Codes, etc. We could also allow them to define geometrical areas using various "standard" methods (which I don't know anything about 😊)

[mkaplun]

I suggest following class architecture already established in the SDCM 2.0. Another idea -- somewhat different from what I suggested before -- is to have all attributes in one class similarly to the Profile class. For example: where: name - any name that may be used to describe the extent (e.g. Brazil), description - description of the extent in a natural language (e.g., Aerospace of Federative Republic of Brazil) (optional) id - code that may be defined in some standard list (e.g., BRA)(optional) The code can also be a URI that points to some element of existing (and accessible) taxonomy. geometry - that may be used to describe the extent (e.g., bounding box, or polygon)(optional) source - a standard that defines a list of values used in the id field (e.g., ISO 3166-1 alpha-3) or how a value in the geometry field is calculated.

[wznira]

I agree that this will work.

Next question: I think a Profile should have zero or more GeographicalExtend.

On Thu, Nov 18, 2021 at 10:53 AM mkaplun @.***> wrote:

I suggest following class architecture already established in the SDCM 2.0. Another idea -- somewhat different from what I suggested before -- is to have all attributes in one class similarly to the Profile class. For example: [image: Geographical Extent class 4] https://user-images.githubusercontent.com/91625618/142448808-1c204634-b864-4edc-9701-bdce3ae4d082.png where: name - any name that may be used to describe the extent (e.g. Brazil), description - description of the extent in a natural language (e.g., Aerospace of Federative Republic of Brazil) (optional) id - code that may be defined in some standard list (e.g., BRA)(optional) The code can also be a URI that points to some element of existing (and accessible) taxonomy. geometry - that may be used to describe the extent (e.g., bounding box, or polygon)(optional) source - a standard that defines a list of values used in the id field (e.g., ISO 3166-1 alpha-3) or how a value in the geometry field is calculated.

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/faa-swim/sdcm/issues/1#issuecomment-972995416, or unsubscribe https://github.com/notifications/unsubscribe-auth/AG2NNSB5INCH6WDFMX7ARMLUMUOQHANCNFSM5IE7ZJHA .