The abstractLocation data type offers access at two levels. At the top level, an XML Schema can declare an element of type abstractLocation, and would have the full set of elements used to declare a location. This includes the geopolitical description, a legal description, an offshore block description, one or more survey locations (geographic lat/long or projected or local), and simply an uncontrolled text description.
At the lowere level, the XML Schema can access each of the five descriptions independently.
The advantages in using the abstractLocation data type are obvious. Use of this gives a complete, interoperable, and standard way to express locations of features such as wells, bottomholes, rigs, etc. In addition, the abstractLocation can be extended to include additional location types, such as a street address.
The XML Schema for abstractLocation is not given in full in this document. It can be accessed by clicking here.
A shortened version of it is presented here:
<schema
targetNamespace="http://www.posc.org/schemas"
xmlns="http://www.w3.org/2000/10/XMLSchema"
xmlns:gml="http://www.opengis.net/gml"
xmlns:posc="http://www.posc.org/schemas"
elementFormDefault="unqualified"
xmlns:xsi="http://www.w3.org/2000/10/XMLSchema-instance">
<import namespace="http:/www.opengis.net/gml"
schemaLocation="feature.xsd"/>
<complexType name="AbstractLocation">
<sequence>
<element name="GeopoliticalLocation" type="posc:goplloc" minOccurs="0"/>
<element name="OffshoreLocation" type="posc:offloc" minOccurs="0"/>
<element name="SurveyLocation" type="posc:survloc" minOccurs="0" maxOccurs="2"/>
<element name="LegalDescription" type="posc:cadastral" minOccurs="0"/>
<element name="comment" type="string" minOccurs="0"/>
</sequence>
<attribute name="version" use="fixed" type="NMTOKEN" value="1.0"/>
<attribute name="status" use="optional">
<simpleType>
<restriction base="string">
<enumeration value="proposed"/>
<enumeration value="actual"/>
</restriction>
</simpleType>
</attribute>
</complexType>
The main AbstractLocation data type consists of four child data types. Each of them are optional. Each represents a different way of giving a location. The four child data types will be discussed below.
Note that there is an attribute that allows the status to be proposed or actual.
If the following steps in XML Schema do not make sense to you, you can either skip this section, or read some of the background material on W3C material: XML Schema Primer. It is also useful to see the namespaces primer.
The AbstractLocation definition is stored in http://www.posc.org/schemas, and is in file location.xsd. The file does not contain any global elements, nor does it contain any target namespace. The application can include the file, and can set the namespace usage within its own schema definitions.
The following is the recommended procedure:
First - Insert the following at the beginning of the XML Schema file:
<?xml version="1.0"?>
<schema
targetNamespace="http://...yourtargetnamespace..."
elementFormDefault="qualified or unqualified"
xmlns:xxxx="http://...yourtargetnamespace..."
xmlns:posc="http://www.posc.org/schemas"
xmlns="http://www.w3.org/2000/10/XMLSchema"
xmlns:xsi="http://www.w3.org/2000/10/XMLSchema-instance">
<include schemaLocation="http://www.posc.org/schemas/location.xsd"/>
where we have the following meanings:
Second - Build the schema, using the appropriate namespaces to indicate where the defined data types and global elements are. For example, here is a BasicWellInformation which will have subtags of WellLocation and BottomholeLocation (among other child tags).
<element name="BasicWellInformation">
<complexType>
<sequence>
....
<element name="WellLocation" type="posc:AbstractLocation"/>
<element name="BottomholeLocation" type="posc:AbstractLocation"/>
...
</sequence>
</complexType>
</element>
In addition to the ability to use the AbstractLocation data type, a schema developer could use one of the four child tags directly. For example, the developer may want to include only the survey location capability for the Bottomhole Location, and may not wish to allow a legal description at all. The above could then be modified as follows:
<element name="BasicWellInformation">
<complexType>
<sequence>
....
<element name="WellLocation">
<complexType>
<sequence>
<element name="Geopolitical" type="posc:goploc" minOccurs="1"/>
<element name="Offshore" type="posc:offloc" minOccurs="1"/>
<element name="Survey" type="posc:survloc"/>
</sequence>
</complexType>
</element>
<element name="BottomholeLocation">
<complexType>
<sequence>
<element name="Survey" type="posc:survloc" minOccurs="1">
</sequence>
</complexType>
</element>
...
</sequence>
</complexType>
</element>
This specification is more specific about what is mandatory and what is acceptable.
In addition to this capability, the user can apply restrictions and extensions to these child data types to more tightly specify them.
Tag: GeopoliticalLocation
Meaning: The geopolitical location is intended to contain information about the country, state, and/or county of the object being located.
Subtags: county, oneof (state, province, stateOrProvince), country, comment.
Attributes: None
Tag: county
Meaning: The name of the county, parish, or equivalent construct in which the object is located. Optional.
Data type: Uncontrolled string.
Attributes: None
Tag: One of state, province, stateOrProvince
Meaning: The name of the state or province in which the object is located. Optional. The three tags are interchangeable in the sense that the semantic meaning of a state or province is the same. The difference between the two is strictly a legal distinction within a country. This is also intended to include equivalent terms such as a commonwealth. The state and province tags are included as choices if there is a need or desire to be explicit.
Data type: Uncontrolled string.
Attributes: None
Tag: country
Meaning: The name of the country in which the object is located. Optional.
Data type: Uncontrolled string.
Attributes: code, codeSpace. These are optional attributes that allow a document to include a country code, and (optionally) the codeSpace from which the country code is taken.
A sample tag for country might be
<country code="US" codeSpace="ISO">United States</country>
Tag: comment
Meaning: An uncontrolled comment about the geopolitical location. Optional.
Data type: Uncontrolled string.
Attributes: None.
Tag: OffshoreLocation
Meaning: The offshore location is intended to contain information about offshore area, block number, or any other information that is required for specifying the offshore location.
Subtags: areaName, blockID, comment.
Attributes: namingSystem. This is an optional attribute to specify the namingSystem of the Offshore Location, which are often identified by a set of codes.
Tag: areaName
Meaning: The name of the offshore area. The meaning of this differs from country to country. Optional.
Data type: Uncontrolled string.
Attributes: None
Tag: blockID
Meaning: The identifier for the offshore block. Optional. The Offshore Location allows for up to four blockID's in case the object being located extends into multiple blocks.
Data type: Uncontrolled string.
Attributes: None
Tag: comment
Meaning: An uncontrolled comment about the offshore location. Optional.
Data type: Uncontrolled string.
Attributes: None.
Tag: LegalDescription
Meaning: The Legal Description is intended to handle objects that are located using a township - range - section description. The LegalDescription tag is broken into parts, but also allows a text line that gives the description.
Subtags: township, range, section, quarterSection, lotNumber, principalMeridian, aliquotRemark, locationDistance OR text, comment
Attributes: None.
Tag: township
Meaning: The township portion of a legal description. This element is mandatory. It must be an integer.
Subtags: None
Attributes: direction. Direction is mandatory, and can be either N or S, representing North or South.
Sample XML:
<township direction="N">27</township>
Tag: range
Meaning: The township portion of a legal description. This element is mandatory. It must be an integer
Subtags: None
Attributes: direction. Direction is mandatory, and can be either E or W, representing East or West.
Sample XML:
<range direction="W">4</range>
Tag: section
Meaning: The section portion of a legal description. This element is optional. It must be an integer from 1 to 36.
Subtags: None
Attributes: None
Tag: quarterSection
Meaning: quarterSection is an optional addition to the legal description. It is intended to handle the quarter Section, quarter quarter Section, and quarter quarter quarter Section descriptions. The format of the value is uncontrolled in the Schema. However, it should be in conformance with the standard method for expressing the quarter section. Also, because it is not possible to express a fraction directly in 7 bit ASCII, it is recommended that the fraction be expressed as "1/4" (or "1/2" if that is the case). See the example below.
Subtags: None
Attributes:
Sample XML:
<quarterSection>NW1/4 of SW1/4</quarterSection>
Tag: lotNumber
Meaning: The lot number of a legal description. This value is often used in place of a section number if appropriate. This element is optional.
Subtags: None
Attributes: None.
Tag: principalMeridian
Meaning: The principal meridian line from which ranges values can be established. For example, the Michigan meridian, the Indian meridian. This element is optional.
Subtags: None
Attributes: None
Tag: aliquotRemark
Meaning: An explanation or description associated with the aliquot portion of a lease as shown in the Serial Register Page Report. This element is optional.
Subtags: None
Attributes: None
Tag: locationDistance
Meaning: A precise location within a section may often be described by the distance from one or two of the section lines. This element may occur zero, one, or two times. The value of the element is a real number.
Subtags: None
Attributes: uom, from, and direction. uom is the IDREF to the unit of measure that goes with the distance value. The from is one of FNL, FEL, FSL, FWL, which means that the distance is measured from the North, East, South, or West line respectively. Both of these attributes are mandatory.
There is also an optional attribute, direction, which may be "parallelToSide" or "perpendicularToBase". This attribute is useful if the section lines are not perpendicular to each other. If from is FNL, then parallelToSide means that the distance is measured from the North line, parallel to the East or West line. perpendicularToBase would mean that the distance is measured perpendicular to the North line.
Sample XML:
<locationDistance uom="ft" from="FNL">82</locationDistance> <locationDistance uom="ft" from="FWL">27.3</locationDistance>
The Survey Location is a complex data type itself. It is explained in an accompanying document, The Survey Location data type
If the following steps in XML Schema do not make sense to you, you can either skip this section, or read some of the background material on W3C material: XML Schema Primer.
The abstract location module is stored in http://www.posc.org/schemas, and is in file location.xsd. As can be seen from the schema above, the file does not contain any global elements, nor does it contain any target namespace. This means that the application can include the file, and can set the namespace usage within its own schema definitions. However, it should be noted that the Survey Location portion of the Abstract Location incorporates the GML Schema defined and controlled by the Open GIS Consortium. This schema does have qualified name spaces, and they must be declared in the XML instance document.
The following is the recommended procedure:
First - Insert the following at the beginning of the XML Schema file:
<?xml version="1.0"?>
<schema
targetNamespace="http://...yourtargetnamespace..."
elementFormDefault="qualified or unqualified"
xmlns:xxxx="http://...yourtargetnamespace..."
xmlns:posc="http://www.posc.org/schemas"
xmlns:gml="http://www.opengis.net/gml"
xmlns="http://www.w3.org/2000/10/XMLSchema"
xmlns:xsi="http://www.w3.org/2000/10/XMLSchema-instance">
<include schemaLocation="http://www.posc.org/schemas/unitsofmeasure.xsd"/>
<include schemaLocation="http://www.posc.org/schemas/location.xsd:/>
where we have the following meanings:
Second - Build the schema, using the appropriate namespaces to indicate where the defined data types and global elements are.
Here is an example of a simple XML Schema whose root element has three subtags. The first is the Unit Block, and the next two are quantity values that use the Units Block.
<element name="RootElement">
<complexType>
<sequence>
<element name="UnitsDefinition" type="posc:unitBlock"/>
<element name="WellInformation">
<complexType>
<sequence>
<element name="wellName" type="string"/>
<element name="wellLocation" type="posc:AbstractLocation/>
</sequence>
</complexType>
</element>
<element name="BottomholeInformation">
<complexType>
<sequence>
<element name="bottomholeDepth" type="posc:quantity"/>
<element name="wellLocation" type="posc:AbstractLocation/>
</sequence>
</complexType>
</element>
</sequence>
</complexType>
</element>
In this example, the data types from the units module and the data types from the location module are both prefixed with the same namespace, even though they come from different files. Since they were both included into the file, they can be considered to be from the same namespace. This is possible in this case since the files themselves do not declare a target namespace, and since there are no global elements in these files. It is like the files themselves have become a part of the main file, and the data types are being defined locally within this main file.