Skip to content

rugbyprof/5443-Spatial-DB

Repository files navigation

5443-Spatial-DB

Roster

Class Roster

ZOOM Link

https://msutexas-edu.zoom.us/j/9403974439

General Course Info

Resources

Assumed

  • This course assumes you can program at level after completing CMPS 1063
    • basic data structures
    • basic OOP concepts
  • I also assume you can install software and use different development platforms with a little help.

Topics / Objectives

  • Cover basics of SQL queries
  • Design a database schema from a set of requirements
  • Implement that design by creating a multi-table database
  • Create an API to interact with database
  • Work with spatial features in
    • Postgres/PostGIS
    • Mongo DB
  • Use QGIS (software for spatial data visualization and manipulation)
  • Execute spatial queries:
    • Nearest Neighbor
    • Region
    • Union / Intersection

Spatial Terms/Data Structures & Algorithms

These terms will assist in class discussions

  • Definitions
    • Points, Lines, Polygons
    • Trees, Graphs
    • Topological Relationships
    • Minimum Bounding Rectangle
  • Trees
    • R-Tree
    • B-Tree
    • R*-Tree
    • Quad-Tree
    • Oct-Tree
    • Bsp-Tree
    • KD-Tree
  • Clustering
    • Dbscan
    • K-Means
  • Algorithms
    • Douglass Peucker
    • Shortest Path
    • Nearest Neighbor
    • Astar

Grading

Categories | Grade
Projects 50% | A 89-100
Presentations 25% | B 79-88
Final1 15% | C 69-78
Github 10% | D 59-68
| F below 59

1. Plane ticket prices, events like weddings, or trips out of the country are not valid excuses for missing the final exam at its scheduled time. I will not make accommodations for anything other than an issue vetted by the dean of students.

Projects

  • Projects will be written in C++ and Python depending on the project.
  • I don't teach the traditional OS course using slides and a linear progression through a text book. Instead I try to create projects that require a basic understanding of the underlying concept in order to implement the project.
  • Each project must run without error (some exceptions allowed). If they do not run, they will not be graded. Correctness is a different matter.
  • The majority of each project will be graded by the class and myself during your class presentation. I will review code and other components separately.
  • Some projects can be done in groups. I will dictate the max size of each group. If I dictate a max size of 3, don't ask for 4. If you are that worried about a friend, then make 2 groups of 2.
  • Occasionally some students prefer to work alone. And although this was my preferred method in grad school, I may insist that you join a group.
  • Each group member will also fill out a performance evaluation on their team members. Sadly there are occasions when a group member does nothing. I want to give you the tools to let me know.
  • Please read the Academic Misconduct Policy & Procedures below. Different cultures and countries have differing opinions on what constitutes academic dishonesty. To avoid any confusion, we will be abiding by MSU's policy on academic dishonesty and plagiarism.

Presentations

  • Presentations are a major component of graduate work. The ability to discuss complex topics in front a group of your peers is an important skill to have.
  • Every project, group or individual, will be accompanied with a presentation.
  • The quality of your presentation is somewhat based on the quality of your project. A poor project makes it hard to give a proper presentation if much of the expected functionality was not included with your project. Basically you don't have much to discuss. On the flip side, an excellent project doesn't ensure a great presentation either. So preparation is key, and I am ALWAYS available for help with presentations.
  • I will give specific requirements for each presentation since each project may vary greatly. One project may simulate scheduling algorithms and will have results, whereas a shell project simply needs a walk-through showing commands, examples of piping, and redirection.
  • In general presentations in my course should follow a basic outline:
    • Project description (if necessary)
    • A logical progression of your steps in implementing the project. Make sure to include:
      • Pitfalls (any confusing components that gave problems)
      • Highlights (any good solutions or components you are proud of)
    • Discuss Results
    • OR
    • Show features
  • Be prepared! Sometimes showing your project seems easy since you spent many hours writing it and have a very deep understanding of it. Using a shell as an example, practicing which commands you will use to show all features of a shell will definitely make for a better presentation. You can also hide small flaws with a well thought out presentation.
  • I am also much less inclined to ask pointed questions if you have a well thought out and thorough presentation.

My View on Cheating / Plagiarism

  • Most plagiarizing, when it comes to programming, happens for two reasons:

      1. You don't have a clue how to solve the problem, so you get a friend or the internet to help.
      1. You didn't start early enough, and you're desperate to get something working the night before it's due, so you get a friend or the internet to help.
  • Both are easy to fix.

      1. Come ask me to explain. I promise you're not the only one who is confused.
      1. Start early. Then when you get stuck, you can ask for help the right way!
  • Please read this article as it pertains to our field of computer science: How To Code Without Plagiarizing

  • Also, this might help: plagiarize and get an "F".

  • Ultimately it's not cool. It's an insult to those that actually do the work.

  • Lastly: Let me reiterate that I'm available for help ... a lot. No excuses. I've helped students at 1am via Slack. I'm online consistently afternoons and most nights, just shoot me a message.

Official Policy on Academic Honesty

The Department of Computer Science had adopted the following policy related to cheating (academic misconduct). The policy will be applied to all instances of cheating on assignments and exams as determined by the instructor of the course. (See below for link to MSU definitions.)

  • 1st instance of cheating in a course: The student will be assigned a non-replaceable grade of zero for the assignment, project or exam. If the resulting grade does not result in a letter grade reduction, the student will receive a one letter grade reduction in course.
  • 2nd instance of cheating in a course: The student will receive a grade of F in course & immediately be removed from course.
  • All instances of cheating will be reported to the Department Chair and, in the case of graduate students, to the Department Graduate Coordinator.

Official Policy on Testing Process

The Department of Computer Science has adopted the following policy related to testing.

  • All bags, purses, electronics (turned off), books, etc. will be placed in the front of the room during exams, or in an area designated by the instructor.
  • Unless otherwise announced by the instructor, nothing is allowed on the desk but pen/pencil/eraser and test papers.
  • No student is allowed to leave the room during an exam and return.

See Also: MSU Student Handbook: Appendix E: Academic Misconduct Policy & Procedures.

About

Spatial Database Concepts

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published