首页 > > 详细

COMP 8042作业代做、data留学生作业代做、C++语言作业代写、C++ 编程设计作业调试代做留学生Processing|帮做Java程序

Assignment 3
Due on March 30th, 2020
COMP 8042
All work should be done individually.
Geographic Information System
Geographic information systems organize information pertaining to geographic features and
provide various kinds of access to the information. A geographic feature may possess many
attributes (see below). In particular, a geographic feature has a specific location. There
are a number of ways to specify location. For this project, we will use latitude and longitude,
which will allow us to deal with geographic features at any location on Earth. A
reasonably detailed tutorial on latitude and longitude can be found in the Wikipedia at
http://en.wikipedia.org/wiki/Latitude and http://en.wikipedia.org/wiki/Longitude.
The GIS record files were obtained from the website for the USGS Board on Geographic
Names (http://geonames.usgs.gov). The file begins with a descriptive header line, followed
by a sequence of GIS records, one per line, which contain the fields provide in Table 1 in
Appendix in the indicated order.
Notes:
• See https://geonames.usgs.gov/domestic/states fileformat.htm for the full field descriptions.
• The type specifications used here have been modified from the source (URL above) to
better reflect the realities of your programming environment.
• Latitude and longitude may be expressed in DMS (degrees/minutes/seconds, 0820830W)
format, or DEC (real number, -82.1417975) format. In DMS format, latitude will always
be expressed using 6 digits followed by a single character specifying the hemisphere, and
longitude will always be expressed using 7 digits followed by a hemisphere designator.
• Although some fields are mandatory, some may be omitted altogether. Best practice is
to treat every field as if it may be left unspecified. Certain fields are necessary in order
to index a record: the feature name and the primary latitude and primary longitude.
If a record omits any of those fields, you may discard the record, or index it as far as
possible.
In the GIS record file, each record will occur on a single line, and the fields will be separated
by pipe (‘|’) symbols. Empty fields will be indicated by a pair of pipe symbols with no
characters between them. See the posted VA Monterey.txt file for many examples.
GIS record files are guaranteed to conform to this syntax, so there is no explicit requirement
that you validate the files. On the other hand, some error-checking during parsing may help
you detect errors in your parsing logic.
1
Name: ..................
Id: A0..............
Assignment 3
Due on March 30th, 2020
COMP 8042
Hassan S. Shavarani
The file can be thought of as a sequence of bytes, each at a unique offset from the beginning
of the file, just like the cells of an array. So, each GIS record begins at a unique offset from
the beginning of the file.
Line Termination
Each line of a text file ends with a particular marker (known as the line terminator). In
MS-DOS/Windows file systems, the line terminator is a sequence of two ASCII characters
(CR + LF, 0X0D0A). In Unix systems, the line terminator is a single ASCII character (LF).
Other systems may use other line termination conventions.
Why should you care? Which line termination is used has an effect on the file offsets for all
but the first record in the data file. As long as were all testing with files that use the same
line termination, we should all get the same file offsets. But if you change the file format (of
the posted data files) to use different line termination, you will get different file offsets than
are shown in the posted log files. Most good text editors will tell you what line termination
is used in an opened file, and also let you change the line termination scheme.
In Figure 1, note that some record fields are optional, and that when there is no given value
for a field, there are still delimiter symbols for it.
Also, some of the lines are “wrapped” to fit into the text box; lines are never “wrapped” in
the actual data files.
Figure 1: Sample Geographic Data Records
2
Name: ..................
Id: A0..............
Assignment 3
Due on March 30th, 2020
COMP 8042
Hassan S. Shavarani
Assignment
You will implement a system that indexes and provides search features for a file of GIS
records, as described above.
Your system will build and maintain several in-memory index data structures to support
these operations:
• Importing new GIS records into the database file
• Retrieving data for all GIS records matching given geographic coordinates
• Retrieving data for all GIS records matching a given feature name and state
• Retrieving data for all GIS records that fall within a given (rectangular) geographic
region
• Displaying the in-memory indices in a human-readable manner
You will implement a single software system in C++ to perform all system functions.
Program Invocation
The program will take the names of three files from the command line, like this:
./GIS
Note that this implies your main class must be named GIS, and be able to be compiled
simply using a g++ compile command. Preferably, you are encouraged to create make files
for the project and provide the required dependency files in your submission.
The database file should be created as an empty file; note that the specified database file may
already exist, in which case the existing file should be truncated or deleted and recreated.
If the command script file is not found the program should write an error message to the
console and exit. The log file should be rewritten every time the program is run, so if the file
already exists it should be truncated or deleted and recreated.
3
Name: ..................
Id: A0..............
Assignment 3
Due on March 30th, 2020
COMP 8042
Hassan S. Shavarani
System Overview
The system will create and maintain a GIS database file that contains all the records that
are imported as the program runs. The GIS database file will be empty initially. All the
indexing of records will be done relative to this file.
There is no guarantee that the GIS record file will not contain two or more distinct records
that have the same geographic coordinates. In fact, this is natural since the coordinates are
expressed in the usual DMS system. So, we cannot treat geographic coordinates as a primary
(unique) key.
The GIS records will be indexed by the Feature Name and State (abbreviation) fields. This
name index will support finding offsets of GIS records that match a given feature name and
state abbreviation.
The GIS records will also be indexed by geographic coordinate. This coordinate index will
support finding offsets of GIS records that match a given primary latitude and primary
longitude.
The system will include a buffer pool, as a front end for the GIS database file, to improve
search speed. See the discussion of the buffer pool below for detailed requirements. When
performing searches, retrieving a GIS record from the database file must be managed through
the buffer pool. During an import operation, when records are written to the database file,
the buffer pool will be bypassed, since the buffer pool would not improve performance during
imports.
When searches are performed, complete GIS records will be retrieved from the GIS database
file that your program maintains. The only complete GIS records that are stored in memory
at any time are those that have just been retrieved to satisfy the current search, or individual
GIS records created while importing data or GIS records stored in the buffer pool.
Aside from where specific data structures are required, you may use any suitable STL library
implementation you like.
Each index should have the ability to write a nicely-formatted display of itself to an output
stream.
Name Index Internals
The name index will use a hash table for its physical organization. Each hash table entry
will store a feature name and state abbreviation (separately or concatenated, as you like)
and the file offset(s) of the matching record(s). Since each GIS record occupies one line in
the file, it is a trivial matter to locate and read a record given nothing but the file offset at
which the record begins.
Your table will use quadratic probing to resolve collisions, with the quadratic function (n
2+n)
2
to compute the step size.
4
Name: ..................
Id: A0..............
Assignment 3
Due on March 30th, 2020
COMP 8042
Hassan S. Shavarani
The hash table must use a contiguous physical structure (array). The initial size of the table
will be 1024, and the table will resize itself automatically, by doubling its size whenever the
table becomes 70% full.
Since the specified table sizes given above are powers of 2, an empty slot will always be found
unless the table is full.
You can use your desired hash function (e.g. elfhash), and apply it to the concatenation of
the feature name and state (abbreviation) field of the data records. Precisely how you form
the concatenation is up to you.
You must be able to display the contents of the hash table in a readable manner.
Coordinate Index Internals
The coordinate index will use a bucket PR quadtree for the physical organization. In a bucket
PR quadtree, each leaf stores up to K data objects (for some fixed value of K). Upon insertion,
if the added value would fall into a leaf that is already full, then the region corresponding
to the leaf will be partitioned into quadrants and the K+1 data objects will be inserted into
those quadrants as appropriate. As is the case with the regular PR quadtree, this may lead
to a sequence of partitioning steps, extending the relevant branch of the quadtree by multiple
levels. In this project, K will probably equal 4, but I reserve the right to specify a different
bucket size with little notice, so this should be easy to modify.
The index entries held in the quadtree will store a geographic coordinate and a collection of
the file offsets of the matching GIS records in the database file.
Note: do not confuse the bucket size with any limit on the number of GIS records that may
be associated with a single geographic coordinate. A quadtree node can contain index objects
for up to K different geographic coordinates. Each such index object can contain references
to an unlimited number of different GIS records.
The PR quadtree implementation should follow good design practices, and its interface should
be somewhat similar to that of the BST. You are expected to implement different types for
the leaf and internal nodes, with appropriate data membership for each, and an abstract base
type from which they are both derived.
You must be able to display the PR quadtree in a readable manner. The display must clearly
indicate the structure of the tree, the relationships between its nodes, and the data objects
in the leaf nodes.
Buffer Pool Details
The buffer pool for the database file should be capable of buffering up to 15 records, and
will use LRU replacement. You may use any structure you like to organize the pool slots;
however, since the pool will have to deal with record replacements, some structures will be
5
Name: ..................
Id: A0..............
Assignment 3
Due on March 30th, 2020
COMP 8042
Hassan S. Shavarani
more efficient (and simpler) to use. You may use any classes from STL library you think are
appropriate.
It is up to you to decide whether your buffer pool stores interpreted or raw data; i.e., whether
the buffer pool stores GIS record objects or just strings.
You must be able to display the contents of the buffer pool, listed from MRU to LRU entry,
in a readable manner. The order in which you retrieve records when servicing a multi-match
search is not specified, so such searches may result in different orderings of the records within
the buffer pool. That is OK.
A Note on Coordinates and Spatial Regions
It is important to remember that there are fundamental differences between the notion that
a geographic feature has specific coordinates (which may be thought of as a point) and the
notion that each node of the PR quadtree corresponds to a particular sub-region of the
coordinate space (which may contain many geographic features).
In this assignment, coordinates of geographic features are specified as latitude/longitude
pairs, and the minimum resolution is one second of arc. Thus, you may think of the geographic
coordinates as being specified by a pair of integer values.
On the other hand, the boundaries of the sub-regions are determined by performing arithmetic
operations, including division, starting with the values that define the boundaries of the
world. Unless the dimensions of the world happen to be powers of 2, this can quickly lead
to regions whose boundaries cannot be expressed exactly as integer values. You may use
floating-point values or integer values to represent region boundaries when computing region
boundaries during splitting and quadtree traversals. If you use integers, be careful not to
unintentionally create “gaps” between regions.
Your implementation should view the boundary between regions as belonging to one of those
regions. The choice of a particular rule for handling this situation is left to you.
When carrying out a region search, you must determine whether the search region overlaps
with the region corresponding to a subtree node before descending into that subtree. You
may define a Rectangle class which could be (too) useful.
Other System Elements
There should be an overall controller that validates the command line arguments and manages
the initialization of the various system components. The controller should hand off execution
to a command processor that manages retrieving commands from the script file, and making
the necessary calls to other components in order to carry out those commands.
Naturally, there should be a data type that models a GIS record.
There may well be additional system elements, whether data types or data structures, or
6
Name: ..................
Id: A0..............
Assignment 3
Due on March 30th, 2020
COMP 8042
Hassan S. Shavarani
system components that are not mentioned here. The fact no additional elements are explicitly
identified here does not imply that you will not be expected to analyze the design issues
carefully, and to perhaps include such elements.
Aside from the command-line interface, there are no specific requirements for interfaces of
any of the classes that will make up your GIS; it is up to you to analyze the specification
and come up with an appropriate set of classes, and to design their interfaces to facilitate the
necessary interactions. It is probably worth pointing out that an index (e.g., a geographic
coordinate index) should not simply be a naked container object (e.g, quadtree); if that’s not
clear to you, think more carefully about what sort of interface would be appropriate for an
index, as opposed to a container.
Command File
The execution of the program will be driven by a script file. Lines beginning with a semicolon
character (‘;’) are comments and should be ignored. Blank lines are possible. Each line in
the command file consists of a sequence of tokens, which will be separated by single tab
characters. A line terminator will immediately follow the final token on each line. The
command file is guaranteed to conform to this specification, so you do not need to worry
about error-checking when reading it.
The first non-comment line will specify the world boundaries to be used:
world
This will be the first command in the file, and will occur once. It specifies the
boundaries of the coordinate space to be modeled. The four parameters will be
longitude and latitudes expressed in DMS format, representing the vertical and
horizontal boundaries of the coordinate space.
It is certainly possible that the GIS record file will contain records for features
that lie outside the specified coordinate space. Such records should be ignored;
i.e., they will not be indexed.
Each subsequent non-comment line of the command file will specify one of the commands
described below. One command is used to load records into your database from external
files:
import
Add all the valid GIS records in the specified file to the database file. This means
that the records will be appended to the existing database file, and that those
records will be indexed in the manner described earlier. When the import is
completed, log the number of entries added to each index, and the longest probe
sequence that was needed when inserting to the hash table. (A valid record is one
that lies within the specified world boundaries.)
7
Name: ..................
Id: A0..............
Assignment 3
Due on March 30th, 2020
COMP 8042
Hassan S. Shavarani
Another command requires producing a human-friendly display of the contents of an index
structure:
debug[ quad | hash | pool ]
Log the contents of the specified index structure in a fashion that makes the
internal structure and contents of the index clear. It is not necessary to be overly
verbose here, but you should include information like key values and file offsets
where appropriate.
Another simply terminates execution, which is handy if you want to process only part of a
command file:
quit
Terminate program execution.
The other commands involve searches of the indexed records:
what is at
For every GIS record in the database file that matches the given

联系我们
  • QQ:99515681
  • 邮箱:99515681@qq.com
  • 工作时间:8:00-23:00
  • 微信:codinghelp2
热点文章
程序代写更多图片

联系我们 - QQ: 99515681 微信:codinghelp2
© 2014 www.7daixie.com
程序代写网!