search

ngageoint / hootenanny

Hootenanny conflates multiple maps into a single seamless map.
GNU General Public License v3.0
350 stars 74 forks source link

Local projection vs. aerial imagery #1384

Open balazsdukai opened 7 years ago

balazsdukai commented 7 years ago

I've just managed to import my shapefiles, including their projection definition (.prj), which is the Dutch local crs. The two data sets that I want to conflate line up perfectly, but all the available aerial/satellite image options are off by ~100m. This does not keep me from doing what I want, becasue I don't need background imagery, but it made me wonder why is the big difference?

What is the CRS that Hootenanny uses internally? Should I reproject my data before importing? I didn't find anything related in the User Guide.

projection_misaligned

The .prj file:

PROJCS["Amersfoort_RD_New",GEOGCS["GCS_Amersfoort",DATUM["D_Amersfoort",SPHEROID["Bessel_1841",6377397.155,299.1528128]],PRIMEM["Greenwich",0],UNIT["Degree",0.017453292519943295]],PROJECTION["Double_Stereographic"],PARAMETER["latitude_of_origin",52.15616055555555],PARAMETER["central_meridian",5.38763888888889],PARAMETER["scale_factor",0.9999079],PARAMETER["false_easting",155000],PARAMETER["false_northing",463000],UNIT["Meter",1]]
brianhatchl commented 7 years ago

Hoot uses OGR to read in different spatial formats. I don't know that we have it configured to do any reprojection or datum transformation when converting. The offset above looks suspiciously like a datum shift to me. The osm data (and the map in iD editor) assumes a WGS84 datum.

@mattjdnv Do you know anything more?

@balazsdukai You could try reprojecting the input data to EPSG:4326 before importing and see if that fixed the shift.

balazsdukai commented 7 years ago

Yes indeed, on the image below the shifted magenta lines are based on a spheroid of Bessel 1841, and projected to the Dutch local system. The orange data that lines up well is in EPSG:4326.

datum_shift

mattjdnv commented 7 years ago

I'm pretty sure we reproject to WGS84 internally. From the Algorithms docs:

"The latitude/longitude data is stored in the database as 64 bit double precision floating point values. All values are stored in the Database in the WGS84/EPSG:4326 projection."

brianhatchl commented 7 years ago

If we are reprojecting, we are not doing a datum transformation at the same time. That's what the most recent screenshot above indicates to me.

bwitham commented 7 years ago

It should be handling the datum too, but I agree something's not right there.

Data reproject workflow is:

input projection --> wgs84 --> planar (some cleaning ops require planar; planar projection chosen for least introduced error) --> wgs84