{"action":"created","issue":{"url":"https://api.github.com/repos/DotSpatial/DotSpatial/issues/1203","repository_url":"https://api.github.com/repos/DotSpatial/DotSpatial","labels_url":"https://api.github.com/repos/DotSpatial/DotSpatial/issues/1203/labels{/name}","comments_url":"https://api.github.com/repos/DotSpatial/DotSpatial/issues/1203/comments","events_url":"https://api.github.com/repos/DotSpatial/DotSpatial/issues/1203/events","html_url":"https://github.com/DotSpatial/DotSpatial/issues/1203","id":355983688,"node_id":"MDU6SXNzdWUzNTU5ODM2ODg=","number":1203,"title":"Calculation of translation param in InRamImageData.GetBitmap is defective","user":{"login":"MatthiasSchilder","id":313898,"node_id":"MDQ6VXNlcjMxMzg5OA==","avatar_url":"https://avatars2.githubusercontent.com/u/313898?v=4","gravatar_id":"","url":"https://api.github.com/users/MatthiasSchilder","html_url":"https://github.com/MatthiasSchilder","followers_url":"https://api.github.com/users/MatthiasSchilder/followers","following_url":"https://api.github.com/users/MatthiasSchilder/following{/other_user}","gists_url":"https://api.github.com/users/MatthiasSchilder/gists{/gist_id}","starred_url":"https://api.github.com/users/MatthiasSchilder/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/MatthiasSchilder/subscriptions","organizations_url":"https://api.github.com/users/MatthiasSchilder/orgs","repos_url":"https://api.github.com/users/MatthiasSchilder/repos","events_url":"https://api.github.com/users/MatthiasSchilder/events{/privacy}","received_events_url":"https://api.github.com/users/MatthiasSchilder/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":0,"created_at":"2018-08-31T13:36:35Z","updated_at":"2018-08-31T13:36:48Z","closed_at":null,"author_association":"CONTRIBUTOR","body":"*IF BUG, INCLUDE THIS PART:*\r\n\r\nIf you use a web map service within a project, which has a coordinate system where coordinate values have more significant digits than a float may handle (for example EPSG 4647; 8 digits ahead of the decimal point, 3 or 4 after), you may notice the WMS-map in the background moves a few units relatively to content in the foreground (for example, features from a shapefile), every time the view extents change. The drift is variable and usually very small (< 10 CRS units).\r\n\r\n![image](https://user-images.githubusercontent.com/313898/44914358-4d32a400-ad30-11e8-8d4d-2c490c6462b7.png)\r\n![image](https://user-images.githubusercontent.com/313898/44914392-62a7ce00-ad30-11e8-8d7f-0530b6b6a00a.png)\r\n\r\nAlso you may notice, there is some space at the sides of the map control, which should be filled with the map image, but isn't.\r\n\r\n![image](https://user-images.githubusercontent.com/313898/44914672-38a2db80-ad31-11e8-9fe9-4dd4d433528d.png)\r\n![image](https://user-images.githubusercontent.com/313898/44914716-55d7aa00-ad31-11e8-8542-a228dc0a9eea.png)\r\n\r\n### Steps to reproduce\r\n\r\nDue to confidentiality constraints, I'm unfortunately not able to provide the shapefile or WMS data.\r\n\r\n1. Load a shapefile with POINT features. Features should have coordinates in a projected coordinate system, where coordinate values have many significant digits.\r\n2. Connect to a WMS, which has data available within the extents of the shapefile.\r\n3. Zoom and pan. You may notice that after each update of the WMS map, there is some drift between foreground and background layers.\r\n\r\nDotSpatial version: HEAD of master\r\n\r\n### Expected behaviour\r\n\r\nA WMS-map in the background shouldn't move relatively to some foreground content.\r\n\r\n### Actual behaviour\r\n\r\nThere should be no variable drift between foreground content and a background WMS-map.\r\n\r\n\r\n"},"comment":{"url":"https://api.github.com/repos/DotSpatial/DotSpatial/issues/comments/417666375","html_url":"https://github.com/DotSpatial/DotSpatial/issues/1203#issuecomment-417666375","issue_url":"https://api.github.com/repos/DotSpatial/DotSpatial/issues/1203","id":417666375,"node_id":"MDEyOklzc3VlQ29tbWVudDQxNzY2NjM3NQ==","user":{"login":"MatthiasSchilder","id":313898,"node_id":"MDQ6VXNlcjMxMzg5OA==","avatar_url":"https://avatars2.githubusercontent.com/u/313898?v=4","gravatar_id":"","url":"https://api.github.com/users/MatthiasSchilder","html_url":"https://github.com/MatthiasSchilder","followers_url":"https://api.github.com/users/MatthiasSchilder/followers","following_url":"https://api.github.com/users/MatthiasSchilder/following{/other_user}","gists_url":"https://api.github.com/users/MatthiasSchilder/gists{/gist_id}","starred_url":"https://api.github.com/users/MatthiasSchilder/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/MatthiasSchilder/subscriptions","organizations_url":"https://api.github.com/users/MatthiasSchilder/orgs","repos_url":"https://api.github.com/users/MatthiasSchilder/repos","events_url":"https://api.github.com/users/MatthiasSchilder/events{/privacy}","received_events_url":"https://api.github.com/users/MatthiasSchilder/received_events","type":"User","site_admin":false},"created_at":"2018-08-31T13:36:48Z","updated_at":"2018-08-31T13:36:48Z","author_association":"CONTRIBUTOR","body":"I think this is due to a bug in InRamImageData.GetBitmap. Because the matrix constructor in line 248 expects float params, all calculations in before are executed in float. This leads to a loss of precision for l and t, which causes wrong values for xShift / yShift. Simple solution seems to be to avoid the cast to float for l and t and cast only after the subsequent division, when values are small enough to be represented precisely with a float. I will open a pull request soon.\r\n\r\n![image](https://user-images.githubusercontent.com/313898/44915592-a9e38e00-ad33-11e8-878c-9d6984d7cb86.png)\r\n"}}
{"actor":{"display_login":"MatthiasSchilder"}}