next up previous
Next: Commands for Part 3 Up: CMSC420 Project - Summer, Previous: 3D Spatial Structures

General XML Output

General <success> Output
This is an example of the form (in the exact output order) of a general <success> tag. All tags will be present even if there are no parameters or outputs.
		<success>
		    <command name="name1" id="1"/>
	    <parameters>
		        <param1 value="value1"/>
		        <param2 value="value2"/>
		    </parameters>
		    <output/>
		</success>

General <error> Output

This is the form (in the exact output order) of a general <error> tag. The <parameters> tag will always be present even if there are no parameters to the command. In each command there may be several errors; in this case you will only output the error of highest priority. For more information see XML Input specification for each command.

		<error type="error1">
		    <command name="name1" id="2"/>
		    <parameters>
		        <param1 value="value1"/>
		        <param2 value="value2"/>
		    </parameters>
		</error>

General <fatalError> Output
This is the form of a General <fatalError> tag. This is used when there is a problem with the entire document

		<fatalError/>

General <undefinedError> Output
This is the form of a general <undefinedError> tag. This is a default error that will be used if there is an error that is not specified in the spec and is discovered post freezing.

		<undefinedError />

General sorting of <city> and <road> tags.

Ordering of <city> tags that are contained within the <output> tag is in descending asciibetical order of the city's name according to the java.lang.String.compareTo() method unless the method for sorting is specified within the command's specification.

Ordering of <road> tags that are contained within the <output> tag is in descending asciibetical order of the start city's name. If two roads have the same start city, the end city's names would appear in descending asciibetical order. The java.lang.String.compareTo() method is used unless the method of sorting is specified within the command's specification.

printPMQuadtree
Prints the PM quadtree. Since PM quadtrees are deterministic once the order of quadrants has been fixed, your XML should match exactly the primary input/output. Because cities now have two sets of coordinates (remote coordinates and local coordinates), we introduce the parameters remoteX and remoteY, which denote the remote coordinates of the metropole we want you to print. There are two possible error conditions. First, if we specify remote coordinates that are not in the bounds of the remote spatial map (see commands for part 3 for details), you should return a metropoleOutOfBounds error. Second, if the PMQuadtree for the associated remote coordinates is empty, you should return a metropoleIsEmpty error.

Parameters:
remoteX
remoteY
Possible <output>:
A <quadtree> tag will be contained within output. This tag will have one attribute order which will be the PM order of the tree you are printing (this is given in the commands tag). and will contain several <gray> <white> and <black> nodes.
The first node in the quadtree will be the root node, this node can be gray or black, then the rest of the PM Quadtree follows. Remember, the exact structure of the quadtree will be represented by the XML output.

<gray>
Nodes will contain 4 children nodes with ordering decided by the order of the nodes within the actual gray node in your PM quadtree.<gray> nodes will have the attributes x and y, these are integers that identify the location (local coordinates) of the gray node. They will appear as such
		<gray x="72" y="40">
		    ...
		</gray>

<black>
Nodes in a PMQuadtree can contain at most one <city> or <airport> tag (not both). Nodes can also contain several <road> tags, depending on the type of tree (PM1 or PM3).
The format of <city>, <airport>, and <road> tags will be as such:
<city name="city1" localX="coordx" localY="coordy" remoteX="coordX" remoteY="coordY" color="color1" radius="radius1"/>
<airport name="airport1" airlineName="airline1" localX="coordx" localY="coordy" remoteX="coordX" remoteY="coordY" />
<road start="city_a" end="city_b"/>
The ordering of the city and road tags within the black node will be as such: first the <city> or <airport> tag will be printed (if it exists) then the <road> tags will be printed in the ordering specified in the General sorting of <city> and <road> tags section. Since the roads are undirected, within the road tag, the start city is the one whose name is first in descending asciibetical order.
Black nodes have the attribute cardinality which is the total number of cities, roads, and airports contained within the black node. Black nodes will appear as such:
		<black cardinality="card">
		    ...
		</black>

<white>
Nodes represent an empty node in your PM quadtree and will appear as such;
<white/>
Possible <error> types:
metropoleOutOfBounds
metropoleIsEmpty
<success> Example:
      <quadtree order="3">
        <gray x="512" y="512">
          <black cardinality="2">
            <terminal airportName="P1" cityName="A" localX="0" localY="5" name="T2" remoteX="0" remoteY="0"/>
            <road end="T2" start="A"/>
          </black>
          <black cardinality="2">
            <city color="black" name="Zurich" radius="5" localX="1000" localY="1000" remoteX="1" remoteY="1"/>
            <road end="Zurich" start="Chicago"/>
          </black>
          <black cardinality="2">
            <city color="black" name="Chicago" radius="5" localX="133" localY="34" remoteX="1" remoteY="1"/>
            <road end="Zurich" start="Chicago"/>
          </black>
          <black cardinality="2">
            <airport localX="2" localY="6" name="P1" remoteX="0" remoteY="0"/>
            <road end="Zurich" start="Chicago"/>
          </black>
        </gray>
      </quadtree>

printAvlTree
This is identical to part 2, with the exception that instead of printing (x,y) coordinates as the value for each node, you should print (localX, localY) coordinates. Airports should not be part of the Avl-g tree.



Subsections
next up previous
Next: Commands for Part 3 Up: CMSC420 Project - Summer, Previous: 3D Spatial Structures
MM Hugue 2019-06-09