Jump to content

 
Photo

Reprojection Producing Unexpected Results

- - - - - FME PostGIS EPSG Reprojection

  • Please log in to reply
5 replies to this topic

#1
kweller

kweller

    Newbie

  • Validated Member
  • Pip
  • 5 posts
  • United States

I should preface this by saying I'm a software developer, not a GIS specialist. However, I've been working on GIS applications for some time now using standard tools and libraries. For this project, I'm developing a workspace using FME Desktop attached to a PostGIS database.

 

So I'm trying to reproject vector data containing lat/long coordinates (based on NAD27) to a Cartesian coordinate system with x and y values based on some sane unit of measure…something from which I can compute areas. It's been suggested that I need a coordinate reference system based on the Albers Equal-Area projection for this purpose. So I've chosen EPSG:5069, since it seems to have everything I need for the Continental U.S.

 

Using the FME Reprojector transformer, I fully expected the output to contain coordinates from EPSG:5069's declared origin and scaled to meters (since the WKT for 5069 contains the declaration UNIT["m", 1.0]). However, all output coordinates are still in lat/long, with units in degrees. Therefore, the subsequent area calculations produce nonsense results. At this point, I have no idea whether the problem is in FME, PostGIS, or my understanding of EPSG:5069.

 

For the sake of completeness, I should mention that EPSG:5069 was missing from the spatial_ref_sys table in the default PostGIS installation, so I had to insert the missing record. I got the missing WKT for the srtext field from this page:

 

http://prj2epsg.org/epsg/5069

 

And I got the missing proj4text field data by capturing the output from this PROJ.4 command:

 

cs2cs -v +init=epsg:5069

 

And finally, here's the CSV record that I loaded into spatial_ref_sys:

 

5069    EPSG    5069    PROJCS["NAD27 / Conus Albers", GEOGCS["NAD27", DATUM["North American Datum 1927", SPHEROID["Clarke 1866", 6378206.4, 294.9786982138982, AUTHORITY["EPSG","7008"]], TOWGS84[2.478, 149.752, 197.726, 0.526, -0.498, 0.501, 0.14129139227926102], AUTHORITY["EPSG","6267"]], PRIMEM["Greenwich", 0.0, AUTHORITY["EPSG","8901"]], UNIT["degree", 0.017453292519943295], AXIS["Geodetic longitude", EAST], AXIS["Geodetic latitude", NORTH], AUTHORITY["EPSG","4267"]], PROJECTION["Albers Equal Area", AUTHORITY["EPSG","9822"]], PARAMETER["central_meridian", -96.0], PARAMETER["latitude_of_origin", 23.0], PARAMETER["standard_parallel_1", 29.5], PARAMETER["false_easting", 0.0], PARAMETER["false_northing", 0.0], PARAMETER["standard_parallel_2", 45.5], UNIT["m", 1.0], AXIS["Easting", EAST], AXIS["Northing", NORTH], AUTHORITY["EPSG","5069"]]    +proj=aea +lat_1=29.5 +lat_2=45.5 +lat_0=23 +lon_0=-96 +x_0=0 +y_0=0 +datum=NAD27 +units=m +no_defs +ellps=clrk66 +nadgrids=@conus,@alaska,@ntv2_0.gsb,@ntv1_can.dat

 

So I'd like a little help figuring out what I'm doing wrong, or at least which architectural layer I should focus my attention on. Even vague hints would be welcome!

 

- Kevin



#2
Hans van der Maarel

Hans van der Maarel

    CartoTalk Editor-in-Chief

  • Admin
  • PipPipPipPipPipPipPip
  • 3,868 posts
  • Gender:Male
  • Location:The Netherlands
  • Interests:Cartography, GIS, history, popular science, music.
  • Netherlands

Where are you calculating the area? In FME or in PostGIS? I'm guessing it's in PostGIS. In FME you can use the AreaCalculator to do so (after the Reprojector of course) and I'm curious to see whether it comes up with the same results as in PostGIS. That should help you narrow down where the error is occuring.


Hans van der Maarel - Cartotalk Editor
Red Geographics
Email: hans@redgeographics.com / Twitter: @redgeographics

#3
kweller

kweller

    Newbie

  • Validated Member
  • Pip
  • 5 posts
  • United States

Actually, I'm already using the AreaCalculator in FME. But I've noticed that the coordinates coming out of the FME Reprojector are latitudes and longitudes, even before they get into the AreaCalculator. So I think the latter is working just fine, but it's being fed data that either has not been reprojected, or has been reprojected incorrectly.

 

Your comment makes me think that the problem must be somewhere in the FME world, because I'm realizing the FME Reprojector can't be calling into PostGIS to perform its calculations (if it did, the database parameters would be part of the transformer's configuration). So my next logical step is to contact Safe Software for further support. The only alternative would be to hand all the data back to PostGIS and have it perform the reprojection using ST_Transform()...but that would mean more network activity than I think is warranted. Still, if worse comes to worst, trying it in PostGIS could be a good diagnostic tool.

 

Sometimes you just need to bounce a problem off someone else to recognize the obvious. :-) Thanks, Hans!



#4
kweller

kweller

    Newbie

  • Validated Member
  • Pip
  • 5 posts
  • United States

OK, I got it working. Turns out FME didn't know the coordinate reference system for the features coming into the Reprojector. So instead of letting me know, it silently pretended that it reprojected the features, when all it really did was merely assign the destination coordinate reference system to them. <!> WTF???

 

Anyway, I just ensured that all the features were in LL27, told the Reprojector that LL27 was the correct source spatial ref, and voila! Everything comes out right. Now I've incurred enough brain damage for one week. LOL

 

- Kevin



#5
Hans van der Maarel

Hans van der Maarel

    CartoTalk Editor-in-Chief

  • Admin
  • PipPipPipPipPipPipPip
  • 3,868 posts
  • Gender:Male
  • Location:The Netherlands
  • Interests:Cartography, GIS, history, popular science, music.
  • Netherlands

OK, I got it working. Turns out FME didn't know the coordinate reference system for the features coming into the Reprojector. So instead of letting me know, it silently pretended that it reprojected the features, when all it really did was merely assign the destination coordinate reference system to them. <!> WTF???

 

Anyway, I just ensured that all the features were in LL27, told the Reprojector that LL27 was the correct source spatial ref, and voila! Everything comes out right. Now I've incurred enough brain damage for one week. LOL

 

It does kinda make sense. FME needs to know what the input coordinate system is in order to succesfully reproject. If you leave it at "read from source" and it can't figure out what it is (i.e. there's no projection information with or in the source file) it'll have to guess. That's why I always recommend specifying it in the Reprojector, even if there is a .prj file with it. Better safe than sorry.


Hans van der Maarel - Cartotalk Editor
Red Geographics
Email: hans@redgeographics.com / Twitter: @redgeographics

#6
kweller

kweller

    Newbie

  • Validated Member
  • Pip
  • 5 posts
  • United States

It does kinda make sense. FME needs to know what the input coordinate system is in order to succesfully reproject. If you leave it at "read from source" and it can't figure out what it is (i.e. there's no projection information with or in the source file) it'll have to guess. That's why I always recommend specifying it in the Reprojector, even if there is a .prj file with it. Better safe than sorry.

 

Agreed. But I also think the Reprojector should at least produce a warning in the log if it can't figure out the input coordinate system. This is based on a well-known principle in software engineering, and an FME workspace is essentially a software program. I think I will submit this as a feature request. :-)







Also tagged with one or more of these keywords: FME, PostGIS, EPSG, Reprojection

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users

-->