Talk:Sign Specification Proposal

So what is the current state of this effort? Is someone still in contact with the responsable person(s) at X-Plane? What about further work on this in FG, especially with the 850 apt.dat format on the horizon? --Papillon81 15:44, 7 November 2011 (EST)

The markup looks okay, but just for clarification: why is the specification restricted to being one ASCII string? The majority of other FlightGear configuration is using XML, while this is much more verbose, it is also much more intuitive for an average user, that is you don't necessarily have to provide any complicated markup explanations for people who aren't familiar with the syntax. Basically, using the existing infrastructure code from SimGear, shouldn't be more complicated than writing a parser for the proposed syntax?

<?xml ...>
<PropertyList>
<sign>
  <type>MANDATORY_INSTRUCTION</type> <!--DIRECTION, LOCATION, RWY DIST. -->
  <size>1</size> <!--1-5 -->

 <face>
  <glyphs>down</glyphs>

  <glyph>2</glyph>
  <glyph>3</glyph>
  <glyph>R</glyph>

  <arrow-up/>
  <arrow-down/>
  ...
 </face>

</sign>
</PropertyList>

--FlightZilla 16:46, 18 June 2006 (EDT)

This is meant to be a simple sign description language for sign specifications included in apt.dat(.gz). The whole file isn't XML, and there's no way the sign strings therein will be XML.

--Melchior FRANZ 23:08, 18 June 2006 (UTC)

Okay, that makes of course sense. So, is this stuff meant to be only in FlightGear's apt.dat.gz or directly in Peel's DB, that is for X-Plane, too? --FlightZilla 17:36, 18 June 2006 (EDT)

DAFIF replacement project

(Moved from main page) Things like these don't belong in the spec. Its purpose is not to describe what an implementation should do. If a string says just {safety}, then this just says that there shall be a "Runway Safety Area" sign. Period. How it is rendered is completely beyond the purpose of a sign description language and rather disturbing. FlightGear doesn't want to be told by a common spec how to render signs. Only what should be on the signs.

Framing for signs that are independent of sign type is at the discretion of the implementing
flight sim - that is - the flight sim should place frames around an independent frame when it
is visually appropriate.  (Since most independent glyphs are stand-alone signs, a reasonable
implementation would be to always frame them.)

Ben Says: even if framing has no place in the specification, division of signs does have a place, as we have an explicit glyph | for it. To some extent we do need to decide what the "correct rendering" of a sign is because if we do not, the author will build the sign not based on this spec, but based on validation of the input sign data in a _particular_ flight sim. So our two options are: make sure X-Plane and FlightSim produce reasonably similar output, or have some signs 'tuned' for Flight Sim and some for X-Plane.

Authors need to know if they can do {@R,safety}22R or whether they must do {@R,safety}|22R. We must know which of these signs we want in our apt.dat files and write the spec such that the correct sign is clear.

Ben says: I've moved these over from discussion