regression: relation presets no longer fit correct

[Klumbumbus]

What steps will reproduce the problem?

1. download and select ​relation/5874542

What is the expected result?

tags/membership dialog should show 2 presets (works in current tested version r9329)

• geography/boundaries/protected area
• relations/boundary

What happens instead?

• no preset is shown in tags/membership dialog
• applying the relations/boundary preset again does not work
• strange behavior: removing type=boundary brings back the geography/boundaries/protected area preset

Please provide any additional information below. Attach a screenshot if possible.

also selection and relation list dialog are affected as they display different icon and text

defect in current latest (r9690) and jenkins (r9696), so no regression of r9691. maybe regression of #12412?

URL:http://josm.openstreetmap.de/svn/trunk
Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2016-01-30 21:52:03 +0100 (Sat, 30 Jan 2016)
Build-Date:2016-01-31 02:33:25
Revision:9690
Relative:URL: ^/trunk

Identification: JOSM/1.5 (9690 de) Windows 7 32-Bit
Memory Usage: 247 MB / 742 MB (51 MB allocated, but free)
Java version: 1.8.0_71-b15, Oracle Corporation, Java HotSpot(TM) Client VM
VM arguments: [-Djava.security.manager, -Djava.security.policy=file:C:\Program Files\Java\jre1.8.0_71\lib\security\javaws.policy, -DtrustProxy=true, -Djnlpx.home=<java.home>\bin, -Djnlpx.origFilenameArg=C:\Program Files\josm-latest-bla.jnlp, -Djnlpx.remove=false, -Djava.util.Arrays.useLegacyMergeSort=true, -Djnlpx.heapsize=256m,768m, -Djnlpx.splashport=62185, -Djnlpx.jvm=<java.home>\bin\javaw.exe, -Djnlpx.vmargs=LURqYXZhLnV0aWwuQXJyYXlzLnVzZUxlZ2FjeU1lcmdlU29ydD10cnVlAA==]
Dataset consistency test: No problems found

Plugins:
- AddrInterpolation (31772)
- DirectDownload (31934)
- DirectUpload (31912)
- HouseNumberTaggingTool (31772)
- OpeningHoursEditor (31772)
- PicLayer (31895)
- RoadSigns (31895)
- apache-commons (31895)
- buildings_tools (31895)
- download_along (31772)
- editgpx (31772)
- imagery_offset_db (31895)
- importvec (31772)
- log4j (31895)
- measurement (31895)
- photo_geotagging (31895)
- photoadjust (32016)
- public_transport (31895)
- reltoolbox (31895)
- reverter (32005)
- tag2link (31910)
- tageditor (31772)
- tagging-preset-tester (31895)
- terracer (31895)
- turnlanes (31772)
- turnrestrictions (31895)
- undelete (31895)
- utilsplugin2 (32018)
- wikipedia (32003)

Last errors/warnings:
- W: org.openstreetmap.josm.io.OsmApiException: ResponseCode=401
- W: org.openstreetmap.josm.io.OsmApiException: ResponseCode=401
- W: java.net.SocketException: Socket Closed
- E: java.net.SocketException: Socket Closed
- W: org.openstreetmap.josm.io.OsmApiException: ResponseCode=401

[stoecker]

Probably boundaries are handled as multipolygon, as the follow the same methods?

[Klumbumbus]

I thought that when boundary=*is used then you should use type=boundary. However wiki is not clear about this. Also the usage is different. type=multipolygon is used more than type=boundary, see e.g. ​http://taginfo.openstreetmap.org/tags/boundary=protected_area?filter=relations#combinations. Our preset doesn't set type at all.

[stoecker]

Replying to Klumbumbus:

I thought that when boundary=*is used then you should use type=boundary. However wiki is not clear about this. Also the usage is different. type=multipolygon is used more than type=boundary, see e.g. ​http://taginfo.openstreetmap.org/tags/boundary=protected_area?filter=relations#combinations. Our preset doesn't set type at all.

type=multipolygon was something introduced by Frederik. For admin boundaries JOSM silently changes this to boundary (other types is does not touch yet). But that's not what I meant. boundary and multipolygon use the same data model and are handled in JOSM alike. Thus the splitting of multipolygon and relation very likely also moved boundaries into "multipolygon" group.

[Don-vip]

In 9716/josm:

fix #12467, see #12412 - presets no longer fit correct for boundary relations (regression from r9574)