Haileybury and Imperial Service College, Hertfordshire
English телендә alexkemp24 April 2020 баҫылып сыҡты. Һуңғы яңыртыуҙар 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.
◦ 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.
- The Relation was created with the Cadastre selected & set to outer within the Member list.
- All tags were moved from the Cadastre to the Relation
(no tags at all were left on the Cadastre in this situation) - I used the campus PDF as my tick-list to map all school buildings
- After completing all mapping for an individual group of buildings each was added to the Relation
- 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) - 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:–
- Shot such a long way off 180° overhead (unlike Bing)
- 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.
Фекер алышыу
will_pтарафынан24 April 2020 cәғәт 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.
alexkempтарафынан24 April 2020 cәғәт 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:
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:
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 thantype=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.alexkempтарафынан25 April 2020 cәғәт 02:21көндө ҡаралған
Hi again, Will
Returning to this & re-reading (5th time, I think) the wiki page is this:
In all honesty I read this as “PS Do not use a
site
relation”. The real killer is that maps will not render it.highflyer74тарафынан25 April 2020 cәғәт 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 :-)
alexkempтарафынан25 April 2020 cәғәт 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.
kucaiтарафынан25 April 2020 cәғәт 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?
alexkempтарафынан25 April 2020 cәғәт 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.
will_pтарафынан25 April 2020 cәғәт 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.
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
alexkempтарафынан25 April 2020 cәғәт 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.
alexkempтарафынан26 April 2020 cәғәт 01:23көндө ҡаралған
will_p:
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.
alexkempтарафынан26 April 2020 cәғәт 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.
alexkempтарафынан27 April 2020 cәғәт 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:
Paste it into the Overpass window at https://overpass-turbo.eu/
alexkempтарафынан27 April 2020 cәғәт 08:54көндө ҡаралған
will_p:
Here is the link to where I found the info in my previous post:
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.
will_pтарафынан27 April 2020 cәғәт 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.