Modify

Opened 9 months ago

Last modified 36 minutes ago

#16073 new enhancement

ImageryCompare for dead layers

Reported by: marc_marc Owned by: team
Priority: normal Milestone: 18.12
Component: Unit tests Version:
Keywords: Cc:

Description

eli check and remove some not working layers.
those layers are show in "URLs found in JOSM but not in ELI" (that's right) but in blue (= should be checked).
To avoid the need to make the same check "by hand" for josm or to make a lookup in eli history for every layers, it would be nice if ImageryCompare (or a dedicated page) could make the same checks and/or used those checks. for exemple missing layer in josm that return a 404 could be tagged in red to easy see that they need to be renove also from josm.
of course it would be nice it the same tools could be shared between both "index" (I also did the same a request at eli)

NB: here is a POC that show removed eli layers not already removed from josm
NB: I start removing those 12 layers by hand, but adding this info in ImageryCompare 'll be usefull for everyone that use it.

Attachments (2)

NLSC.jpg (173.5 KB) - added by stoecker 13 days ago.
notforme.png (32.6 KB) - added by Don-vip 13 days ago.

Download all attachments as: .zip

Change History (68)

comment:1 Changed 9 months ago by Stereo

My POC works but is unreadable :). Basically it looks at the URLs that have disappeared in imagery.geojson since an arbitrary commit at the beginning of the year, keeps only those with } to filter out attribution URLs etc., and compares the URLs to the ones ImageryCompare says are missing.

comment:2 Changed 9 months ago by stoecker

I'm thinking about a way to detect dead entries. But it may take some time to think and implement a proper solution.

comment:3 Changed 9 months ago by Stereo

Martin over at ELI is working on the problem too. He's requesting tiles within the layer's bbox to make sure it's returning something.

comment:4 in reply to:  3 Changed 9 months ago by stoecker

Replying to Stereo:

Martin over at ELI is working on the problem too. He's requesting tiles within the layer's bbox to make sure it's returning something.

Jupp. That's one of the points ;-)

comment:5 Changed 2 weeks ago by Don-vip

In 14482/josm:

see #16073, see #17056 - initialize imagery integration test

comment:6 Changed 2 weeks ago by Don-vip

First batch of errors:

outdated

Last edited 7 days ago by Don-vip (previous) (diff)

comment:7 Changed 2 weeks ago by Klumbumbus

Regarding https://josm.openstreetmap.de/wiki/Maps/France?action=diff&version=146 I think it was supposed to display the EULA in the language which is set in JOSM if available. Currently available are english and french: https://wiki.openstreetmap.org/wiki/WikiProject_France/CRAIG/EULA

comment:8 Changed 2 weeks ago by stoecker

Seems there are some errors:

I think you should output >= 300 HTTP errors, so we can fix redirects as well. They should be warnings, not errors.

We have some certificate issues, probably due to missing full chain.

Last edited 2 weeks ago by stoecker (previous) (diff)

comment:9 in reply to:  7 Changed 2 weeks ago by stoecker

Replying to Klumbumbus:

Regarding https://josm.openstreetmap.de/wiki/Maps/France?action=diff&version=146 I think it was supposed to display the EULA in the language which is set in JOSM if available. Currently available are english and french: https://wiki.openstreetmap.org/wiki/WikiProject_France/CRAIG/EULA

Yes. There is code in ImageryPreference.java for this. The Map change should be reverted and the check simply replace {lang} with the default "" for this test here.

comment:10 Changed 2 weeks ago by stoecker

In 14485/josm:

handle {lang} for EULA, see #16073

comment:11 Changed 2 weeks ago by stoecker

In 14487/josm:

more helpful exception text, see #16073

comment:12 Changed 13 days ago by stoecker

In 14488/josm:

add warning for 3xx status codes (non ATM), see #16073

comment:13 Changed 13 days ago by Don-vip

In 14496/josm:

fix #17060, see #16073 - Support Internationalized domain names (IDN)

This allows JOSM to accesss https://öpnvkarte.de

comment:14 in reply to:  8 Changed 13 days ago by Don-vip

Replying to stoecker:

Do you mean you have already sent an e-mail, or do you want someone to do it?

comment:15 Changed 13 days ago by stoecker

Ooops. Should be "sent".

comment:16 Changed 13 days ago by Don-vip

In 14497/josm:

fix #17060, see #16073 - update integration test

comment:17 Changed 13 days ago by Klumbumbus

Component: External imagery sourceUnit tests
Milestone: 18.12

comment:18 Changed 13 days ago by Don-vip

In 14498/josm:

fix #17062, see #16073 - Load Taiwan Government Root CA certificate

This allows JOSM to accesss https://data.gov.tw/license

comment:19 Changed 13 days ago by Klumbumbus

For wiki:/Maps/Taiwan#NLSCOpenDataWMTS JOSM says "No layers defined by getCapabilities document: https://maps.nlsc.gov.tw/OpenData/wmts". Wrong WMTS file or a bug in JOSM?

comment:20 Changed 13 days ago by Don-vip

https://maps.nlsc.gov.tw seems dead, I have sent an e-mail to them

Changed 13 days ago by stoecker

Attachment: NLSC.jpg added

comment:21 in reply to:  20 Changed 13 days ago by stoecker

Replying to Don-vip:

https://maps.nlsc.gov.tw seems dead, I have sent an e-mail to them

Hmm, why?


Last edited 7 days ago by Don-vip (previous) (diff)

Changed 13 days ago by Don-vip

Attachment: notforme.png added

comment:22 Changed 13 days ago by Don-vip

Because of this. But I don't know why, this is the only site I cannot access:

Last edited 7 days ago by Don-vip (previous) (diff)

comment:23 Changed 13 days ago by Don-vip

Is it IPv6 only? My DNS resolves to an IPv4 address while JOSM server resolves to an IPv6 one.

comment:24 Changed 13 days ago by Don-vip

In 14499/josm:

see #16073 - initialize tile source

comment:25 in reply to:  23 Changed 12 days ago by stoecker

Replying to Don-vip:

Is it IPv6 only? My DNS resolves to an IPv4 address while JOSM server resolves to an IPv6 one.

Yes. IPv6 is broken for their site: https://[2001:e10:6040:143::28]/

comment:26 Changed 12 days ago by Don-vip

In 14507/josm:

see #16073 - test tile source

comment:27 Changed 11 days ago by Don-vip

To test that max zoom is correct I need to know where to check. For local providers I simply choose the center of the bbox, but for global providers it is more tricky, as the max zoom isn't available globally. For example with ESRI, they provide the available resolutions per area. It appears the more precise location is Santa Rosa, California, USA:

https://wayback-usw2.maptiles.arcgis.com/arcgis/rest/services/World_Imagery/MapServer/tile/18820/22/1611358/667371

Question is: how do we store this information in the wiki? I suggest a new attribute, something like <test-max-zoom-location>38.438631,-122.719048<test-max-zoom-location>

We could also add a <test-no-tile-location> to test the validity of <no-tile-header>.

Comments?

Last edited 11 days ago by Don-vip (previous) (diff)

comment:28 Changed 11 days ago by Don-vip

In 14512/josm:

see #16073 - improve test

comment:29 Changed 10 days ago by stoecker

Don't get too sophisticated. A general availability check should be enough.

comment:30 Changed 10 days ago by Don-vip

OK we can keep this for later. I'll check at a lower zoom.

comment:31 Changed 10 days ago by Don-vip

In 14513/josm:

see #16073 - rework/simplify max zoom test

comment:32 Changed 10 days ago by Don-vip

In 14514/josm:

see #16073 - messed up parameters order

comment:33 Changed 10 days ago by Don-vip

In 14515/josm:

see #16073 - use Greenwich instead of (0,0) for global sources

comment:34 Changed 10 days ago by Don-vip

In 14516/josm:

see #16073 - ignore check when max-zoom not defined (344 entries)

comment:35 Changed 10 days ago by stoecker

According to AbstractTileSourceLayer the default Max-Zoom we use is 20. You could use that for tests, so that we can fix these which have 18 only.

comment:36 Changed 10 days ago by stoecker

Or you use the function of the tile layer to get the MaxZoom, which takes the default into account :-)

comment:37 Changed 8 days ago by Don-vip

In 14519/josm:

see #16073 - handle entries with several shapes (like French 'BDOrtho IGN')

comment:38 Changed 7 days ago by Don-vip

In 14521/josm:

see #16073 - handle entries where centroid does not lie in shape (like Canadian 'British Columbia Mosaic')

comment:39 Changed 7 days ago by Don-vip

In 14522/josm:

see #16073 - add robustness

comment:40 Changed 7 days ago by Don-vip

In 14523/josm:

see #16073 - make sure correct projection is used

comment:41 Changed 7 days ago by Don-vip

In 14524/josm:

see #16073 - fix NPE

comment:42 Changed 7 days ago by stoecker

Drop SPOT in sources as well: [o34776].

comment:43 Changed 7 days ago by stoecker

How do we want to handle known invalid entries like the TLS problems? Add an Ignore list to ImageryCompareIgnores in some form? Maybe a second table?

comment:44 Changed 7 days ago by Don-vip

In 14526/josm:

see #16073 - increase timeouts, don't test max-zoom for scanex

comment:45 in reply to:  42 ; Changed 7 days ago by Don-vip

Replying to stoecker:

Drop SPOT in sources as well: [o34776].

Fixed in [o34777]. You should use an IDE to spot compile errors :p

Replying to stoecker:

How do we want to handle known invalid entries like the TLS problems? Add an Ignore list to ImageryCompareIgnores in some form?

A separate page with the same idea sounds good.

comment:46 in reply to:  45 Changed 7 days ago by stoecker

Replying to Don-vip:

Replying to stoecker:

Drop SPOT in sources as well: [o34776].

Fixed in [o34777]. You should use an IDE to spot compile errors :p

Compiling also for simple fixes would be enough as well. ;-)

How do we want to handle known invalid entries like the TLS problems? Add an Ignore list to ImageryCompareIgnores in some form?

A separate page with the same idea sounds good.

Why separate? ImageryCompare already handles a lot of other non-remote validity checks. Keeping that in one place is not strange I'd say.

comment:47 Changed 7 days ago by Don-vip

The point of this test is not to compare with ELI but check the validity of our own sources. I have other tests like this (validity of our plugins, presets, validator rules, etc.) that also fail quite often and could benefit from a common page like IntegrationTestIgnores. Right now I exclude some presets directly in the Java source code, it's not ideal.

Also the TLS stuff from example has nothing to do with ELI: from a web browser, it works. It only concerns Java.

comment:48 in reply to:  47 ; Changed 7 days ago by stoecker

Replying to Don-vip:

The point of this test is not to compare with ELI but check the validity of our own sources.

I know. Nevertheless ImageryCompare actually is an ImageryCompareAndCheckValidity test already. A lot of that stuff has nothing to do with ELI as well. It was only a place where these checks could be added without duplicating a lot of effort.

I have other tests like this (validity of our plugins, presets, validator rules, etc.) that also fail quite often and could benefit from a common page like IntegrationTestIgnores. Right now I exclude some presets directly in the Java source code, it's not ideal.

A generic page for all integration tests is not a bad idea. Format could be similar to the ignores page, but adding a integration test name as first column.

comment:49 in reply to:  48 Changed 7 days ago by Don-vip

Replying to stoecker:

Format could be similar to the ignores page, but adding a integration test name as first column.

That's what I had in mind :)

comment:50 Changed 7 days ago by Don-vip

In 14527/josm:

see #16073 - fix timeouts

comment:51 Changed 7 days ago by Don-vip

In 14528/josm:

see #16073 - handle ignore list

comment:52 Changed 7 days ago by Don-vip

In 14529/josm:

see #16073 - increase timeout

comment:53 Changed 7 days ago by Don-vip

In 14530/josm:

see #16073 - better error message

comment:54 Changed 6 days ago by Don-vip

In 14532/josm:

see #16073 - avoid spurious warnings

comment:55 Changed 6 days ago by Don-vip

In 14533/josm:

see #16073 - use custom http headers when required

comment:56 Changed 6 days ago by Don-vip

In 14535/josm:

see #16073 - check response contents
see #16854 - stability of created primitive IDs (accidental commit...)

comment:57 Changed 6 days ago by Don-vip

In 14536/josm:

see #16073 - check response contents with correct cache

comment:58 Changed 6 days ago by Don-vip

In 14538/josm:

see #16073 - avoid multiline error messages

comment:59 Changed 6 days ago by Don-vip

In 14539/josm:

see #16073 - check response contents correctly

comment:60 Changed 6 days ago by Don-vip

In 14544/josm:

see #16073 - don't log duplicate errors

comment:61 Changed 5 days ago by Don-vip

In 14549/josm:

see #16073 - support WMS_ENDPOINT

comment:62 Changed 5 days ago by Don-vip

In 14550/josm:

see #16073 - rework error handling

comment:63 Changed 5 days ago by Don-vip

In 14551/josm:

see #16073 - detect correct min_zoom value

comment:64 Changed 4 days ago by Don-vip

In 14553/josm:

see #16073 - avoid unnamed layers

comment:65 Changed 2 hours ago by Don-vip

In 14564/josm:

see #16073 - better detection of bad zoom errors

comment:66 Changed 36 minutes ago by Don-vip

In 14565/josm:

see #16073 - detection of json errors

Modify Ticket

Change Properties
Set your email in Preferences
Action
as new The owner will remain team.
as The resolution will be set.
to The owner will be changed from team to the specified user.
The owner will change to marc_marc
as duplicate The resolution will be set to duplicate.The specified ticket will be cross-referenced with this ticket
The owner will be changed from team to anonymous.

Add Comment


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

 
Note: See TracTickets for help on using tickets.