Modify

Opened 8 years ago

Closed 7 years ago

Last modified 7 years ago

#7444 closed defect (fixed)

Broken transformation + offer boundaries (EPSG:31370 not working)

Reported by: A_Pirard Owned by: team
Priority: critical Milestone:
Component: Core Version: latest
Keywords: Cc: A_Pirard, joshdoe

Description

In the course of ticket 5387, I discovered that EPSG:31370 is not working (with Wallonie PPN).
I'm moving my comments from there to here.

Attachments (1)

African_art.png (85.1 KB) - added by A_Pirard 8 years ago.

Download all attachments as: .zip

Change History (11)

comment:1 Changed 8 years ago by A_Pirard

If you want to display raster data with a non-standard projection, then switch JOSM to THIS projection and load the layer.

I thought that EPSG:31370 is a standard. I suppose that "switch JOSM" means set Edit/Preference/WMS/Projection to Proj4J:EPSG:31370, I did.

My OSM view changed from previous Belgian map to entire black. Best bet was to use slippery map, it displayed near Bafwandese on RN4 off Kisangani (that's ex-Belgian Congo!!!) I set the view back to Belgium and JOSM displayed the map I attached as African_art.png. I tried the Wallonie PPNC overlay with both the definition you recommend and mine (forcing 31370). Both give a black map. None of the other overlay that used to work works any longer.

Changed 8 years ago by A_Pirard

Attachment: African_art.png added

comment:2 Changed 8 years ago by A_Pirard

by bastiK


Replying to A_Pirard:

I thought that EPSG:31370 is a standard. I suppose that "switch JOSM" means set Edit/Preference/WMS/Projection to Proj4J:EPSG:31370, I did. My OSM view changed from previous Belgian map to entire black.

Try with the latest version of the proj4j plugin, it should work now. (In ​[o27902])

by bastiK


Replying to stoecker:

Yes sure. We have no raster-reprojection. If you want a full-featured GIS, use one and not JOSM. If merkaartor does what you want, why not use it. Merkaartor uses proj4 library, we can't do this from josm's java core.

See #7427.

by stoecker


The plugin proj4j ist still broken. Without proper boundaries JOSM is not able to zoom properly and this makes working impossible. If proj4j does not offer boundaries, then at least the projection dialog should allow to specify them by hand.

by stoecker


Also if I display the map and go to download dialog, then area matches. But when I did download data, then it does not appear in the right position over the map. Seems one of the coordinate transformations is broken. Works with ESPG:4326 and ESPG:3857.

comment:3 Changed 8 years ago by A_Pirard

On 2012-02-20 11:56, JOSM wrote :

I suppose that "switch JOSM" means set Edit/Preference/WMS/Projection to

Proj4J:EPSG:31370, I did.

My OSM view changed from previous Belgian map to entire black.

Try with the latest version of the proj4j plugin, it should work now. (In ​[o27902])

With 27902, as compared with my previous report:

  • switching the map to 31370 no longer blackens OSM, it continues to display correct data
  • the slipping map now stays on the current view
  • but reloading the same view blackens the window, the OSM data displays elsewhere and is distorted
  • when dragging to view it, it's in a striped area, not black one.
  • Initially loading an area is correct until you try to load more but the black area turns to stripes as you move the mouse over it.

I'll continue testing this issue without reloading data until better.

comment:4 Changed 8 years ago by Don-vip

In 5022/josm:

see #5387, #7444 - Add Belgian Lambert 1972 (EPSG:31370) and Belgian Lambert 2008 (EPSG:3812) projections

comment:5 Changed 8 years ago by A_Pirard

5022 tests

I removed the Proj4j plugin to avoid confusion.
tests around http://www.openstreetmap.org/?lat=50.63091&lon=5.62633&zoom=17

Inconsistencies exist when switching main projection but that does not belong to this test.
The layers were closed and reopened when changing projection to cope with that.

Edit/Preference/WMS/Projection to WSG84 4326: OK
Edit/Preference/WMS/Projection to Mercator 3857: OK
Edit/Preference/WMS/Projection to Belgian Lambert 1972 :
. No support warning for Bing but it works
but with thin horz transparent stripes between tiles.
. Wallonie PPN fits OSM
. strangely enough, an IGN (National Geographic) server is offset
(they should know what they're doing!) requesting same
BBOX=239131.7242675,147688.0771998,239165.5047061,147721.8576384
Edit/Preference/WMS/Projection to Belgian Lambert 2008:
Bing: same as 1972
. Wallonie PPN:
<ServiceException code="InvalidSRS">
Note: no such reply for 4326 & 3857, just black or white tiles
. IGN server: fits very nicely

Glad I could help.
Keep the good work.
#7427 day will be a geat day, best of luck.

comment:6 Changed 7 years ago by bastiK

On http://www.ngi.be/FR/FR4-4.shtm they recommend different datum parameters for Lambert 1972. What is the source for the values in [5022]?

Edit: I see the code comment now (It's from http://www.eye4software.com/resources/datum/4313/). Maybe we should switch to the more official parameter set. They report an error of about 20cm, I think this is acceptable for OSM.

Last edited 7 years ago by bastiK (previous) (diff)

comment:7 Changed 7 years ago by A_Pirard

Sometimes, a "mere" 20 cm does matter ;-)
The strangest is that, as I mentioned above, their server http://www.ngi.be/testbed/wms/top10r_l08_fr? exhibits a *huge* offset.
OSM, Bing and Wallonie all coincide, but not IGN (ign.be = French for nri.be)

<entry value='EPSG:31370'/>
<entry value='BE IGN'/>
<entry value='Lambert 1972'/>
<entry value='-92.14'/>
<entry value='61.8'/>
<entry value='5.6856837423339535'/>
<entry value='50.51024229850053'/>

Not a big deal, what is most wanted is #7427 reprojection.
It's a pain to have to repeatedly switch the screen projection.

Version 1, edited 7 years ago by A_Pirard (previous) (next) (diff)

comment:8 in reply to:  7 Changed 7 years ago by bastiK

Replying to A_Pirard:

Sometimes, a "mere" 20 cm does matter ;-)
The strangest is that, as I mentioned above, their server http://www.ngi.be/testbed/wms/top10r_l08_fr? exhibits a *huge* offset.

I've cross-checked with this online converter: http://www.ngi.be/FR/FR2-1-9.shtm and the JOSM error for coordinate conversion is currently less than 1m (in the area I've checked), but IGN offset is about 100m. So I conclude that the IGN WMS is indeed very inaccurate when requesting images in Lambert 1972 and there is nothing we can do about it in JOSM.

comment:9 Changed 7 years ago by bastiK

Resolution: fixed
Status: newclosed

comment:10 in reply to:  6 Changed 7 years ago by A_Pirard

Replying to bastiK:

On http://www.ngi.be/FR/FR4-4.shtm they recommend different datum parameters for Lambert 1972. What is the source for the values in [5022]?

Edit: I see the code comment now (It's from http://www.eye4software.com/resources/datum/4313/). Maybe we should switch to the more official parameter set. They report an error of about 20cm, I think this is acceptable for OSM.

I'm not sure if this is important. I throw it in just in case.

I had previously faced http://trac.osgeo.org/proj/ticket/47 (early bug!)
My projections were wrong and I applied that fix in JOSM and Merkaartor.
That 3 yo bug must still be around in many places.
It was still here in my Ubuntu 10.04 and that's was why Mapproxy wasn't working.
Spent several hours to find why !!! :-( ('EPSG:31370' in ... not of type list' ???)

Fixed 2 years ago, that bug was fixed again 4 months ago !!!!!

Now if I look at the new values from
http://svn.osgeo.org/metacrs/proj/trunk/proj/nad/epsg
I see a very little value difference with my 2yo fix.
0.33657, -0.456955, 1.84218, 1 -> 0.3366, -0.457,1.8422, -1.2747

Would that be what you're talking about?
Or is that guy talking to you? ;-)
("... I'm closing on this assumption but please reopen again if I'm still missing something.")

Last edited 7 years ago by A_Pirard (previous) (diff)

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain team.
as The resolution will be set.
The resolution will be deleted.

Add Comment


E-mail address and name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.