Hello Mike. Apologies, can you explain what you did here? Did you just remove the turn restrictions of the bus gate (which still exists as far as I am aware), or are they mapped in another way?

Thanks, Andrew. So, do you think they should remain on the map? It can be a slippery slope, if every office within a larger institution is mapped separately.

BUNET, I suppose, is a consortium of those 5 colleges (acronym of their initials), who probably share IT resources and staff.
office=it might be an appropriate descriptor, but they seem too private for me, and part a larger entity more than their own IT company.
At the moment, besides the overall college institution being mapped, we have libraries and chapels, which are mostly private but might be open to visitors in some cases, and they occupy very distinctive buildings. All other private amenities (college bars, dining facilities) and internal offices are not mapped as such.

If jhdore mapped these for a reason, we can hear it, otherwise I would agree with reverting.

Hi.

Is it actually necessary to map these? They seem to me quite internal to the organigram of the institutions, and we don't map various other college offices (academic, bursaries, development, etc.), which are of little interest to general users.

Moreover, they certainly are not "bars" (even if drinking were to happen in them!).

The street signs mark Queen St as a designated pedestrian area, the pavement is levelled and people certainly use it as a pedestrian street. (Compared, for example, to George St, which has traffic restrictions but certainly feels more like a normal road).
Wouldn't highway=pedestrian be a better descriptor? All access tags are correct anyway.

Hi. May I ask what were you trying to achieve?

Is the creation of a new amenity=bus_station for this collection of bus stops necessary? Does it actually function as a station/prominent terminus?
Before, that tag was used only for the Gloucester Green station with inter-city coaches.
I am open to hear an argument, but I am not convinced at the moment. The geometry also looks arbitrary.

P.S. This changeset moved a few nodes by mistake breaking the platform 3 and track line elements. They are fixed now.

Mapping what is actually on the ground, over what is defined legally on paper, is a founding principle of OSM, and it applies to roads too. The wiki page for UK roads is helpful guidance, but every case should be always judged individually.
If this is the only exception, it might mean that that's what is is, or that other roads might also need to be reviewed, or that the legal classification is out-of-date. Alone, it cannot mandate how it should be tagged.

In Oxford, for users, this does not look and does not behave like a primary road, in my opinion.
Legal classification and national consistency are not powerful enough arguments to change it.
The only argument I can see for highway=primary is that it is actually a primary road for bus routes. That's true (although not applicable to most users).

Anyway, the note asks to start a discussion on talk:GB before changing it. I assume that some discussion happened there some time ago, to reach a consensus decision on this.
If you would like to review, it is probably best to move the discussion there, compared to this changeset where only we are notified. (If you do, please let us know.)

Thanks. All the best!

Hi both,

The wiki for key:highway specifies:
> Note that highway=* distinguishes roads by function and importance rather by their physical characteristic and legal classification. Usually these things are highly correlated, but OSM is not obligated to copy official road classifications.

And key:highway=primary:
> Use highway=primary to tag a major highway linking large towns
> Primary highways are usually open to all motorised trafic

This section of road is not a primary link on the ground, it is not signed as such and cannot be used as such by traffic. The current state of the map is before my time, but I think it is accurate.
The legal classification is irrelevant. In my opinion, mapping Oxford St Aldate's and High Street as primaries would make a worse map for users.

Hi. I believe this could be the proper identifying house name of this property. Was your change based on a source or just a supposition?

Hi. I think it is fine as it is. As long as the object is correctly mapped, rendering doesn't matter (it will always struggles when multiple labels from areas and nodes overlap).
The overall area named Gardens is still needed. Nevertheless, I have done a couple of adjustments.
Thanks. All the best.

Sorry for the slow reply.

Personally, I'd say it is definitely more a "addr:housenumber", than "addr:unit". It _is_ a subdivision of the building, but principally it is a number in the ordered street sequence.

I'd also use "addr:housename" over "addr:substreet".

How it is rendered on an envelope is irrelevant, in my opinion. We are recording raw data which can be used in a number of ways. Unless we think that the envelope is the true expression of the nature of the address data and that's what we record ­— and I don't think that's the case.
In general, I am not a fan of that wiki page about UK addresses, so take this as you will.

All the best.

Why substreet and not housename?

Addr:housename, "The house (or building) name that is included in the address."

These are clearly names of the building, and they are included in the address.
I think the standard housename is preferable to the very niche and unusual substreet.

Personally, I think we should aim to choose simple solutions (which work across countries and local contexts) over more complicated and particular ones.

Thanks for surveying the entrances!

I think it appears as:

77 Hawk House
Baynhams Drive
[Wolvercote]
OXFORD

(But the number is not a flat number, it follows the street numbers.)

Addr:interpolation on a single object is very much acceptable, and documented on the wiki, although there is no consensus.

osm.wiki/Addresses#Buildings_with_multiple_house_numbers
> Specify the range (e.g. 10-95). Note that there is a risk of ambiguity between two meanings:
When such a range is officially used for the entire house, this is the preferred method. In this case 10-95 is simply a label like any other. In this and other cases, house numbers officially contain a dash and are not meant to be treated as special.
When such a range is meant to be interpreted as a list of addresses, use addr:interpolation=* (described below) to emphasise this. Some mappers will add a short "virtual" way which allows them to put addresses 10 and 95 on separate nodes as normal. Some mappers will specify the range 10-95 on a single object, where the addition of the addr:interpolation=* tag disambiguates it from the "simply a label" meaning, specifying that it is indeed to be treated as a range. Both approaches are used in practice and there is little consensus.
Note that in some cases building or building complex has single address such as 3-5 that only looks like a housenumber range. As usual, do not convert such data blindly, without a verification.

Personally, I think it works very well and I have been using it extensively in Oxford.
It distinguishes it from other cases and it is well received for example by the main search engine on openstreetmap.org. Without the interpolation on the single object, I think it does not return addresses in the range. With it, it does. The rendering is great, and the human interpretation is also very clear: it specifies what the X-Y range means.

Mapping individual entrances certainly provides more detail, but the result is the same: a range with dash and interpolation tag on a single object.

All best.

The previous solution was correct. The name is used in official addresses.

Moreover, the current interpolation suggests that numbers are in between, on the line, like a terrace, which is not accurate for flats.

I would suggest restoring the previous tags to the overall buildings.

Sorry, disregard everything I said. There was indeed a duplicate, in addition to the overlap of the overall area and the sub-areas!

I reverted it.

Now I'll try to see if it can be mapped with more precision.

Hi. This wasn't a duplicate. The node refers to a specific sub-element of the overall area (with boundaries that are not well defined, I presume).

Hi,

Welcome to OSM and thanks for your edit!

Just a couple of notes:

- This changeset contains an edit to Pawłosiow in Poland, and edits in Oxford. If you meant to edit Pawłosiow, it is better to do it in a separate changeset, to keep it small and local.
(See: osm.wiki/Changeset#Geographical_size_of_changesets)

- The 'name' should be a proper name, not a description. A lot of the names you assigned to natural and school elements in Blackbird Leys seem only descriptive (unless they are really referred to as Wood 1, etc.?).
(See: osm.wiki/Names#Name_is_the_name_only)

- Careful in applying appropriate tags (a basketball hoop is not a building, etc.) and not to break multipolygons.

Cheers. Enjoy mapping.

Best,
gmar

Hi. Could you explain your rationale for these edits to college staircases?
Personally, I am not sure that the new solution is an improvement.
They are sui generis buildings. They don't have addresses, so I question the use of the 'addr' tag.
I think the previous use of 'name', while not perfect, is more appropriate, and certainly clearer for the user, especially because the staircases are mapped as distinct buildings. (If the whole building was a single area, with individual entrances mapped as nodes, I could see the unit approach working more, but that's a bigger change, and again, it would lose information more than add).

Hi. The house numbers here are already mapped from 1 to 43 with an interpolation line, which will automatically determine the mid addresses. Further details about the addresses should be added primarily to the end nodes.
See addr:=**#Tags_for_interpolation_ways
Number 45 is mapped already as a separate building.

The building is mapped as a single terrace (building=terrace), with addresses as separate nodes. No address on the terrace is needed.

If you wanted to replace the terrace with a more detailed number of individual terraced houses, they will need to be drawn individually, with an address on each one of them. (The programme JOSM has some automated plugins for that, if you want to look into it). It would be more detailed, but it doesn't necessarily add much more information, unless the house are of significantly different sizes or shapes.