Hi kucai

This is something that I’ve struggled with also, and particularly now that we have all been in Covid-19 lockdown, and I do not even have a metres-bad GPS track to rely on. The solution that I have been relying on in the UK follows this decision matrix:

1. The UK roads have all been imported from an accurate Ordnance Survey DB (or at least we hope that it is accurate - my own cross-reference investigations from BorderLine imports say ‘yes’, as in the common situations where a border follows a road, river or other feature it has normally matched perfectly)
2. The English are obsessed with roundabouts, both small & large
3. When the Borders (mentioned above) have passed through such roundabouts it has frequently been straight through the middle
4. The roundabouts provide an excellent target when looking through imagery, much like firing an arrow (I live in Nottingham)

The upshot (pun intended) of the above is that I correct the Imagery used to the nearest roundabout that I can find. It seems to work well so far.

These could be quickly adjusted using maps

That statement needs to be heavily modified: almost all modern maps can NOT be used to update the OSM map. That is due to the copyrights deployed within modern maps.

This is the relevant statement from the OSM Copyright Statement:

OSM contributors are reminded never to add data from any copyrighted sources (e.g. Google Maps or printed maps) without explicit permission from the copyright holders.

somewhat based on UK English rather than real English words

“real”???

Not going to even attempt to make further comment, other than to point out the self-parody involved in the language construction. And no, England does not own English, any more than any other locality that makes use of English owns it.

The en:Wikipedia page on Meadow is pretty damn good.

There is zero connection to streams/rivers, though they would need decent water supply & drainage to function well as a meadow (the first not usually a problem in Ireland nor England, of course). In connection with Victorian times they would often be odd fields close to a city that remained as common-land after enclosure, and thus functioned as places to stroll & take exercise on a Sunday.

They had a vital function as sources of Hay to feed the animals in Winter. In modern times they are often deliberate sources of greensward sown with meadow flowers as the premium sod for the back-garden.

Excellent stuff.

As far as I’m concerned, what you are doing is exactly what OSM is designed for. There are possibly thousands of years of history in those farmer’s names. And to think that it has come down through word-of-mouth only. This is getting like the bard’s folk-tales.

So this is correct, then?

name:cy=Ysgol Uwchradd Aberteifi
name:en=Cardigan Secondary School

Any idea as to the Operator? Would it be Welsh Assembly or local Council or something else?

@spiregrain:

I suspect BT will take longer

Just 9 schools in the East Riding of Yorkshire have an EduBase ID mapped, and (so far) almost none have contacts nor addresses fully mapped. So, I suspect that HU may take longer than BT. If I get to the end & you are still going, then I’ll start at the end & map towards you.

This is definitely a marathon rather than a sprint. It’s amazing that so much much has been mapped, and yet as soon as you dip your toe in it is obvious that so much remains to be done.

I’m pleased that I switched. I was enjoying exploring the NI countryside, even if only vicariously, but EY is the place I was born, brought up in & made a good living from as a young man. It’s 40+ years since I travelled it and, even if on occasions bitter sweet, a pleasure to revisit.

@spiregrain:
I see little point in 2 of us using the same site (mathmos.net) to do the same work - far too much chance of interfering with each other. So, I’ve wrapped up the table that I was working on in the BT postcode section, and will switch to HU instead (my home town was Hull, and I spent my youth working in the East Yorkshire region).

Hi spiregrain

The charts and tables here https://osm.mathmos.net/schools/progress/BT/

I’m making use of the same site, and came across one of the schools that you had mapped (St Oliver Plunkett Primary School at BT11).

For NI I’m finding these three to be useful additions to mathmos.net:

• http://apps.education-ni.gov.uk/appinstitutes/default.aspx
• https://www.eani.org.uk/search-schools
• www.schoolswebdirectory.co.uk

The first two are Northern Ireland-specific school search sites, whilst the last one occasionally has web-address URLs that the first one does not. However, I’m often left with a generic web-search for the URL (I find Google maps to be best for that).

I’m making a point of entering full Contact & Address details (using the JOSM presets) as that is precisely what will be searched for (and why, imo, OSM maps can be useful).

Thank you Jude & Alan for scratching my intellectual itch. I never thought of Northern Ireland as an equestrian centre, but I guess that that is just my normal ignorance. I’ll go back & fix the mapping to try & reflect that.

@Polyglot:
The wiki on Site Relations says ‘use multi for schools’ (see one of the other recent diaries - I forget which one - for proper quote & url). That seems conclusive to me.

Site seems to have all the disadvantages & none of the advantages of Multi. So, what about them?

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

• Map way/relation to area (map_to_area)

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.

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/

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.

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.

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.

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.

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.

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.

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.