OpenStreetMap logo OpenStreetMap

alexkemp's Diary

Haileybury and Imperial Service College, Hertfordshire

Posted by alexkemp on 24 April 2020 in English. Last updated on 28 April 2020.

My last Diary was a HowTo on using JOSM to create a Relation to map Heath Mount School. Heath Mount was founded in 1796 & occupies 40 acres of the Woodhall Estate close to Ware in Hertfordshire. Now, just to show that some people & places may be created more equal than others, here is the Haileybury and Imperial Service College, which is also close to Ware & occupies 500 acres. This one has been a little bit more of a challenge to map.

drone footage

◦ Haileybury College (OSM map)
◦ Haileybury College (OSM relation - 130 members)

The bulk of the mapping is complete for this College (85 different items so far) but lots of buildings still to follow.

First a quick bio, then mapping highlights:

The East India College (named after the East India Company, which had the obligation to maintain it) had existed on the site since 1806 but closed in 1858 following an Act of Parliament. By 1862 a Haileybury College became an independent public school on the same site, and has continued ever since, now for boys & girls.

The School cadastre already existed when I began the Relation, as did most of the buildings & many of the ground features. A number of the buildings were named, but not all. The website has an overview of the campus but the buildings are not named on that page.

I phoned the school up & spoke to a lady who sent me a PDF that named most (not all) of the buildings. Hooray! If I point out that it has 13 dormitory Houses on site, each ‘House’ of which often comprises multiple buildings, you may begin perhaps to get some measure of the scale of this place.

  1. The Relation was created with the Cadastre selected & set to outer within the Member list.
  2. All tags were moved from the Cadastre to the Relation
    (no tags at all were left on the Cadastre in this situation)
  3. I used the campus PDF as my tick-list to map all school buildings
  4. After completing all mapping for an individual group of buildings each was added to the Relation
  5. Most buildings are set as inner within the Relation Member
    (every Member is inside the Cadastre, which itself is set as outer; another Member that is mapped inside another Member would require setting as outer; JOSM performs integrity checking on uplift & suggests a sensible fix on this one, so uplift often & fix all errors)
  6. I’ve tried to give a sensible naming scheme + ordered the Members accordingly

Some Help Wanted, if you Can

I’m in the middle of the final batch of building entry, which is the magnificent Dining Hall/Quad/Chapel/Terrace collection shown in the picture at top of this Diary. There are many school Houses, Academic places & school sections located within this complex & I’m struggling with how to map it, and could do with some advice.

I had to redo the Dining area to get the holes mapped (a Multipolygon - the classic OSM method to map a building with internal quads open to the sky, in which the exterior wall is tagged ‘outer’ & internal quads are tagged ‘inner’). That was relatively easy, since the Catering section & the 1932 Dining Hall designed by Sir Herbert Baker do not interfere with the Multipolygon at this moment. However, other sections are within the walls & (although I tried) I failed at mapping them as building sections.

The obvious method (I think) is to map them using the Site relation and map them as a set of rooms. My main concern is that I may switch the entire site collection from it’s current Multipolygon to Site (although I suspect that that may prove to have show-stoppers of it’s own), and do not want to introduce future show-stoppers at this stage.

I’ve had a quick try with indoor=room for the Common Room & Sixth Form Centre. Both show with the Relation, of course, but neither shows on the map by itself, which suggests that indoor tagging has very low priority.

(An example of a Multipolygon relation showstopper is that it can contain only ways; It cannot contain complex Multipolygons (buildings with holes) nor lines (each thows errors); it is also not supposed to contain nodes, although the enforcement is lax on that).

25 April Update:
I’ve completed & uploaded some significant surgery on the Quad building (start_date=1809). Fortunately I was able to complete it without having to first delete the original mapping (a close call in this situation). I think that the root cause is that recent Imagery such as Esri is:–

  1. Shot such a long way off 180° overhead (unlike Bing)
  2. Tile offsets vary wildly across short distances.

Although Bing is old that did not matter in this situation for this building, so I used that to map it.

The indoor=room mapping is not rendered on the standard OSM map nor in JOSM, and that is unfortunate as I need the names to display. For the Memorial Quad + Quad I used building:part=quad and the name does render in JOSM, but not yet in OSM (it may just be too early) (update: no, it just does not render). Regardless, whilst building:part is accurate for the Quads it would not be accurate for the various rooms. It looks like I may have to just live with their absence from general visibility unless someone has a brainwave.

26 April Update:
More building surgery, this time on the Terrace. Various abutments are now in place and it is correctly connected with the rest of the building. Once again, I was able to retain the original mapping.

The part marked as ‘Terrace’ is actually outside the building & faces across the Arboretum & field. That part is tagged building:part=terrace. The College is currently 105 members (including the Terrace) & still going.

There is a Portico facing the Quad (right-hand side of the picture above) and, after aligning the Terrace so that it fitted (and then fitting it) together correctly with the rest of the other 3 sides of the Quad I realised with some surprise that much of the Portico was missing. Well, not now. The Chapel now correctly fits on top of that Portico (it was actually too big before).

What I would love to do after Lockdown is over is to be able to visit & photograph the various buildings for Mapillary. This looks like a wonderful site for that.

Location: Bride's Farm, Hertford Heath, Little Amwell, East Hertfordshire, Hertfordshire, England, SG13 7PY, United Kingdom
Email icon Bluesky Icon Facebook Icon LinkedIn Icon Mastodon Icon Telegram Icon X Icon

Discussion

Comment from will_p on 24 April 2020 at 17:11

The multipolygon relation you have created (osm.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? osm.wiki/Relation:site

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

Comment from alexkemp on 24 April 2020 at 22:33

Hello Will.

I’m always happy to receive help that is genuine. As it happens, I have already met & mentioned this particular feature before and have therefore consciously chosen the Multipolygon option over the Site option. Whether my choice was correct or not is another thing altogether, of course.

If you have a look at Option 3 (“3. Multi-site Schools should be placed within a MultiPolygon Relation”) of my School Intelligence Diary post you will see:

The obvious type of Relation would seem to be type=site, but even that wiki page says to use Multipolygon for schools

Now yes, that Diary post + the Wiki entry is talking about multi-site schools rather than a single site (as here and Heath school) with lots of items in the site. After the prompt of your comment I re-looked at this and now am not so sure. Nevertheless, it does seem to be working fine, and the Relation as currently defined is providing a good dictionary for all services available at the site in a way that should aid any human searching the site.

I did earlier with other schools try type=site & met so many problems that I re-read the Wiki entry and came across the sentence above. I therefore shrugged my shoulders and got used to using a poly for all schools. I understand your concern with the inner / outer designation, but consider this:

With this Imperial school I had a situation where I was trying to highlight that the Main Entrance was the Main Entrance (I did not initially spot that there were gates at each side of the oval). I labelled the grass as Main Entrance and thought that that would do it. 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! Still, it looked fine and grouped everything together without complaint, so I shrugged my shoulders again. Later I spotted the twin gates for each road either side of the oval. When added they were named as “Entrances”, so I removed the name on the Oval & the grass from the Relation. On uplift the system again complained and said that the Boer War Memorial should be inner. Another shoulder shrug & everything now is the way that you see it.

And yes, it is blooming annoying that nodes (the gates) each give a complaint, but they are accepted & show in a meaningful way on the map (why can gates not be mapped with a line?). I’m much more pragmatic than yourself, I think. Probably an age thing.

In the end I agree with you; it should be type=site rather than type=multipolygon. However, there are several days committed to this now, and I cannot stand the pain & time that would undoubtedly occur if I attempt to convert it. Plus, it works in what a Relation is supposed to be doing, and I do not know any practical advantages that such a conversion would achieve, nor any practical disadvantages that a multipolygon is causing.

Comment from alexkemp on 25 April 2020 at 02:21

Hi again, Will

Returning to this & re-reading (5th time, I think) the wiki page is this:

Sometimes other relations, especially multipolygon relations, have been added as members of a site relation. This can be difficult for database users to interpret, so it should be avoided where possible.

Site relations are typically not interpreted or used by database users such as map rendering or routing applications or any other software.

In many cases standard solutions, for example multipolygon relations, are a perfectly acceptable replacement.

In all honesty I read this as “PS Do not use a site relation”. The real killer is that maps will not render it.

Comment from highflyer74 on 25 April 2020 at 08:12

Good morning!

A little off topic: what came to my mind when looking at the map was the naming of different parts of the college. As we tend use name=* for the name only in OSM, I would not use name=(unnamed) but rather not tag it at all. As for the parkings I would also just use e.g. name=Terrace 4, as amenity=parking already says what it is.

Other than that: beautiful work :-)

Comment from alexkemp on 25 April 2020 at 10:24

Hi highflyer74

The use of a “Parking” prefix (etc.) is deliberate. It is used so that humans can look down the list in the Relation & survey all the different Parking places (etc.) in one block (there are almost 100 members now).

The reason for the use of “(unnamed)” is to provoke someone to complete the mapping (possibly me if I can wangle an invite to photo the buildings). I’ll see how it sits with me after everything else has been entered.

Comment from kucai on 25 April 2020 at 10:55

When you take pics for mapillary on site like this, do you still make them as a (walking/driving) sequence? Or do you just do the Panoramio thing - take pictures of buildings/pois?

Comment from alexkemp on 25 April 2020 at 14:29

Howdy kucai

My answer is “yes”, but I suspect you may wish for more details.

In ordinary circumstances there are many people locked-down within restricted circumstances. A sequence of photographs along a route allows such people to more fully experience the nature of the place. I’ve had a small number of places where I’ve made such a sequence.

The more-usual driving sequences are intended for automatic derivation of traffic signs, etc.. I’m not involved in that.

Most of the 7k-odd photos that I’ve taken are PoI photos, intended to attach to PoI so that OSM map users can get a visual appreciation of a specific location. I’m looking for depth as well as breadth. They are also intended to lodge info for later use during mapping at the computer.

My main reason is so that I do not get lost whilst re-creating my survey on the computer. That is why I photo so many street-signs.

Comment from will_p on 25 April 2020 at 15:10

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: osm.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: osm.wiki/Relation:multipolygon

Comment from alexkemp on 25 April 2020 at 22:22

highflyer74:
> I would not use name=(unnamed) but rather not tag it at all.

Looked again at this after a sleep. Not the slightest doubt that you are right (very jarring). I’ve removed all such name-tags. Will upload together with other changes.

Comment from alexkemp on 26 April 2020 at 01:23

will_p:

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.

That’s a useful tool.

I’m unsure whether your comment on lack-of-tags is due to the reason you give, as the Terrace Parking areas are tagged as ‘outer’ but still do not show any tags.

Here is Fernwood school: osm.org/relation/11026813 (a very simple relation holding 2 sites for the same school). Does a similar overpass query for that show the same symptoms? Only showing tags for the relation itself? Or is that because of the query used rather than the mapping method used?

Can you show me a situation where a Site relation allows components to be clicked on & show their tags? That would be a compelling demonstration.

Please realise Will that I am NOT trying to avoid what you are saying - quite the reverse. It is simply not enough to demonstrate that the method used does NOT work. It also needs for a different method to be shown that DOES work, else I will spend my time doing a headless chicken demonstration.

Comment from alexkemp on 26 April 2020 at 04:30

will_p:
The school is now complete as best as I can manage (only Avenue - the entrance avenue - wants to be included, but a line within a multipolygon throws an error so I left it out).

Checking the Overpass-query again, none of the component tags show, either outer nor inner. That can be confirmed by clicking on the Tennis Courts (marked as outer since they are outside the formal Cadastre for Haileybury); only the Relation tags show if one of the Members is clicked. I do not know whether that is normal behaviour for every Relation or not.

Comment from alexkemp on 27 April 2020 at 08:38

will_p:
It turned out that your Overpass Query was the problem. Here is a query that shows any of the way tags and, indeed, any of the node tags, directly when clicked on in the map; so much for non-standard:

rel(11028673);    
(._;>;);    
out;              // output relation
map_to_area;      // map OSM relation to Overpass API area by adding 3600000000 to its id    
(._;>;);    
out;              // output area 3611028673

Paste it into the Overpass window at https://overpass-turbo.eu/

Comment from alexkemp on 27 April 2020 at 08:54

will_p:
Here is the link to where I found the info in my previous post:

The main use case of this statement is to search for objects inside an area, which is again inside another area (“area in area query”)

An Overpass API internal area creation job does not ordinarily create links to areas-in-areas. Therefore, your previous link would not have worked for a site relation any more than it worked for my multipolygon relation. Therefore, folks can create interactive maps to their heart’s content with my so-called non-standard use of a multipolygon. They simply need to learn how to use the Overpass API correctly.

Comment from will_p on 27 April 2020 at 09:43

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.

Log in to leave a comment