Please post your suggestions and recommendations for this addendum.

In response to "Update to Light Name Table", with respect to support of FAA level D airports, we would like to request clarifications, additions, and/or corrections for the following light types:

References:

AC - FAA Advisory Circular AC 150-5340-30D

AIM - FAA Aeronautical Information Manual

As a general comment, we would like to distinguish between elevated and in pavement lights since their real world intensities, directionality, and sizes are appreciably different.

1. Runway guard (AC 4.4, AIM 2-1-10-d):

Taxiway\Runway_Guard 415

Taxiway\Guard\Type[1-4]_Light 418-422

It is unclear what distinguishes these types. They are all listed as omni-directional, non-flashing, white lights when they should be uni-directional, yellow, flashing lights.

2. Stop bar (AC 4.5.a)

Taxiway\Stop_bar_Light 416

These are red, not green lights.

3.) Taxiway Centerline (AC 4.3.b.1-3)

Taxiway\Centerline 406-408

Taxiway\Lead-on_Light 413

No yellow light types are available. Why have a lead-on type without a lead-off type?

Also in support of FAA level D airports, we request additions and/or clarifications in order to attribute the following standard lineal and areal airport features, none of which appear to be representable within the bounds of the CDB specification:

References:

AC - FAA Advisory Circular AC 150/5340-1J

AIM - FAA Aeronautical Information Manual

As a general comment, it would seem that a hierarchical attribution scheme, similar to the one for lights, would fit better with the CDB philosophy. It would also alleviate the need for an exhaustive classification list in order to have a basic representation of any marking.

5.3.1.9.1 Airport Lineal Features Components

1.) Enhanced taxiway centerline markings (AC Section 3 21.e, AIM 2-3-4.b.2)

Note that these might be better represented as areals because properly handling convergence (AC Appendix 3 Figure C-2) in a run-time publisher may be difficult.

2.) Dashed taxiway edge markings (AC Section 3 22.2, AIM 2-3-4.c.2)

3.) Non-movement area boundary markings (AC Section 4 38, AIM 2-3-6.c)

4.) Vehicle roadway markings (AC Section 4 36, AIM 2-3-6.a)

Non-zippered white markings could be represented by "AF Generic Markings - Road Mark" areals, but areals are not the ideal shape type for these features.

5.3.1.9.2 Airport Areal Features Components

1.) Surface painted signs (AC Section 3 26-30, AIM 2-3-4.e-f, 2-3-5.3.d)

2.) Geographic position markings (AC Section 3 32, AIM 2-3-4.g)

3.) AF Elevation Constraint - Elevation Constraint

We request usage clarification. This feature seems ideal for representing exact runway and/or taxiway elevation profiles, as well as other important airport elevation features such as drainage ditches, tunnel entrances, etc. that are problematic to represent in courser regular grid LODs. This feature is part of the specification, yet it is completely undefined in its format and intended use.

4.) VOR receiver checkpoint markings (AC Section 4 37, AIM 2-3-6.b)

5.) Marking of permanently closed taxiways (AC Section 4 40, AIM 2-3-6.d)

Should temporarily closed runways and taxiways also be covered including light types for same?

Note that this post together with the previous one on lights should not be considered an exhaustive evaluation of the CDB specification with respect to the cited references. The issues above are only the set we have encountered thus far in our attempts to represent FAA level D airports in CDB.

Here are some proposed solution for the requests raised in regards to:

a) Enhanced Taxiway Centerline Markings

b) Dashed taxiway edge markings

c) Non-movement area boundary markings

d) Vehicle roadway markings

e) Permanently closed taxiways

We'll need to look at this further before we propose any solution:

a) "Surface Painted Signs"

b) "Geographic position markings"

We will also continue the evaluation in regards of the elevation constraints. We do agree that the specification offers no details on how to use this and we will propose a solution soon.

------- Proposed solutions -------------

1. We do not have an Airport Lineal Feature for "Enhanced Taxiway Centerline Markings" (AC Section 3 21.e, AIM 2-3-4.b.2). We should add this to our list of Airport Lineal Features as follows:

CNAM = "AFL Taxiway Markings" and APFN = "Enhanced Centerline"

It is mentioned that an area would be better handled to "properly handle convergence". Can you clarify what you mean by this?

2. We do not have an Airport Lineal Feature for "Dashed taxiway edge markings" (AC Section 3 22.2, AIM 2-3-4.c.2). We should add this to our list of Airport Lineal Features as follows:

CNAM = "AFL Taxiway Markings" and APFN = "Dashed Edge Line"

3.) We do not have an Airport Areal Feature for "Non-movement area boundary markings" (AC Section 4 38, AIM 2-3-6.c). These markings delineate the movement area, i.e., area under air traffic control. These markings are yellow and located on the boundary between the movement and nonmovement area. The nonmovement area boundary markings consist of two yellow lines (one solid and one dashed) 6 inches (15cm) in width. The solid line is located on the nonmovement area side while the dashed yellow line is located on the movement area side. We should add this to our list of Airport Lineal Features as follows:

CNAM = "AF Other Markings" and APFN = "Non-movement Area Bundary "

4.) We do not have an Airport Areal Feature for "Vehicle roadway markings" (AC Section 4 36, AIM 2-3-6.a). The vehicle roadway markings are used when necessary to define a pathway for vehicle operations on or crossing areas that are also intended for aircraft. These markings consist of a white solid line to delineate each edge of the roadway and a dashed line to separate lanes within the edges of the roadway. In lieu of the solid lines, zipper markings may be used to delineate the edges of the vehicle roadway. We should add this to our list of Airport Lineal Features as follows:

CNAM = "AFL Generic Markings" and APFN = "Vehicle_Roadway_Line_Solid"

CNAM = "AFL Generic Markings" and APFN = "Vehicle_Roadway_Line_Zippered"

8.) We do not have an Airport Areal Feature for "Permanently closed taxiways" (AC Section 4 40, AIM 2-3-6.d). Yellow crosses are placed at each end of the runway and at 1,000 foot intervals. We should add this to our list of Airport Lineal Features as follows:

CNAM = "AF Taxiway Markings" and APFN = "Closed Taxiway"

---------- Items needing more evaluation/analysis ----------------

5.) We do not have a means to represent "Surface Painted Signs" (AC Section 3 26-30, AIM 2-3-4.e-f, 2-3-5.3.d). Surface painted taxiway direction signs have a yellow background with a black inscription, and are provided when it is not possible to provide taxiway direction signs at intersections, or when necessary to supplement such signs. These markings are located adjacent to the centerline with signs indicating turns to the left being on the left side of the taxiway centerline and signs indicating turns to the right being on the right side of the centerline.

NOTE it is difficult to fold-in the full generality of signage with the currently provided mechanism for surface detail. In all likelyhood, we need to point to a small OpenFlight model. SOLUTION IS TBD

6. We do not have an Airport Areal Feature for "Geographic position markings" (AC Section 3 32, AIM 2-3-4.g). The geographic position marking is a circle comprised of an outer black ring contiguous to a white ring with a pink circle in the middle. When installed on asphalt or other dark-colored pavements, the white ring and the black ring are reversed, i.e., the white ring becomes the outer ring and the black ring becomes the inner ring. It is designated with either a number or a number and letter. The number corresponds to the consecutive position of the marking on the route.These markings are located at points along low visibility taxi routes designated in the airport's Surface Movement Guidance Control System (SMGCS) plan. They are used to identify the location of taxiing aircraft during low visibility operations. Low visibility operations are those that occur when the runway visible range (RVR) is below 1200 feet(360m). They are positioned to the left of the taxiway centerline in the direction of taxiing. (See FIG 2-3-12). They are positioned to the left of the taxiway centerline in the direction of taxiing. (See FIG 2-3-12.) The geographic position marking is a circle comprised of an outer black ring contiguous to a white ring with a pink circle in the middle. When installed on asphalt or other dark-colored pavements, the white ring and the black ring are reversed, i.e., the white ring becomes the outer ring and the black ring becomes the inner ring. It is designated with either a number or a number and letter. The number corresponds to the consecutive position of the marking on the route.

NOTE it is difficult to fold-in the full generality of signage with the currently provided mechanism for surface detail. In all likelyhood, we need to point to a small OpenFlight model. SOLUTION IS TBD

7) We do not have an Airport Areal Feature for "VOR receiver checkpoint markings " (AC Section 4 37, AIM 2-3-6.b)). The VOR receiver checkpoint marking allows the pilot to check aircraft instruments with navigational aid signals. It consists of a painted circle with an arrow in the middle; the arrow is aligned in the direction of the checkpoint azimuth. This marking, and an associated sign, is located on the airport apron or taxiway at a point selected for easy access by aircraft but where other airport traffic is not to be unduly obstructed. .

NOTE it is difficult to fold-in the full generality of signage with the currently provided mechanism for surface detail. In all likelyhood, we need to point to a small OpenFlight model. SOLUTION IS TBD

This post is to answer the questions in regards to the "Update to Light Name Table".

a) First question: We have in our Light Name table, 5 occurances of "runway guard lights", ie. type 1 to 4 plus a generic runway guard light. There is nothing that says what differentiates them. After further investigation, there is no need for the four types of Guard lights. The outcome of this is that the current Runway_Guard light type remains as follows:

i) Airport_Lighting\Taxiway\Runway_Guard: light number 415

The following four Guard light types are deprecated. There are no compatibility issues since the contents of Lights.xml is the same for each of these light types.

ii) Airport_Lighting\Taxiway\Guard\Type1_Light: light number 418

iii) Airport_Lighting\Taxiway\Guard\Type2_Light: light number 419

iv) Airport_Lighting\Taxiway\Guard\Type3_Light: light number 420

v) Airport_Lighting\Taxiway\Guard\Type4_Light: light number 421

b) Second question: Our Light Name table indicates that Airport_Lighting\Taxiway\Stop_Bar_Light is a green light, whereas the ccbrianf is saying it is red. The AC-FAA Advisory Circular AC 150-5340-30D also says it is red. The contents of Lights.xml will be updated to correct this error.

c) Third question: According to the latest FAA advisory, there are special-cases of taxiway centerline lights called lead-on lights and lead-off lights . The special lights can be green and yellow. To reflect this new requirement, the Light Name table will be updated as follows :

\Airport_Lighting

\Taxiway

\Centerline

\Aligned

\Curved

and...

\Airport_Lighting

\Taxiway

\Lead-on_Green

\Lean-on_Yellow

\Lead-off_Green

\Lean-off_Yellow

We hope this provide acceptable solutions to your questions.

1. We do not have an Airport Lineal Feature for "Enhanced Taxiway Centerline Markings" (AC Section 3 21.e, AIM 2-3-4.b.2). We should add this to our list of Airport Lineal Features as follows:

CNAM = "AFL Taxiway Markings" and APFN = "Enhanced Centerline"

It is mentioned that an area would be better handled to "properly handle convergence". Can you clarify what you mean by this?

Note that these might be better represented as areals because properly handling convergence (AC Appendix 3 Figure C-2) in a run-time publisher may be difficult.

I simply meant to indicate that satisfying the constraints illustrated in AC Appendix 3 Figure C-2 and described by this:

Note: There must be no partial dashed lines less than 9-feet (2.74 m) at the point of convergence. The first inside dashed lines must be aligned with the outside dashed lines― starting and stopping with the dashed lines on the outside, as shown in the figure above.

procedurally in a run-time publisher might be difficult enough to warrant an off-line computed areal representation instead. This would eliminate the need to detect lineal convergence and apply special run-time algorithms.

NOTE it is difficult to fold-in the full generality of signage with the currently provided mechanism for surface detail. In all likelyhood, we need to point to a small OpenFlight model. SOLUTION IS TBD

Could you please elaborate on the aspects of signage that has lead you to this conclusion? It does not seem obvious why this would be the case. I assume that if this approach were taken, the model would be marked as a "foot print" so that it could be projected on the underlying terrain altimitry?

There are obviously a large array of sign types and paint colors to represent. Did you have any response to this request?

As a general comment, it would seem that a hierarchical attribution scheme, similar to the one for lights, would fit better with the CDB philosophy. It would also alleviate the need for an exhaustive classification list in order to have a basic representation of any marking.

In particular, a simple way to represent generic aviation colored paint would go a long way toward filling this gap. It would probably also generically cover most future painted signage needs that we are unable to anticipate.

PS: Thank you very much for your time and consideration. We appreciate your efforts, and look forward to using the extensions you propose.

APFN = "Vehicle_Roadway_Line_Zippered"

This change is fine but just to note that the current APFN field is 24 characters.

It would be nice if there were an optional analog to the RWID field for taxiway and gate id information everywhere RWID is supported.

References:

AC - FAA Advisory Circular AC 150/5340-1J

AIM - FAA Aeronautical Information Manual

5.3.1.9.1 Airport Lineal Features Components

1.) Enhanced taxiway centerline markings (AC Section 3 21.e, AIM 2-3-4.b.2)

Note that these might be better represented as areals because properly handling convergence (AC Appendix 3 Figure C-2) in a run-time publisher may be difficult.

2.) Dashed taxiway edge markings (AC Section 3 22.2, AIM 2-3-4.c.2)

3.) Non-movement area boundary markings (AC Section 4 38, AIM 2-3-6.c)

4.) Vehicle roadway markings (AC Section 4 36, AIM 2-3-6.a)

Non-zippered white markings could be represented by "AF Generic Markings - Road Mark" areals, but areals are not the ideal shape type for these features.

5.) Runway hold position markings (AC Section 3 23.d, AIM 2-3-5.a)

Since these are represented by lineals, and are directional, please document a standard for specifying the orientation. The only alternative we have devised is to use the navigation data to find the nearest runway and orient them accordingly.

Thank you ccbrianf and John. We will provide an update on the Web site soon based on your comments.

Hi,

I'd like to make the following comment about the "Additional Attributes" section:

It is understandable that data producers have requested the freedom to use whatever attribute coding schemes they find most convenient or expressive. However, doesn’t enabling this mean that data consumers may find their CDB data set contains attribute values that they do not understand and cannot predict? If the point of using CDB is to have data sets that any CDB-ready system can understand then doesn’t this tend to undermine that goal? Shouldn't CDB define a single set of attributions (as it has done for classifications) that are sufficient for its purpose and used in common by all users?

Thanks.

In regards to previously posted question on this post:

Question 1:

It would be nice if there were an optional analog to the RWID field for taxiway and gate id information everywhere RWID is supported.

Answer:There is a Gateway ID (GAID) attributes which has been provided as an addendum (CDB - Misc). Could you please check to see if this meet your need. It could be expanded to supporte everywhere the RWID and the APID is supported.

Hi,

I'd like to make the following comment about the "Additional Attributes" section:

It is understandable that data producers have requested the freedom to use whatever attribute coding schemes they find most convenient or expressive. However, doesn’t enabling this mean that data consumers may find their CDB data set contains attribute values that they do not understand and cannot predict? If the point of using CDB is to have data sets that any CDB-ready system can understand then doesn’t this tend to undermine that goal? Shouldn't CDB define a single set of attributions (as it has done for classifications) that are sufficient for its purpose and used in common by all users?

Thanks.

[To rharris]

Yes, we agree wholehartedly with your comment. The proposed version 3.1 of the spec merely adds an attribution extension mechanism to the CDB. The proposed scheme is careful in seggragating those attributes whose origin is other than the CDB. As a result, the proposed scheme requires that a separate extended-level *.dbf file be provided for each of the three attribution schemas, namely one for CDB, one for Geomatics standards and one for vendors.

One of the benefits of the approach is that it provides the means to embed all of the source-level attribution data used during the development of a Common Database. As a result, source-level attribution data conforming to various Geomatics standards (SEDRIS transmittal, DGI WGG, DIGEST, UHRB) can be readily integrated into the CDB structure. Similarly, vendor-specific attribution can also be integrated into the CDB structure. The additional attribution can provide additional information about a feature that can be accessed the modeler during the build process; similarly, the tools themselves could make use of that information to build richer CDB content.

I have extracted the following text from the proposed V3.1 of the spec. Here are the three categories of attributes, clearly seggragated into the following categories:

a) CDB attributes: CDB attributes are attributes whose semantics, data type, length, format, range, usage, units, compatibility and schema are entirely governed by the CDB specification. Most of these attributes are unique to the CDB Specification, ie these attributes are not found in source data that conforms to various (US) governmental standards and Specifications. As a result, this attribution data must be derived via CDB tool automation or provided directly by the user.

b) Geomatics Attributes

Geomatics attributes are attributes whose semantics, data type, length, format, range, usage, and units, are governed by various governmental/industrial Specifications and standards. Such attributes are generally found in source data that conforms to such standards and specifications. While the CDB Specification itself does not define and govern the usage of these attributes, it nonetheless accommodates their storage within the repository structure of the CDB. NOTE: that the attributes from the various Geomatics attributes are labelled with a group tag (e.g. ISO/IEC 18025:2005, DIGEST 2.1 , DGIWG FDD Dec 08, UHRB) that distinguishes them from each other.

c) Vendor Attributes

Vendor attributes are attributes whose semantics, data type, length, format, range, usage, and units are governed by one or more vendors. In general, such attributes cannot be used by other vendors since they are often proprietary. Such attributes exclude the above two types of attributes and are generally unique to each vendor. While the CDB Specification itself does not define and govern the usage of these attributes, it nonetheless accommodates their storage within a CDB.. NOTE: that the attributes from the various vendor-specific attributes are labelled with a group tag that distinguishes them from each other.

APFN = "Vehicle_Roadway_Line_Zippered"

This change is fine but just to note that the current APFN field is 24 characters.

I think this comment was overlooked as several of the newly defined APFN strings exceed the current 24 character APFN field size. I assume abbreviations for those that exceed the limit are in order?

So after looking through the extended attribution scheme, I like the concept of it. But I have some questions about the which attributes are being moved to extended attribution and which are deprecated.

For optional attributes that are typically empty, it makes a lot of sense. It can keep the class-level attribute file smaller. But there are a few attributes that if moved to the extended attribute file, will take up much more space than if they were left in the class-level attribute file. So from the 3.1 spec, an attribute value takes 34 bytes (LNK is 6 digits, GRP is 8 characters, EAC is 4 digits, and EAV is 16 characters). Chaining them together helps a lot for certain attributes (RWID->APID) and keeps the file size lower. But for values that are usually unique, like the bounding box attributes (BBL, BBW, BBH), there will be a lot of overhead to store these attributes. If a shapefile has 100 unique models in it, the class level attribute file can store these attributes in about 2700 bytes (9 bytes x 3 attributes x 100 models). This same information in the extended attribute file takes 10200 bytes (34 bytes x 3 attributes x 100 models).

Another example is the load information (NIS, NIX, NNL, NTC, NTX, NVT). In a class-level attribute, they would take 39 bytes per model, but in the extended attribute file they would take 204 bytes per model. Unless most of your models shared identical load parameters, this causes the RTP to load much more data. We still intend to keep using them, because they are the only load management information about the model (short of loading the actual model), but we would prefer to keep them as a class-level attribute.

Ryan