Opened 13 years ago

Closed 13 years ago

#3630 closed bug (worksforme)

Coordinate reference system ETRS89/UTM zone 33N (EPSG: 25833) is wrong

Reported by: monokultur Owned by: nobody
Priority: major: does not work as expected Milestone: Version 1.7.0
Component: Projection Support Version: 1.6.0
Keywords: Cc:
Must Fix for Release: Yes Platform: OS X
Platform Version: 10.6.6 Awaiting user input: yes

Description

The polygons of shape-files created/converted in zone ETRS89/UTM 33N (EPSG: 25833) are at the wrong place (about 1000 km to far west). The facts have been checked with other GIS programs.

Attachments (1)

Shape_UTM.zip​ (71.6 KB ) - added by monokultur 13 years ago.

Download all attachments as: .zip

Change History (11)

in reply to:  description comment:1 by lutra, 13 years ago

Replying to monokultur:

. The facts have been checked with other GIS programs.

this means it only happens in qgis or in all the sw you have tested?

comment:2 by monokultur, 13 years ago

It only happens in qgis. All other gis programs are projecting the polygones at the right place.

comment:3 by lutra, 13 years ago

can you please attach a sample data?

by monokultur, 13 years ago

Attachment: Shape_UTM.zip​ added

in reply to:  3 ; comment:4 by monokultur, 13 years ago

The attached file shows some fields in north-east germany. you can check with the digital ortho photos (wms-server url: ​http://www.geodaten-mv.de/dienste/adv_dop) if they are at the right place (the photos are visible only at a certain scale)

in reply to:  4 ; comment:5 by jef, 13 years ago

Priority: critical: causes crash or data corruption → major: does not work as expected

Replying to monokultur:

The attached file shows some fields in north-east germany. you can check with the digital ortho photos (wms-server url: ​http://www.geodaten-mv.de/dienste/adv_dop) if they are at the right place (the photos are visible only at a certain scale)

In ​http://spatialreference.org/ref/epsg/25833/ EPSG:25833 the x coordinates usually has only 6 digits. Unfortunately what MV (and also Brandenburg) calls EPSG:25833 is EPSG:25833 with an offset of 33000000m (and formerly only 3000000m). On ​http://www.geoportal-mv.de/land-mv/GeoPortalMV_prod/de/Geowebdienste/Hinweise_Geowebdienste/index.jsp#epsgportal Hinweise Geowebdienste - GeoPortal Mecklenburg-Vorpommern] this is called EPSG:35833 and explictly marked as not OGC conformant. I've also found [[http://gdi.berlin-brandenburg.de/papers/gap.pdf sources that call this BBG:25833 and also have "our" definition of EPSG:25833.

I'm not sure how we should deal with this.

BTW assigning a user defined CRS with +proj=tmerc +lon_0=15 +ellps=GRS80 +k=0.9996 +units=m +datum=WGS84 +x_0=33500000 puts the shape exactly on the above WMS in EPSG:4326.

in reply to:  5 comment:6 by jef, 13 years ago

Replying to jef:

BTW assigning a user defined CRS with +proj=tmerc +lon_0=15 +ellps=GRS80 +k=0.9996 +units=m +datum=WGS84 +x_0=33500000 puts the shape exactly on the above WMS in EPSG:4326.

Same for the shape moved 33000000m westward and set to EPSG:25833.

comment:7 by monokultur, 13 years ago

Is it possible to integrate EPSG: 35833 into qgis?

in reply to:  7 comment:8 by jef, 13 years ago

Replying to monokultur:

Is it possible to integrate EPSG: 35833 into qgis?

Does that help? E.g. it won't on OGC services that are advertised with EPSG:25833.

BTW which other softwares did you try this with?

comment:9 by jef, 13 years ago

Awaiting user input: set

comment:10 by jef, 13 years ago

Resolution: → worksforme
Status: new → closed

closing for the lack of feedback.

Note: See TracTickets for help on using tickets.