I’ve never suggested that it’s not possible to create interactive maps with your non-standard multipolygon (of course it is), rather my point is that people would have a craft a query specially for it. For OSM data to be useful, people should be able to query things in a generic way, and my overpass query to show all the schools in a bounding box is doing that.

Your overpass query isn’t treating the relation as a multipolygon, but just any relation. It’s just listing the relation members and would work no matter the type. Any query that actually treats your relation as a multipolygon, and tries to render the polygons defined, would not work properly.

Alex, here are a few comments on your replies above-

You are correct that ‘site’ relations are not well supported, but they are the only documented way that I know to achieve what you are doing: grouping the buildings and other features within a site together.

The reason that there aren’t better methods is probably because there is a common view in OSM that features don’t need grouping together in this way. The argument is that simply placing the features inside a polygon shows their relationship to the feature that polygon represents. I appreciate that you might disagree with this, but I am simply stating my perception of community option.

While your non-standard use of the multipolygon relation does render on the standard map without obvious problems, it does have the potential to cause problems with other uses of the data. Let’s say someone loads the data into a spatial database, such as PostgreSQL with PostGIS, and then writes a query to select buildings located inside school polygons. For the multipolygon you have created, most of the buildings won’t be returned, because they are actually being placed outside the school’s polygon (or specifically inside inner rings that are not part of the polygon).

Alternatively let’s say someone creates an interactive map where people can click on features to show more information. In this case, clicking on the buildings (or other features tagged with the ‘inner’ role) won’t work if the multipolygon is correctly rendered. Here’s an Overpass query that shows this: https://overpass-turbo.eu/s/ThB. The tags are not displayed if you click, for example, on the Arboretum or most of the buildings.

All the elements are indeed shown if you view the relation at: https://www.openstreetmap.org/relation/11028673. But that view isn’t attempting to render the multipolygon, but is just showing all the elements that the relation contains. I think the relation type could be set to anything here and it will still appear the same.

You refer to the multipolygon’s outer way as being the land parcel (or cadastre), but I would consider that to be the area defined by the multipolygon itself.

On Uplift the system told me that The Boer War Memorial was wrongly designated & should >be outer. I did that & it was fine. It was thus:

Cadastre: outer Grass oval: inner Boer War Memorial: outer

That really did my head in!

I think more advanced uses of multipolygons are confusing to most people at first (they were to me). This example does make sense when you consider ‘inner’ rings are holes punched in the ‘outer’ rings and therefore having an ‘inner’ ring directly inside another ‘inner’ ring doesn’t make sense because that area is already excluded. You are however allowed to make another hole inside an inner ring (using the ‘outer’ role), which is then an inner island, which is again part of the polygon. It’s hard to explain this clearly and the example ‘Island within a hole’ on the multipolygon wiki page might make it clearer: https://wiki.openstreetmap.org/wiki/Relation:multipolygon

The multipolygon relation you have created (https://www.openstreetmap.org/relation/11028673) for the school site looks rather strange with over 50 members with the role ‘inner’. Multipolygons are intended to represent areas when a closed way isn’t sufficient. They aren’t intended for grouping things inside an area together. The inner role is used when you want to punch a hole in an outer ring, so here you have created a polygon with over 50 holes in it, and in so doing are implying the school buildings aren’t part of the school site. I suspect this wasn’t what you intended.

Multipolygons also should not contain nodes.

The school site can be mapped with a single closed way, so a multipolygon is not needed. Did you perhaps intend to use the ‘site’ relation instead? https://wiki.openstreetmap.org/wiki/Relation:site

I know this comment probably won’t be welcome, but I am genuinely trying to be helpful.

Hi,

I don’t think there is any reason why addr:place can’t be used in America. My post was about the different ways the tag is being used in the UK and some associated problems. It is a worldwide tag, but I was limiting my discussion to the UK because that’s the area I’m familiar with.

I don’t know whether the American community has discussed the best way to map shopping centre addresses, if no alternative method has been agreed, I would go ahead and use addr:place.

Regards, Will

I disagree with combining craft=photographer and shop=photo_studio. Both can be used together where appropriate, but they are not always the same. craft=photographer implies the studio of a photographer, but it does not say which types of photography are offered. Some photographers specialise in particular things: weddings, glamour photography, photographing merchandise to appear in catalogues, etc. This tag does not suggest anybody can walk in off the street and have their photograph taken, while shop=photo_studio implies exactly that.

Please be careful about encouraging mass edits. Many mappers (myself included) have spent a lot of time mapping these things and really do care about these subtle distinctions. I have no objection to merging things that really are the same, but this must be done with care, and this almost always means by local mappers. It is very easy to remove worthwhile distinctions between tags without realising you are doing so and that can be demotivating to the people who added them

I agree people sometimes use shop=photo_studio where shop=photo would be correct. I don’t disagree with changing them, but it must be verified on the ground or with local knowledge.

Where I live in Nottingham (England) we have a website showing services and amenities mapped locally. There is a separate layer for photo studio shops: http://osm-nottingham.org.uk/?z=12&lon=-1.19768&lat=52.95009&bgl=OSM,1,17&l=services&lh=Auctionhouses;Launderettes;Drycleaners;Printingcopyshops;Taxioffices;Drivingschools This will be no way to create such a layer if these tags are carelessly merged together.

Tom: Looking at the Westbury addresses, they all appear to have been added in 2009, so I suspect the mapper didn’t have access to good enough aerial imagery to add buildings. And StreetView wasn’t available then either.

Regarding postcode ‘stubs’, I have never bothered with them, but I suppose they might be of some use, particularly on the borders of postcode districts, where trying to determine the postcode from centroids or other inexact sources is going to be unreliable.

A quick query on the address data I’ve extracted indicates there are 20,934 addresses with just a postcode stub, and of these, 11,980 are in Birmingham and 3,951 in Coventry. So it’s obviously favoured by West Midlands mappers.

chillly: My lists certainly aren’t a good indicator of completeness. I did unsuccessfully search for data about the total number of addresses in each postcode district, so I could show the level of completeness, but possibly this isn’t available without access to the PAF database.

I suppose I could just use the total number of postcodes in each area as a rough indicator of the number of addresses. But it would require filtering out the inactive postcodes usually located at sorting offices first, and then, I’m not sure it would be accurate enough to be worthwhile.

I make regular use of your postcode overlay. It’s much appreciated.

RobJN: I’m aware of the Postcode Finder tool. It is very useful, although it’s a shame it doesn’t support the ‘street’ relations that I have used a lot. I mostly use it to easily look at the Land Registry data.

Regarding the “Wrong Postcode” lists, it is necessary to be careful that it is matching the correct street, because most of the mismatches it’s highlighted in my area have turned out to be a different street with the same name, sometimes several miles away. I appreciate that matching the correct street is quite difficult to do. Perhaps it could use the postcode centroids to pin down the location.

Pgd81, a late reply to your comments:

I have sometimes used the approach you suggested for retail units. While not widely used it is one method that can be used. I have also sometimes used the addr:place tag for large retail parks, where the address doesn’t really have a street just an area.

As for using addr:housename and addr:unit for residential sub-streets, I don’t think there is anything particularly wrong with doing it that way, but I suppose I think there should be a more generic solution. This is partly because it won’t work well in all circumstances: for example if the sub-street itself contains both house names and numbers. Consider this example (the names are made-up, but it’s based on a real example): Dairy Barn, 2 Glebe Farm Court, Church Lane This is a courtyard called Glebe Farm Court, located off Church Lane, which containing a series of dwellings with housenames and numbers. It’s not impossible to represent this using existing tags, but it would involve using 2 or 3 tags for things they aren’t really intended for, so would be rather ugly/hackish.

In reply to Tom’s comments:

Regarding using addr:interpolation on individual buildings, I think it is correct. It’s really the only way to avoid ambiguity. I must have done this hundreds of times and would be most unhappy if somebody removed them. Here’s an example: http://www.openstreetmap.org/browse/way/224033525. This usage of addr:interpolation has been documented on the wiki now (not that I think the wiki should be used as the sole source in deciding whether tagging is correct).

For addr:flats, I think it’s acceptable to use a semi-colon to separate multiple numbers, so if I were tagging the example you gave, I would use addr:flats=23;23a;23b. (Some people prefer commas instead of semi-colons.)

Regarding the school I referred to, this is the link: http://www.openstreetmap.org/browse/relation/409896. It is split in two by a trunk road but joined by a foot bridge. To tag this, I decided to draw two separate polygons for the separate parts and then combined them together using a multipolygon relation with two ‘outer’ roles. I then included the amenity=school tag and the address details inside the multipolygon relation.

I like to group all the addresses on a street together using a street relation (in this case: http://www.openstreetmap.org/browse/relation/1917127). I was making a technical point that strictly (according to the wiki) ‘address’ roles in street relations are not allowed to themselves be relations (only nodes or ways). Personally I don’t see any reason for this limitation and ignore it.