Opened 8 years ago

Closed 5 years ago

#4099 closed defect (duplicate)

[landcover] Incorrect labelling of multipolygon relation

Reported by: David Earl Owned by: mapnik-team@…
Priority: minor Milestone:
Component: mapnik Version:
Keywords: Cc:

Description

Someone seems to be rather over-enthusiastically grouping together all the residential areas in Cambridge into multipolygon relations. I'm not convinced this is helpful. However, there is a rendering artefact which makes this particularly unpleasant. The name of one of (the many) outer elements is being picked up and rendered widely across the whole of the area which the relation covers (possibly it is in the middle of any anonymous outers which are also part of the relation, not sure).

The name chosen seems to be pretty random. It comes from this small way, "The Orangery".

http://www.openstreetmap.org/browse/way/43491617

You can then see this insignificant "The Orangery" caption rendered repeatedly all over Cambridge where it is completely irrelevant. For example:

http://www.openstreetmap.org/?lat=52.197111&lon=0.103013&zoom=18&layers=M

and

http://www.openstreetmap.org/?lat=52.190617&lon=0.129325&zoom=18&layers=M

It doesn't seem right to render the name of one element of a multipolygon relation arbitrarily on others.

I think the relation concerned is this one: http://www.openstreetmap.org/browse/relation/1823059 but it could be this one, I'm not certain: http://www.openstreetmap.org/browse/relation/1825599

I will contact the author directly about the undesirability of this relation in principle, but I think the way the name is being rendered is a bug in any case.

Change History (5)

comment:1 Changed 7 years ago by Ldp

These relations seem to have been deleted, so this particular manifestation of this issue is now gone.

This is actually an issue that has its roots in the import process, not in mapnik itself. Multiple disjunct outer ways in multipolygon relations each get converted into their own postgis polygon in the rendering database. When mapnik gets around to seeing the data to be rendered, it has no way of knowing that they were once part of a single entity (the relation).

So far so good, but where things turn sour is that if the relation itself doesn't have a name tag, it takes a name tag from any one of the member ways. Same for any other relevant tag. The solution is twofold: 1) Explicitly tag the relation with the relevant tags and 2) (the most important) *don't* use relations to group things together.

Relations are not categories. "All residential areas in a particular municipality" is the perfect example. When a proper admin boundary exists, it's easy to answer the question "give me all residential areas in this region". It doesn't need a relation to get that done.

comment:2 Changed 7 years ago by rasmusv

I think that the original reporters problems have been resolved in OSM, however I've observed something similar in Denmark. I have created the multipolygon 1933205 [1], which covers the municapality of Samsø (Samsø Kommune) - a big island with approximately 16 islets. The multipolygon is given a name tag which should preferably apply only to the complete multipolygon and not all of the 17 parts of the multipolygon [2] as it is now. The problem with the existing method of rendering is that you cannot see the names of the islets, but instead they are wrongly called "Samsø Kommune".

[1]: http://www.openstreetmap.org/browse/relation/1933205 [2]: http://www.openstreetmap.org/?lat=55.8944&lon=10.6519&zoom=14&layers=M

comment:3 Changed 5 years ago by math1985

Is this still a problem?

comment:4 Changed 5 years ago by math1985

Summary: Incorrect labelling of multipolygon relation[landcover] Incorrect labelling of multipolygon relation

comment:5 Changed 5 years ago by math1985

Resolution: duplicate
Status: newclosed

This issue is now being discussed on Github: https://github.com/gravitystorm/openstreetmap-carto/issues/779

Therefore, I will close the issue here.

Note: See TracTickets for help on using tickets.