wrong "area style on outer member" error

[dieterdreist]

What steps will reproduce the problem?

1. validator problem on upload

What is the expected result?

no problem

What happens instead?

Validator _ERROR_

IMHO this should be at most a "notice", surely not an "ERROR". Errors are believed by most mappers to be always wrong, and that's also what your description suggests (should normally be fixed).

There is no general problem with area tags on things that are also part of a multipolygon relation with an outer role. The only problem is old style multipolygons, but those should be resolved by now, I suggest to remove this test completely.

Example: relation 7604503

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

URL:http://josm.openstreetmap.de/svn/trunk
Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2017-09-24 17:02:23 +0200 (Sun, 24 Sep 2017)
Build-Date:2017-09-25 01:33:33
Revision:12895
Relative:URL: ^/trunk

Identification: JOSM/1.5 (12895 en) Mac OS X
Memory Usage: 569 MB / 1820 MB (362 MB allocated, but free)
Java version: 1.8.0_121-b13, Oracle Corporation, Java HotSpot(TM) 64-Bit Server VM
Screen: Display 188875522 1920x1080, Display 458628992 1920x1080
Maximum Screen Size: 1920x1080
VM arguments: [-Dsun.java2d.opengl=true]
Dataset consistency test: No problems found

Last errors/warnings:
- W: No configuration settings found.  Using hardcoded default values for all pools.
- W: java.io.IOException: Cannot run program "xdg-open": error=2, No such file or directory. Cause: java.io.IOException: error=2, No such file or directory
- W: java.io.IOException: Cannot run program "xdg-open": error=2, No such file or directory. Cause: java.io.IOException: error=2, No such file or directory

[Don-vip]

@team: what do you think? I don't see us adding a special case for this. Maybe deleting the test as suggested is the best move?

[dieterdreist]

there's really no way JOSM can tell which kind of area tags should belong to which object (way or relation). It is one of the purposes of multipolygon relations to reuse existing geometry, and there is no problem with overlapping areas, as long as they describe different things.

[stoecker]

The ​relation 7604503 is simply wrong. It is no multipolygon, so the validator error is 100% correct. Probably you wanted to use ​type=site.

[dieterdreist]

I don't see why this relation would be "simply wrong", nor do I understand what would be different if I'd use a site relation. From my understanding, the only purpose where a site relation is needed is when you want to employ special roles.
According to the ​OSM wiki, the multipolygon relations "are used to represent complex areas" (that's what we have here). There is also some explanatory text: "(e.g., because its outline consists of several ways joined together, or because the area consists of multiple disjunct parts, or has holes)"
The relation in question is an example for "multiple disjunct parts".

[stoecker]

You have 3 areas, the pyramids and then you want to make another area out of this, which is historical site.

This in itself is doubful, because you try to create 2 identical areas which have different area types (one building, one archaeological site). That may or may not be possible, but anyway it is not supported in JOSM and other tools - until recently it was not even possible at all with old style multipolygons and I don't see convincing reasons to change that behaviour yet as valid cases are very seldom.

So however you look at it is either wrong or doubtful.

Beside this a historical site would not only consist of the three pyramids, but also of the area around them. A pyramid is no site in itself.

Like in most of the troublesome cases you're using the multipolygon as a grouping instance and that it is not - type=site was invented for that purpose when really necessary otherwise simply grouping should not be done.

[dieterdreist]

I am not creating 2 identical areas, because there are 3 small areas and together those are one area (different area). Clearly a building can be an archaeological site, and this site can have a different name than the building, this is neither doubtful nor suspect.

I appreciate that you have changed your opinion from "simply wrong" to "maybe doubtful", and you even admit that there are "valid cases", although you believe they are "very seldom" (from this alone I believe the error should become a "warning" at most).

I don't know whether the area around the pyramids have to be part of this particular archaeological site. (It is "archaeological site", not "historical site", which would have a less clear meaning).

You still make very bold assertions ("A pyramid is no site in itself."), which are completely questionable, maybe this is a language problem? I don't think anybody with the most basic knowledge about archaeology would question that an ancient pyramid in all cases IS a site.

I don't know what you mean by "grouping instance", there is clearly the mention of "disjunct geometries" as usecase for multipolygons, and this is clearly applicable here. Yes, type=site might be used as well, but this doesn't mean a multipolygon is wrong.

Can you explain how JOSM can know whether a tag describing an area on an outer way has to go onto a relation or onto a way? I believe this is something that requires knowledge of the real world situation. Please remove this test, it is misleading.

PS: Just in case you will close this again, I promise I will not reopen it.

[stoecker]

I don't care if you ignore the statement that this is not supported or not, but the result is the same. You use an unsupported mapping and the warning is correct.

[dieterdreist]

For reference, I've written to the talk mailing list in order to collect some other opinions.
You can find the thread ​here

[bastiK]

In 12905/josm:

see #15360 - demote "Area style on outer way" valdiator test from Error to Warning level

[bastiK]

It is right, that this kind of tagging wasn't possible until very recently. All the more reason to deactivate the test, because by keeping it we actively take a stance against this newly available tagging practice. If it will be considered acceptable or bad practice by the community is far from clear to me and it is not our job to decide (yet).

[stoecker]

Replying to bastiK:

It is right, that this kind of tagging wasn't possible until very recently. All the more reason to deactivate the test, because by keeping it we actively take a stance against this newly available tagging practice. If it will be considered acceptable or bad practice by the community is far from clear to me and it is not our job to decide (yet).

You totally miss the fact that the definition must match the support.

• All software supporting old multipolygon tagging (most) will fail with this style of tagging.
• JOSM does not support this style of tagging, outer tags on a multipolygon will simply be ignored.

So you can't simply say the community may decide if this is good or bad practice, as the community simply has no idea about the involved algorithms. This is a decision to be made by the software developers of the important OSM software (mapnik, iD, JOSM, ...).

If you want to support this, change our drawing code to handle it properly. Changing only the warn level is crap.

Jochen is of the opinion to support it in osm2pgsql, because it is a result of the logical structure without the old multipolygons tagging. I think that may be considered in some years, but currently it simply will lead to more broken polygons, as if you allow this type of tagging:

• you wont be able find the errors created by people still thinking old style multipolygon is valid
• all these multipolygon as a collection type polygons will be syntactical valid, but still logical broken
• You will have a lot of things like multipolygon is wood and outer ways are wood and the result is not what people expect
• many software tools will handle them wrong.

I did not only suggest to participate in Jochen's challenge, but I also participated a lot: All of these issues existed, still exist and will come up new. Explicitely supporting this is simply not a good idea. For osm2pgsql it is the logical step due the way it works and the way it handles data. But JOSM is an editor and we should discourage things which make using the data more complicated than necessary.

[dieterdreist]

I believe the only sane way is to be logical. Old style multipolygons have never been logical, and it has been known since ever. You don't confuse people by being logical (tags for the way on the way, tags for the relation on the relation), you confuse them by saying: some tags on the way don't apply to the way, they apply to the relation. This is only asking for trouble, and is miseducating people to stop thinking and start learning exceptions. I am very happy we don't have any old style multipolygons any more, and I hope we're not going to get something similarly insane in the future.

Relations are generally a feature for advanced mappers, who generally will have heard by now that mp relations should only be added in the "new" style.

As a result of the current warning I could make 4 Multipolygons instead of 1, to get rid of the error: one for each single pyramid, with the respective tags, and one for the 3 pyramids together. No warning any more.

[stoecker]

Replying to dieterdreist:

some tags on the way don't apply to the way, they apply to the relation.

Where do you get that impression from? The warning says that the outer ways describe an area type in itself, which is not supported.

This is necessary to avoid conflicts with the multipolygon definition which existed for a decade.

And this definition was not "never been logical". Even if you don't understand the logic at the time of the definition it was the correct way to do it.

[dieterdreist]

Multipolygons have been introduced in 2007 by converting areas with a hole, at the time the instruction was to put the tags on the outer way. ​2 years later, in 2009, the instruction was changed to put the tags on the relation. This was 8 years ago. A lot of time has passed since then.

[stoecker]

Well, and? This style of polygons was there for a decade and only very recently a big effort was done to get rid of hundreds of thousands old style multipolygons. Even now people are creating these. Whether the wiki said that the old style is deprecated since 2009 does not count, as the date where it really was done is June/July 2017 and that's only a few months ago. Come back in two years. Maybe situation and the tools changed by then and can be reconsidered.

[bastiK]

Replying to stoecker:

Replying to bastiK:

It is right, that this kind of tagging wasn't possible until very recently. All the more reason to deactivate the test, because by keeping it we actively take a stance against this newly available tagging practice. If it will be considered acceptable or bad practice by the community is far from clear to me and it is not our job to decide (yet).

You totally miss the fact that the definition must match the support.

• All software supporting old multipolygon tagging (most) will fail with this style of tagging.
• JOSM does not support this style of tagging, outer tags on a multipolygon will simply be ignored.

Suppressing the rendering of area styles on outer ways of a multipolygon is a feature that has to be actively implemented. (In our case it is a remnant of old-style multipolygon drawing.) So "adding support" would mean removing sort-of outdated code.

So you can't simply say the community may decide if this is good or bad practice, as the community simply has no idea about the involved algorithms.

By "community" I don't necessarily mean the wisdom of the masses, but an agreement among technically minded people.

If you want to support this, change our drawing code to handle it properly. Changing only the warn level is crap.

Agreed, this would be #14826.

Jochen is of the opinion to support it in osm2pgsql, because it is a result of the logical structure without the old multipolygons tagging. I think that may be considered in some years, but currently it simply will lead to more broken polygons, as if you allow this type of tagging:

• you wont be able find the errors created by people still thinking old style multipolygon is valid

The old-style multipolygons with a hole will still be filled, so the problem is obvious. In addition, we have MultipolygonTest, which finds old-style multipolygons.

• You will have a lot of things like multipolygon is wood and outer ways are wood and the result is not what people expect

Without the "area style on outer member" validator warning, the only indication will be double rendering of the area, i.e. brighter color. Possibly we can add new validator code to detect the common problems with double tagging (same landuse=*, amenity=*, building=*, ... tag on relation and outer way).

I did not only suggest to participate in Jochen's challenge, but I also participated a lot: All of these issues existed, still exist and will come up new. Explicitely supporting this is simply not a good idea. For osm2pgsql it is the logical step due the way it works and the way it handles data. But JOSM is an editor and we should discourage things which make using the data more complicated than necessary.

I guess it boils down to whether you like this new way of tagging and want to see it used, or not. :)

[stoecker]

Replying to bastiK:

Suppressing the rendering of area styles on outer ways of a multipolygon is a feature that has to be actively implemented. (In our case it is a remnant of old-style multipolygon drawing.) So "adding support" would mean removing sort-of outdated code.

It is no SO EASY, otherwise I'd have done it when removing the other code. But I agree it will not really be a hard task.

The old-style multipolygons with a hole will still be filled, so the problem is obvious. In addition, we have MultipolygonTest, which finds old-style multipolygons.

It is not so obvious. That's the problem. No issue with a building, but for larger landuses with small holes this was an issue during the cleanup and still is an issue. That's so easy to overlook, especially when downloading incomplete multipolygons.

• You will have a lot of things like multipolygon is wood and outer ways are wood and the result is not what people expect

Without the "area style on outer member" validator warning, the only indication will be double rendering of the area, i.e. brighter color.

Same as above - overlooking of the covered holes.

Possibly we can add new validator code to detect the common problems with double tagging (same landuse=*, amenity=*, building=*, ... tag on relation and outer way).

That may help.

I guess it boils down to whether you like this new way of tagging and want to see it used, or not. :)

I'm open to reconsider my opinion in the future (e.g. next year), but in the current situation it is much to early to allow or encourage this style in the editors.

[stoecker]

Ticket #12385 has been marked as a duplicate of this ticket.