Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#12573 closed defect (fixed)

JOSM uses the wrong WMTS layer identifier

Reported by: sanderd17 Owned by: team
Priority: normal Milestone: 16.04
Component: Core imagery Version:
Keywords: template_report wmts Cc:


I have a problem loading the new AGIV WMTS layers ( ). These layers offer different imagery which are all under an ODBL-compatible license.

When when adding the WMTS url, and trying to load it, most of the names of the layers are some sort of hexadecimal strings. And when trying to load such a layer, it fails with 501 server errors on every tile request.

After some investigation, I found that JOSM seems to use the identifier from the wrong ows:Identifier XML node.

F.e. instead of using the "grb_bsk_grijs" identifier (which is directly under the Layer node), it uses an identifier "E2707D13-B366-4D25-A286-E1B1330CADF7GRB_BSK_GRIJS" which is some obscure string under a ows:DatasetDescriptionSummary node.

When I understand the WMTS standard correctly, the above WMTS document is a valid one, so should be parsed correctly by JOSM.

Would it be possible to only consider ows:Identifier nodes that are 1st-generation children of Layer nodes, and ignore the other identifiers?

System info:

Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2016-01-06 17:30:31 +0100 (Wed, 06 Jan 2016)
Build-Date:2016-01-06 16:32:31
Relative:URL: ^/trunk

Identification: JOSM/1.5 (9329 en_GB) Linux Arch Linux
Memory Usage: 290 MB / 629 MB (72 MB allocated, but free)
Java version: 1.8.0_74, Oracle Corporation, OpenJDK Server VM
VM arguments: [-Djosm.restart=true]

- Mapillary (32040)
- PicLayer (31895)
- SimplifyArea (31895)
- apache-commons (31895)
- apache-http (31895)
- buildings_tools (31895)
- ejml (31895)
- geochat (31895)
- geotools (31895)
- jts (31772)
- log4j (31895)
- measurement (31895)
- opendata (31937)
- terracer (31895)
- utilsplugin2 (32018)

Attachments (0)

Change History (9)

comment:1 Changed 5 years ago by wiktorn

In 9887/josm:

Properly interpret more complex getCapabilities documents.

Keep a track of how deep into the XML tree reader has traversed. Do the
interpretation of the tags only if they are present at proper level.

If unknown tag is found, move the reader to the end of the tag, to avoid

When using moveToReader within parseLayer, it is needed, to keep tagStack

This should fix problems with BE WMTS imagery - See: #12573

comment:2 Changed 5 years ago by wiktorn

Test case for this problem is outstanding / WIP

comment:3 Changed 5 years ago by wiktorn

In 9888/josm:

Properly handle situation, when Style tag doesn't contain Identifier.

See: #12573

comment:4 Changed 5 years ago by Don-vip

Milestone: 16.02

comment:5 Changed 5 years ago by Don-vip

Can this ticket be closed?

comment:6 Changed 5 years ago by wiktorn

Keep this open for me, I'll close it committing the test cases

comment:7 Changed 5 years ago by Don-vip

Milestone: 16.0216.03


comment:8 Changed 5 years ago by wiktorn

Resolution: fixed
Status: newclosed

In 9902/josm:

Final fix for #12573 - WMTS getCapabilities parser error.

Unit tests for case in #12573 and some edge case. Fix for edge case.

Closes: #12573

comment:9 Changed 5 years ago by Don-vip

Milestone: 16.0316.04

Milestone renamed

Modify Ticket

Change Properties
Set your email in Preferences
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.