Take the 2-minute tour ×
Geographic Information Systems Stack Exchange is a question and answer site for cartographers, geographers and GIS professionals. It's 100% free, no registration required.

I have administrative boundaries data for communities in Switzerland from SwissTopo. Original data came in shape files with 'Bessel 1841 Hotine Oblique Mercator Azimuth Natural Origin' projection.

Full info from ArcGIS:

Projection: Hotine_Oblique_Mercator_Azimuth_Natural_Origin
False_Easting: -9419820.590700
False_Northing: 200000.000000
Scale_Factor: 1.000000
Azimuth: 90.000000
Longitude_Of_Center: 7.439583
Latitude_Of_Center: 46.952406
Linear Unit: Meter (1.000000)

Geographic Coordinate System: GCS_Bessel_1841
Angular Unit: Degree (0.017453292519943299)
Prime Meridian: Greenwich (0.000000000000000000)
Datum: D_Bessel_1841
  Spheroid: Bessel_1841
    Semimajor Axis: 6377397.155000000300000000
    Semiminor Axis: 6356078.962818188600000000
    Inverse Flattening: 299.152812799999990000

I tried defining and projecting this data into 'CH1903 LV03' (as described here) in ArcGIS 9.3 and loaded into GIS Cloud service.

When I overlay my data onto Google Maps or Open Street Map, they seem to be shifted ~200/300m NE from correct position. This happens to both original data in CH1903 LV03 and data reprojected to oter CS.

alt text

Has anyone of you encountered solution for such problem?

share|improve this question

7 Answers 7

up vote 5 down vote accepted
+100

What geographic/datum transformation did you use in ArcGIS? There aren't any for Bessel 1841 because that's an ellipsoid, rather than a geodetic datum. Is it really CH1903? Or CH1903+? The use of Bessel 1841 implies to me that the data originally came from a GRID or coverage. CH1903/CH1903+ wasn't supported in ArcInfo Workstation, so only the ellipsoid could be written to the prj.adf file. Try to define the coordinate system for the original data again as CH1903+ LV95 or CH1903 LV03, then try to project it to WGS 1984.

For the transformation try CH1903_To_WGS_1984_2 or CH1903_Plus_To_WGS_1984_1.

share|improve this answer
    
Thanks for reply. As far as I know data here usually come in either CH1903+ LV95 or CH1903 LV03. I tried defining both of these systems already but the positional error remains. –  radek Dec 2 '10 at 16:00

Google Maps doesn't use WGS84. Try re-projecting the original data to EPSG:3857

+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=@null +no_defs

ESRI used to use Web Mercator Auxiliary Sphere (WKID 102100) or Web Mercator projection (WKID 102113). You can download the .PRJ file from spatialreference.org.

share|improve this answer
    
I tried already uploading data in different CS. As well as reprojecting them within Cloud GIS to EPSG:900913. No result here. –  radek Dec 1 '10 at 19:56
1  
It might be worth it to start with the original data, re-project to 900913 with ArcGIS and upload if you haven't already. Multiple re-projections can introduce errors. Also, make sure the locally re-projected data lines up with a local dataset known to be accurate. Do you have a link for the data? –  Sean Dec 1 '10 at 20:46
2  
By the way, it's incorrect to use EPSG as the authority for 900913. 900913 is not in the EPSG Geodetic Parameter Dataset. The proper code from the EPSG authority is EPSG:3857. Disclaimer/Disclosure: I'm a member of the Geodesy subcommittee that handles the EPSG Geodetic Parameter Dataset. –  mkennedy Dec 2 '10 at 1:52
    
@mkennedy, thanks I didn't know that. –  Sean Dec 2 '10 at 15:37
1  
At ArcGIS 10, it's "WGS 1984 Web Mercator Auxiliary Sphere". This was 102100 at 9.3.1, and had its code changed to 3857 in ArcGIS 10. "WGS 1984 Web Mercator" is code 102113, and is mathematically equivalent to 102100/3857. The main difference is that "WGS 1984 Web Mercator" uses a custom sphere. "WGS 1984 Web Mercator Auxiliary Sphere" uses standard WGS84 and forces the sphere-based Mercator equations via a projection parameter. –  mkennedy Dec 2 '10 at 22:23

Some years ago I had a similar problem which I discussed in the PROJ4 mailing list (discussion thread). Some more material is also found here.

share|improve this answer
    
Thanks Markus. I've seen your post on PROJ4. Idoubt if it's CH1903+ vs. CH1903 issue, but I'll have a closer look. –  radek Dec 3 '10 at 12:04

Not a full answer, but you may have luck using MapWarper to experiment w/ different projections, as well as manual warping?

I haven't tried it, so can't fully endorse it, but it sure seems like a neat tool...

share|improve this answer
    
Thanks Dan. Will give it a try. –  radek Dec 7 '10 at 19:13

What scale was your data collected at? Although, in thinking more about it, the offset seems to be uniform...

share|improve this answer
1  
Hey Jim, that probably belongs up top in a comment, rather than being an answer. –  jvangeld Dec 11 '10 at 4:33
    
This is a good comment. A shift of 200-300m can be attributed to errors in a good map processed at a scale of 1:250,000 or so. The crude outline of the vector region in the illustration suggests the scale is pretty small, so inherent inaccuracy is likely to be part of the explanation no matter what. –  whuber Dec 11 '10 at 19:15

Had a similar-ish issue during the summer. Who knows, may inspire a solution in your case.

ArcGIS tile numbering and shift

I was displaying cached (fused) ArcGIS layers in OL. And they were always off. At every zoom level. Turns out it had to do with the tile numbering scheme. ArcGIS tiles are numbered from Top Left while everything else in OL (e.g. WMS) was from bottom left. And this caused a consistent shift in data. Solution is the above link.

share|improve this answer

This i most likely an issue with DATUM transformation not beeing applied during the coordinate transformation. ArcMap can be a mess with these kind of things..

Have you tried for example first using other tools to first transform the data to WGS84 and then transforming it to EPSG:900913?

I see that swisstopo has some scripts doing this..

You could also use the GDAL library to try transforming into WGS84 first using ogr2ogr. But be aware of the following:

There seems to be an issue with the EPSG definition of those swiss systems, especially regarding the datum transformation. Verify that your EPSG specification for CH1903 / LV03 (epsg:21781) includes TOWGS84[674.374,15.056,405.346,0,0,0,0]

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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