georeference.org
Subscribe to this thread
Home - General / All posts - New User -- Projection Problem?
jar19 post(s)
#27-Apr-06 14:10

I am new to GIS and to Manifold. I am trying to create a simple county map layering FTP data downloaded as ESRI shapefiles from Palm Beach County, Florida, USA, with data on individual warehouse and other properties that I have collected from a private service and geocoded. I think I have a projection problem, but I am not sure.

I am running a very small trial map. The result I get has the PB County data showing up as a proper map but in the upper right corner and the private data showing up as a dot in the lower left corner. The two sets of data will not merge, or layer together. They will merge and layer with each other within themselves, and opening each component individually, they seem to work ok. There are geocoding mistakes in the private data, putting some properties in the wrong part of town.

I have been all over the Help files in Manifold, and all over GeoReference.org. I have attempted to go through the excellent training materials that I purchased along with Manifold, and I have been through the must-read parts of the manual, or most of them. Here is the bottom line: I am not a geographer. This is my first venture into GIS and I fear I have got in over my head.

I have worried the projection choices to death and got nowhere. I have asked the purveyor of the private data for projection information and that has not been forthcoming. I have found only one .prj file in all of the dozens of PB County files. Here it is:

PROJCS["NAD_1983_StatePlane_Florida_East_FIPS_0901_Feet",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["Transverse_Mercator"],PARAMETER["False_Easting",656166.6666666665],PARAMETER["False_Northing",0.0],PARAMETER["Central_Meridian",-81.0],PARAMETER["Scale_Factor", 0.9999411764705882],PARAMETER["Latitude_Of_Origin",24.33333333333333],UNIT["Foot_US",0.3048006096012192]]

From the above I decided to go with Florida State Plane East Feet and NAD 1983, rather than venture into the Transverse Mercator bog. The thing is, no matter whether I use Florida State Plane East or let Manifold just project them into Latitude Longitude, it doesn’t seem to make any difference.

The PB County data are zoning classifications keyed to the map, city boundaries, etc. I am not using the above file in the trial, as it is too large for the quick-load purposes of the trial map. The private data are 187 warehouses from a .dbf table, imported into Excel, then into Manifold, copied and pasted as a drawing, then addresses standardized and then georegistered by Manifold with the results appearing on a layer as scattered points. Ditto for another table of 508 properties land used industrial, all in one municipality in the county.

I am really hung up and would appreciate any hints offered. This is all aimed at a commercial and industrial real estate application. Thanks.

artlembo


1,871 post(s)
#27-Apr-06 15:12

tell us about the X,Y coordinates in the original data. What do the numbers look like? Now, since you've been working with the data, I suggest you re-import the data, and then report to us the X,Y coordinates (make sure your display status under Tools-> options is set to projected). When we see the numbers, some of us geographers might just luck out and guess what it is.

Also, how far up in the corner is the data? Is it thousands of feet, hundreds of miles, etc.

mdsumner


3,617 post(s)
#27-Apr-06 15:19

"The thing is, no matter whether I use Florida State Plane East or let Manifold just project them into Latitude Longitude, it doesn’t seem to make any difference."

All I can offer is that this statement suggests you are using *Edit Projection* rather than *Current Projection* - it's quite confusing at first, but you are applying an interpretative step (harvesting whatever metadata you have), rather than a transformation (changing from a known coordinate system to another).

It's the number one FAQ - ensure you understand the difference - you open Edit Projection in your drawing, and then click "Current Projection" to enter the metadata you mentioned. Otherwise you sound like you're on the right track.

BTW, Manifold will pay heed to as-yet unseen .prj formats - you might provide it to them, see the Suggestions:

http://www.manifold.net/resources/suggestions.html

jar19 post(s)
#28-Apr-06 15:27

Re your replies, here are some of the things you asked about: 1) There are no X,Y coordinates in the original PB County data. It is from an FTP site and I unzipped it (using a free utility, not mighty WinZip, and I hope I did not run afoul of anything like the .tar problem) resulting in six files for each file name. They are .dbf, .sbn, .sbx, .shp, .shp.xml, and .shx. As these result in pretty pictures (Nice zoning areas keyed to the map, which I was able to theme and color. Ditto for the other few files I used for the trial map.) I am hoping they are OK. I did, however, re-import them into a new map and got the same results. There are object IDs, ID numbers, and usually a feature name and feature number. There is often a Geometry A and a Geometry B, both of which are usually a zero. There are no street addresses and this data was not geocoded by me. 2) The private data was geocoded by me, using the transform toolbar to append the proper information and build up a Manifold friendly address line from the data supplied by the vendor. The resulting Lat and Lon display as 26.xxxxx and –80.yyyyy. 3) Trying to use my tracker tool, I found I could not get it out of the degrees mode. I held CTL down, as suggested in the Help file, but this did not affect the tool. The map I was attempting to measure is in Latitude Longitude projection, which is also interesting and leads to Note 4. The degrees mode result is anywhere between 1,005,000 and 1,009,000 degrees in round numbers. When I hold down the Control key I get “L: 0.0000e+000 in,” which makes me wonder about the units I have set and which I have been unable to find or correct in Tools -> Options, either. 4) I went over the Florida State Plane East Feet projection, of course, in response to mdsumner’s (Dr. Sumner? I know it’s Dr. Lembo.) suggestion. Like the puppy eyeballing the rug, I may not be entirely sure why I am not supposed to go there, but I know I am not to use Target Projection (or I think I know this) and the general rule is that I am to do my business in Current Projection. So, I re-did the 508 industrial land use properties in Florida State Plane East Feet. No problem. Went to the 187 warehouses and saw they were in Latitude Longitude. Changed that (using Current Projection) to FSPEF NAD83 and got a goofy result. Changed it back to Lat Lon and (leaving the 508 in FSPEF) it works in its own layer and with the 508. Go figure. So: I have two private data layer components, one each in Lat Lon and FSPEF, and I have five PB County layer components in Lat Lon. I have a map layer, which has all of the above components in it, which is in Lat Lon projection, and which has the components spread out. I then deleted the map component, created a new map component, and re-projected the one oddball private drawing into Lat Lon, so the whole schmear is now in Lat Lon. Same story. The two sets of private data are off in the lower left corner, the public data off in the upper right. This is the new saved version: FSPEF is out, Lat Lon is in. 5) Here is the URL for the Palm Beach County FTP site: ftp://pbcgis:sigcbp@ftp.co.palm-beach.fl.us/

I will send this in to Manifold when I have a little better handle on the problem. If you wish to let Manifold know in the meantime, feel free. This is where the .prj file came from. It is the only one with a set of seven files out of the dozens they present; all the others are in sets of six, as discussed above.

Finally, I have been unable to check on the display status under Tools -> Options, unless it is Tools -> Options -> Rendering -> Adjust Display Scale for Monitor Resolution, which is checked. Otherwise, I can’t find it. Help has been no help but I have not yet begun to fight.

Thank you both, again, for taking the time to comment and help me out. I hope that this response is useful to you.

Dimitri


3,145 post(s)
#29-Apr-06 10:16

Since there are no .prj's involved for the majority of files you are not able to work with this I don't see what you would report to Manifold. It seems to me perhaps you have not grasped the fundamentals of how to correctly import projected data from formats that do not report coordinate systems. This is easy to fix as there is endless documentation on this that will show you the way step by step.

Stop what you are doing and go back and read the Introduction topics carefully that relate to projections and importing components from legacy formats. Next, very carefully read *all* of the topics in the Import and Export chapter that relate to importing shapefiles and also all of the topics in the Examples chapter that relate to importing shapefiles. You've been doing similar things for hours already so there understandably will be a temptation to skim the topics instead of actually reading them. Avoid that temptation as the devil is in the details.

The drill is simple: when importing from an idiotic format it is up to you to tell Manifold what projection is supposed to be used, because the format is too stupid to tell Manifold that information. If you have latitudes and longitudes that are in millions of degrees you have done it wrong.

Import the data and then immediately use Edit - Projection - Current Projection to tell Manifold the correct projection that is inteded. After that, you don't ever touch the Current Projection dialog again for that component. Thereafter, you re-project, if desired, using Edit - Projection. But, none of that will work if you do not correctly assign the current projection immediately after import - *anything* you do after that will be wrong and utterly worthless if that first current projection step is not accurately done.

Assuming that you got all the files available, it may be comforting to know that all the above is not Manifold's fault: it is the fault of the person who is providing projected information within shapefiles. They are the ones who have made your life miserable by laying this trap for you. Let's hope they are a decent person who has lapsed into evil due to funding constraints and that even though they know what they are doing is wrong they feel it is better they get these files out to the public no matter how gruesome the shape (ha, ha... a pun :-) they may be in. If they had consideration for the public (or adequate resources if that is the problem) they'd publish the data as simple lat/lon in shapefiles (if they felt they had to use shapefiles) or they'd use a sensible format such as SDTS (if they felt compelled to publish it in projected form).

One more thing I hope no one takes wrong... in response to mdsumner’s (Dr. Sumner? I know it’s Dr. Lembo.) suggestion. Weird. I assume you did not intend any offensive tone (always hard to judge from email), but it does illustrate the risk of leaping to conclusions, which is no more effective in guessing identities than it is in guessing how to import projected shapefiles. :-) ...in both cases it is better to slow down and carefully, systematically read all available documentation before reaching a conclusion. In the identity case I suggest a search on the forum archives and a Google search of Manifold's web site on "sumner". Mike Sumner of Australia has been a highly respected contributor to the Manifold user community for years, including such outstanding contributions beyond the call of duty in beta test campaigns that he is one of the few from hundreds of beta testers thanked by name in the release notes. I know you didn't mean this wrongly, but not to take anything away from the good Dr. Lembo (a hero in his own right), it is important to give explicit credit to Mike. :-)

Nick Verge


2,701 post(s)
#29-Apr-06 14:37

Slightly off topic...

But does anyone know why the ESRI's shape file format, does not include projection information?

Since this file format was designed by one of the earliest GIS developers with plenty of experience of working with geographic information, this has always puzzled me and i just dont understand why this file format omits this information. It is not as if it is complex, geotiffs encode it without problem. Why can the shape file format do too. It is a really dumb omission.


Dream no small dreams for they have no power to change the minds of men. - After Johann Wolfgang von Goethe

Dimitri


3,145 post(s)
#01-May-06 07:02

This is just a guess, but I'd bet that if they knew projections and respected them they were overwhelmed by the technical difficulties of creating a format that would, in their minds, do projections justice. And so they just gave up and said, "OK, in this interchange format use lat/lon."

Keep in mind that a format that stores projection information does not store information on all possible projections. It only stores information on those projections that it knows about. Although it is true that most coordinate systems are parameterized variations of a much smaller number of fundamental transformations and therefore that a projection-encoding scheme could allow for a seemingly-infinite number of user-specified parameterized variations, any such scheme would still be limited to variations of the limited list of fundamental types.

When designing such a coding scheme you are therefore limited to a finite number of projections known to the developers and maintainers of the format. With very large or rich systems like, say, Oracle or MapInfo or Manifold that's not an issue because the roster of available projections is so large. But it might have seemed daunting back in the dawn of time to shapefile developers.

Note that the modern "Oh, this problem is too difficult so I'll make pretend it doesn't exist" approach that's taken by the bureaucratic imbeciles at OGC with GML doesn't solve anything, because an "extensible" approach where anyone can, in effect, re-write the format to be anything they want it to be simply ends up with a variety of incompatible formats.

It's like a multinational organization deciding to come up with a common language that everyone can use to interchange documents, say, called "LML," (Language Markup Language) where the rules of LML say that you can "extend" LML to add new verbs, nouns, syntax and grammer as you like. So the French (of course) use the extension capability to make LML look like French, the Germans commission the Goethe Institute to create LML extensions that are incomprehensible to the French and the Israelis write LML extensions that parse right-to-left. The result is zero interchange via LML even though individual constituencies who have invented their own LML flavors can read/write their proprietary flavor.

If the above scenario sounds stupid, that's exactly how GML works with the net effect of zero interop as well.

Back to shapefiles: it's evident from A to Z that shapefiles were not created by a far-seeing computer scientist but rather by someone with relatively weak computer science skills looking for a quick solution to an immediate problem. Just the idea of using .dbf in such things and creating a format consisting of multiple files is a tip-off this was not designed for the long term.

artlembo


1,871 post(s)
#29-Apr-06 15:35

"it is important to give explicit credit to Mike. :-)"

thanks for the clarification, but I personally don't mind taking credit for the good things that Mike does. In fact, if Mike could just replace his name with mine on his last 3 peer reviewed articles, I would greatly appreciate it!

mdsumner


3,617 post(s)
#30-Apr-06 01:54

Ha - Art you don't care about those, it's the next 3 you want your name on. ;)

Not doctor, yet . . .

1 msec Copyright (C) 2007-2008 Manifold.net. All rights reserved.