5

I have the Census TIGER data for Oregon from

http://www.census.gov/geo/maps-data/data/tiger-data.html

Then the bottom one of 2010 Census Population & Housing Unit Counts — Blocks.

The shapefile loads fine into QGIS 1.8 and shows it as EPSG 4269/NAD83.

Then I have this city data from the State of Oregon Website.

http://navigator.state.or.us/sdl/data/shapefile/m2/cities.zip

It claims to be in EPSG 4269/NAD83 also.

When I first loaded it up the scale of both were WAY off. The projection of the Cities you had to zoom out so far to see that the state population map became a tiny dot. (i.imgur.com/QZLQjfO.jpg) I re-saved the cities shapefile and chose to save it as a EPSG 4269/NAD83 and reloaded it. Now they both show on the same scale but the cities is far south of the Tiger file. (i.imgur.com/wI1OzSG.jpg) I tried enabling on the fly projections to see if that would fix it and no go. I manually loaded up some geocoded addresses under the NAD83 and they fit perfectly onto the TIGER/Census map so I think there is something wacky with the city data but I can't figure it out.

I am pretty new to QGIS and very much a novice at GIS in general. Any tips or ideas on ways to get these to line up would be helpful.

I have found that if I save other files to 3644 they match up with the Cities data. But if I save the cities data as any style let it be 3644 or 4269 it no longer matches up it becomes like Image 2 where it is way south of the other files. This leads me to think that the Cities file has some sort of lat/long correction that when saving to other CRS or when re-projecting as other CRS causes it to show up very far south. Now investigating how to remove/fix this attribute any and all help is appreciated.

Improve this question
2
  • Check in settings if the project crs is set to the correct one and that enable on the fly projections is checked.
    – Ger
    Commented Sep 9, 2013 at 15:50
  • Yup, both are set but the cities are still very much what appears to be south of where the TIGER data shows up.
    – DanTheMan
    Commented Sep 9, 2013 at 15:53

1 Answer 1

Reset to default
4

Pasting the Cities .prj file in to http://prj2epsg.org/search gives me EPSG:3644 - NAD83(NSRS2007) / Oregon Lambert (ft) which sounds plausible.

EDIT:

I had to explicitly select EPSG:3644 and everything lines up for me.

enter image description here

Improve this answer
6
  • Let me go take that a try. I will report back.
    – DanTheMan
    Commented Sep 9, 2013 at 16:29
  • if that is correct then QGis should work it out - check you have on-the-fly reprojection turned on
    – Ian Turton
    Commented Sep 9, 2013 at 16:34
  • Same issue, when I use the default file for cities (the one that I didn't save as 4269) and the original TIGER file then tell it to "on the fly" project for 3644 they are still very north/south of each other. Just like this [link](i.imgur.com/wI1OzSG.jpg)[/link] picture shows. So even when I force them to the same EPSG via saving or on the fly they are still very far off from each other. It is really strange. Is it due to the fact that the cities was originally done in Feet and during the conversion unit measurement gets messed up? That website is very cool and useful though!
    – DanTheMan
    Commented Sep 9, 2013 at 16:37
  • Very strange. If I save-as on the TIGER data and save it to 3644 then load that to the ogirinal Cities file they match up. Yet when I save the Cities data and output it to 4269 it does not match up to the TIGER data. Very strange. I guess I'll just work in 3644 and convert everything to 3644 in place of converting the single 3644 file to 4269. Does this sound like a plausible method to work under? There isn't any advantage/disadvantage to the different CRS's? As long as everything is using the same CRS and match up, than everything should work out just fine correct? Sorry for all the ?s
    – DanTheMan
    Commented Sep 9, 2013 at 17:00
  • Hrm I am starting to think that 3644 isn't what the cities data is set it. I think it is 3644 with some sort of Lat/Long correction because when I export the TIGER data to 3644 and load it with the cities it matches but then when I load in other data and tell it to "On the fly" re-project for 3644 the TIGER data and the new data match and the Cities data goes way far south again...
    – DanTheMan
    Commented Sep 9, 2013 at 17:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.