Question

Question 5. ArcGIS records projection and coordinate system information into a file with prj extension. Open MD_cities_SPCS.prj in any text editor (e.g., WordPad, Notepad, etc.). Read the prj file, and explain the following information for the MD_cities_SPCS layer: projection, geodesy, GCS, geodetic datum and unit. Make sure you do not change the file (i.e., do not save the changes if you ever modify the content of this file. You may read ArcGIS Help to answer this question. (2 points)

this is the prj file opened in notepad (see below), I have no idea what it means...

PROJCS["NAD_1983_StatePlane_Maryland_FIPS_1900",GEOGCS["GCS_North_American_1983",DATUM["D_North_American_1983",SPHEROID["GRS_1980",6378137.0,298.257222101]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]],PROJECTION["Lambert_Conformal_Conic"],PARAMETER["False_Easting",400000.0],PARAMETER["False_Northing",0.0],PARAMETER["Central_Meridian",-77.0],PARAMETER["Standard_Parallel_1",38.3],PARAMETER["Standard_Parallel_2",39.45],PARAMETER["Latitude_Of_Origin",37.66666666666666],UNIT["Meter",1.0]]

Answer 1

Before you can do this homework assignment in any meaningful way, you and your teacher need to be of one accord about whether an ERD expresses Data Analysis or Database Design. In previous questions concerning ERD, I've always offered the view that ERD is for data analysis, and database design ought to be expressed in some other diagramming scheme, such as a relational schematic diagram. However, it's very possible that your teacher doesn't see this the same way I do. A large number of professionals use ERD as an alternative to relational schematics, and express database design in an ERD. Your solution looks like design to me, and not analysis. If your teacher doesn't distinguish between analysis and design (and some don't) there is something fundamental that you need to learn, and that your teacher will not be able to teach you. You need to distinguish between the features of the problem and the features of the proposed solution to the problem. If you don't make that distinction you end up in one of several pitfalls. The most common pitfall is coming up with the right solution to the wrong problem. I've seen this happen over and over again in the field. The second most common pitfall is changing the problem definition in order to make the problem easier to solve. Sometimes this is done intentionally, in order to meet a deadline with limited resouirces. But when it's done unintentionally, a host of problems crop up. The third pitfall is what may be called "thinking inside of the box". In this pitfall, the would be solver adds a constraint that was not in the original problem definition, but is a feature of the first faulty solution. The "box" is a feature of a proposed (faulty) solution and not a feature of the problem as originally stated. But once it's been accepted as part of the problem, the problem becomes unsolvable.