Modify

Opened 2 years ago

Closed 2 years ago

#14133 closed defect (invalid)

mismatching of data and imagery projections

Reported by: greg.schmidt@… Owned by: team
Priority: normal Milestone:
Component: Core Version: latest
Keywords: projection Cc:

Description

Background:

  • we have played around using the different imagery projections in JOSM, switching between imagery sources of 3857 and 4326. The imagery loader properly does not allow an imagery source other than what JOSM is setup for to load (i.e. if JOSM set to load 4326, it will refuse to load a 3857 source properly). Good so far.
  • When we switch to imagery using 4326, and still have a OSM data source dishing out 3857 vector data, JOSM allows it do display and does not put out a warning.

Questions:
1) is this what everyone else has observed?
2) does JOSM not automatically reproject the 3857 data vector source to the source that imagery is in (.e.g. 4326)?
3) should JOSM put out a warning if the data vectors are of a different projection than what is assigned for the imagery?

Mark this ticket as a possible defect for now.

Attachments (2)

imageryLoadError.png (196.0 KB) - added by anonymous 2 years ago.
esriImagery.png (119.5 KB) - added by anonymous 2 years ago.

Download all attachments as: .zip

Change History (16)

comment:1 in reply to:  description Changed 2 years ago by bastiK

Replying to greg.schmidt@…:

Questions:
1) is this what everyone else has observed?

Yes.

2) does JOSM not automatically reproject the 3857 data vector source to the source that imagery is in (.e.g. 4326)?

The vector data will always respect the global projection, as configured in the preferences. Generally, the projection of the background imagery must match the global projection. However, it is a common case that WMS servers support 4326, but not 3857. As it happens, you get very reasonable results if 4326 tiles are simply stretched and displayed on top of a 3857 map. So as an exception, we do that.

3) should JOSM put out a warning if the data vectors are of a different projection than what is assigned for the imagery?

See also epsg4326to3857Supported parameter on Maps.

comment:2 Changed 2 years ago by anonymous

So let me explain our dilemma then:

  • we have a 4326 imagery source and were forced to set the global projection (data vector projection) to 4326 to be able to load it into josm. The imagery loads and displays fine.
  • however, the vector data source (still in web mercator 3857) doesn't seem to reproject over the 4326 imagery. It doesn't come close to aligning with it. Not any clear indicators of matching vectors to imagery locations ...the vectors are unmatchable.

Are we doing something wrong?

comment:3 Changed 2 years ago by anonymous

note - the same vector and imagery source work fine in Arc Map

comment:4 in reply to:  2 Changed 2 years ago by bastiK

Replying to anonymous:

So let me explain our dilemma then:

  • we have a 4326 imagery source and were forced to set the global projection (data vector projection) to 4326 to be able to load it into josm. The imagery loads and displays fine.

You can display 4326 imagery source with global projection being set to 3857.

  • however, the vector data source (still in web mercator 3857) doesn't seem to reproject over the 4326 imagery. It doesn't come close to aligning with it. Not any clear indicators of matching vectors to imagery locations ...the vectors are unmatchable.

Are we doing something wrong?

What kind of vector data source are we talking about? I'm assuming you opened a .osm file. A screenshot may clarify the situation.

comment:5 Changed 2 years ago by anonymous

we have a 4326 imagery source and were forced to set the global projection (data vector projection) to 4326 to be >>able to load it into josm. The imagery loads and displays fine.

You can display 4326 imagery source with global projection being set to 3857.

Ok so we get warned when global projection set to 3857 when trying to load the 4326 imagery source.
Are you possibly suggesting that we need to set the epsg4326to3857Supported=True for this case then? and this will suppress the warning and allow the imagery to load and furthermore allow the stretching of the OSM vector data to occur to match?

comment:6 Changed 2 years ago by anonymous

will get you an image shortly, but want to confirm a few things here. We have tested both with imagery sources of WMS and WMTS. Not sure if the WMTS acts the same as WMS in this situation.

comment:7 Changed 2 years ago by Klumbumbus

<epsg4326to3857Supported>true</epsg4326to3857Supported> only suppresses the warning massage, nothing more.

Please additional to the screenshot let use know, which imagery you are using and the required parts of your JOSM Status Report.

Changed 2 years ago by anonymous

Attachment: imageryLoadError.png added

Changed 2 years ago by anonymous

Attachment: esriImagery.png added

comment:8 Changed 2 years ago by anonymous

Image source:


http://server.arcgisonline.com/arcgis/rest/services/ESRI_Imagery_World_2D/MapServer/WMTS/1.0.0/WMTSCapabilities.xml
Note it is WMTS. Hopefully ok?

The Warning we get should be what you referred to above for a warning.

But pretty sure after this warning, it does not load unless we switch the global projection to the 4326.
This is what I am trying to double-confirm.

comment:9 Changed 2 years ago by anonymous

I am downloading your latest stable JOSM.
Will test the imagery source above with default Web Mercator (3857).
Will confirm the warning and see if the service actually loaded it or not.
I think we saw the Warning and assumed it failed. That's when we switched the Global projection to 4326.
Back to you in a little bit.

comment:10 Changed 2 years ago by anonymous

Will write back tonight. Dont have access to make the open source JOSM work right now.

comment:11 Changed 2 years ago by anonymous

Ok we tried the following:

  • global projection 3857
  • loaded a WMTS image source in 4326 and got the warning.
  • it also did not add the entry into the Imagery sources list. So it failed.

The difference though is we used a WMTS source. Perhaps WMS is the only one that will allow the 4326 image to load when global data projection set to 3857?

We dont have a WMS 4326 source off hand. Searching. Do you by chance?

comment:12 in reply to:  11 Changed 2 years ago by bastiK

Replying to anonymous:

Ok we tried the following:

  • global projection 3857
  • loaded a WMTS image source in 4326 and got the warning.
  • it also did not add the entry into the Imagery sources list. So it failed.

The difference though is we used a WMTS source. Perhaps WMS is the only one that will allow the 4326 image to load when global data projection set to 3857?

Yes, this seems to be the case.

We dont have a WMS 4326 source off hand. Searching. Do you by chance?

See for example Rio Mosaic 2013.

comment:13 Changed 2 years ago by anonymous

ok tested that and it works.

The thing we are trying to look at is:

compare the 4326 shifted to a 3857 projected imagery. We would need same source or very close slew angle to compare them. And enough overlapping visibility to drop points on corners or landmarks and make a comparison.

We are curious how closely the shift is to the Web Mercator (3857).

If you have a similar source for the Rio Mosaico 2013 but in 3857, please forward. Otherwise, feel free to close this ticket. Thanks

comment:14 Changed 2 years ago by bastiK

Resolution: invalid
Status: newclosed

At street-level zoom and with reasonable tile size, the distortion is extremely small. The WMS server NRW-Atlas:Luftbilder supports both 3857 and 4326. Please reopen, if you have specific requests.

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.