Much smaller changeset areas, please: osm.wiki/Changeset#Geographical_size_of_changesets

Since I, evidently, haven't had opportunity to finish drafting my full response (it became quite lengthy; I may actually publish it as a diary entry and simply link to it), hopefully this will suffice until I do.

Firstly, this sounds like osm.wiki/Tagging_for_the_renderer which is to be avoided.

“[the tagging] was messing up some of the address labels in certain programmes”
Then that renderer (or address parser / generator) should be fixed, instead of compromising data, especially since there are a multitude of ways to render the same data. Data should accurately reflect reality, regardless of how renderers currently handle the tagging (or elements; many don't fully handle relations, especially for routing). Renderers should then adapt to handle said accurate tagging.

To do otherwise is to inhibit improvement of data-parsers (renderers, etc.).

“messing up some of the address labels”
However, incase it really is a data (non-rendering) issue; how so? If you submitted a bug-report, then a link to that might suffice.

“the borough tag was making these places rank higher”
Places should be tagged based on what they actually are, not how any particular renderer may present them (see above). The map is the database of tagged nodes, not the tileset generated by one particular renderer. Many people use the data in a variety of ways, so it's unwise to presume which renderer (if any) they might be using.

Ranking (if that concept is relevant; it isn't always) is derived from the semantic meaning of the values, not how it's rendered. Renderers should match / reflect said semantic meaning. If they don't, then file avg reports to have them fixed.

“ensure the parish is always prioritised”
What, precisely, do you mean by prioritised or priority?

Hierarchy (in this context / scenario) can be (and is, in OSM) derived by the relationship between which elements enclose others.

“Have left First Tower as a suburb though since it isn't really in town.”
While I agree that it doesn't seem to qualify as a town in its own right (but, then, what's the consensus definition of what does qualify? Hence raising the point that it should be discussed), it's not a suburb (of a(nother) town), either.

“Parish centres, as well as other important centres (Maufant, St Aubin etc.) should be marked with a village tag.”
Why? Only actual villages proper should be tagged place=village. Other places of importance should be tagged distinctly. Such as being selected as the admin_centre of an admin relation.

Hence why I see the need to discuss such things, to figure out sensible (semantic, machine-readable) ways of properly marking (tagging) the somewhat unique features of a small island, to have a well-thought-out scheme which is applied consistently, to be successful in presenting a case to developers of data-parsers (renderers, etc.) to handle such a scheme (which may well involve a per-nation conditional). Its likely that they don't know about Jersey's oddities and the challenges that poses, and probably guess that the rules for the mainland apply here. For example, note that the group of islands to our SE (I forget which name is for which group, nevermind being able to spell it correctly, without looking it up, while using a limited device) are mapped as being French territory, rather than ours. Though, perhaps that simply means that they're disputed. My point; unless developers have the necessary info (from locals who even know of OSM) then they'll have to make assumptions based on guesswork. Yet, in my experience, many are receptive to learning about places where the assumed rules don't apply, and what the actual situation is, and are willing to do the necessary work to make an exception / conditional for such places.

“St Helier, St Saviour and St Brelade with a town tag due to their relative importances.”
Why? Parishes aren't towns. Only actual towns proper should be tagged place=town .

Importance can & should be derived from semantic hierarchy. Else, there needs to be devised a method of tagging places on the small scale of this rock.

Just as it would be incorrect (even if convenient) to mark parishes as states, since they're not states.

For now, maybe simply place=parish (this is one of the advantages of textual key:value pairs; new values can be set whenever needed). Did you check what less-common values exist in TagInfo? If place=parish suddenly appeared, and only here, then that would get some people (developers & influential mappers) thinking & enquiring, rather than continuing to assume that their guesses are valid.

Think beyond renderers; when querying the count of towns in Jersey, the answer should be 1, not 13.

“parishes are admin level 8, vignatines/cuillettes level 9”
Why, precisely?
What's at level 3-7? (If I recall, level 2 is for nations; else if it's level 3 then my previous question would be for levels 4-7.)

“the goal should be that visualisations prioritise parish names over anything else”
Why the focus on visualisations (by which I assume you mean graphical renderings)?

I strongly disagree, based on said focus. It also goes against OSM policy & technical-soundness (from which policy seems to be derived).

The goal is an accurate libre map (which is the dataset of tagged elements). How that's rendered is a distinct concern. There are several renderers, and many different renderings, which focus on different features (some deliberately omit labels). So, data accuracy is paramount to not hinder that. Multiple renderings from the same data is hugely beneficial; as one (major) example, it avoids the problem of trying to design a single rendering to please everyone; different renderings for different target-audiences.

Take a look at the layers tab on the website; compare how some of those are significantly different to OSM Carto (the default). All rendered from the same data. There are quite a few others which are radically different.
Several use-cases involve no rendering.

So, while I do agree that, regardless of appearance, in a nested list denoting the hierarchy of the likes of parish etc., that parishes are (locally) quite high (but under the island & bailiwick, at least), and that common-use renderings should reflect said hierarchy (but how they do that is another question; there are several ways), I absolutely disagree that data should be corrupted to pander to any particular renderer. That's backward, and significantly reduces the value of the data (and thus OSM).

Renders are to be slaves to data, not the inverse. Don't treat them as invariable, and to be worked around. Help improve them by bringing problems to the attention of their developers; that benefits everyone, and achieves the best of both (accurate data, representative renderings).

What you see on orm.org is merely there for convenience (so that the minimum requirement is only a browser). It's certainly not the best way to use the map. Many folks seldom look at the OSM Carto rendering, including for day-to-day usage (e.g. reference & navigation). Consider how popular OsmAnd is; that downloads the map data and renders it locally (for a whole variety of reasons; many more features (e.g. searching (offline) are possible that way). You've used StreetComplete, which uses yet another rendering still.

To try to achieve ideal rendering, in each renderer, without changing any of them, all by data-fiddling, will be impossible & futile.

Start with accurate data. If renderers handle it badly, then address THAT problem (of the renderer).

Seriously; read osm.wiki/Tagging_for_the_renderer since it gives examples and somewhat explains (though, not well about WHY, but I'll edit that when I can).

If you have particular questions (since the concepts are abstract, and it's within my realm of expertise) then fire away and I'll do my best to address them.

That's actually why my draft response became lengthy; I attempted to give a crash-course on why the sensible way is such, and a bit of the history of the problems it avoids.

I suspect that you may have picked up some misconceptions from certain others who focus on the default rendering regardless of the data.

Hopefully this provides enough food for thought.

@SomeoneElse
Except that one *can* control when StreetComplete closes sets, being an experienced user myself.

Plus, when I've pointed out the problem to others, there have been several instances of positive feedback, even thanks, because they were glad to learn how to do it better (viz having more control).

There's no point making excuses for buggy editors or improper-usage by mappers (some folks use SC as a general-purpose editor, rather than only for surveying). Users are responsible for their account and what's uploaded via it.

👍🙂

Remedying false-value changes from changeset/113918944

Here; uniform AND *accurate*/*correct*: changeset/113954606 . This clean-up took the best part of an afternoon, instead of being able to do productive work (elsewhere).

See note/2939819 with attached photos (captured 2021-11-18).

See also discussion of changeset/113918944 .

Further thoughts; part of why I tagged only Broad Street itself was because that's where the restriction signage was.

Incase it was re-opened to (general) motor_vehicle traffic, that made it easy to update, rather than having to remember to re-tag all the subsequent roads, too. If they weren't also re-tagged then that would adversely affect routing.

Changing fewer elements means less bloat in the database (since each revision is preserved), too.

In terms of routing, since it's a one-way system, then Broad Street being closed also means that the subsequent roads are inaccessible (by motor_vehicles); a cascade effect of the same restrictions without having to make them explicit on each subsequent road. Particularly since there's no signage (about these access restrictions) at those locations.
However, I suppose the counter-argument is routing for non-motor traffic (pedestrians, bicycles, etc.).

I was attempting to avoid an obvious failure-mode in future (whatever that might be, when the States decide if Broad Street remains pedestrianised or re-opens to motor traffic). If it remained closed, then re-tagging all the subsequent roads would definitely make sense. But, even the States don't know if it's (long-term) temporary or permanent(, yet).

The general policy on temporary changes (e.g. roadworks) is to be very careful about them, since some data-users don't fetch updates for a long time (months, or sometimes never).

Strictly, we should be using *:conditional tagging, with OH syntax, so that the data contains the current published end-date, which we simply keep bumping as the term of the restrictions is extended. But, from what I've read (re how to properly handle the likes of roadworks) very few data-parsers make use of those sorts of conditionals (e.g. highway:conditional). However, wouldn't hurt to add them alongside other tagging.

See note/2939819 with attached photos, captured circa noon 2021-11-18 .

Sigh. Please explain these changes, since the changeset comment is unclear.

From what source did these changes come? None was specified.

The values were set based on survey and reading signage (thus now the source:* tags are completely misleading). That took a while for me to do (and the weather isn't exactly hospitable, lately), which has all been undone here & will need to be redone; most frustrating.

Besides surveying & (non-temporary) signage, http://roadworks.gov.je/JSW/ makes very clear (if you look up the entry for Broad Street, unfortunately there's no dedicated / specific URL for the entry) that “… Broad Street will be closed to facilitate pedestrian prioritization. Commercial Vehicles will be able to gain access between 7am and 11am (Please note the end date is subject to change); Bus Routes Affected: 4 V.B,19 OUT,19 V.AA,19 V.BB,25 OUT,” & “Road Closed”.
Roads affected:
▪︎“Broad Street”
▪︎“Charing Cross”
▪︎“York Street”

The restrictions apply “All Day”, “Fri 1 Jan 21
Fri 31 Dec 21” (which they keep extending, since it's “In Progress”).

So, it's most certainly not motor_vehicle=designated at all. The opposite.

Since OSM is about mapping what's on the ground, no source trumps survey. So, unless you surveyed this very recently ….
I'll be surveying today, so this will now be my first target (I was gonna go elsewhere to add & correct other things, but alas).

Accurate tagging always comes before uniformity. Besides correctness, these changes will affect routing.

The values of source:* aren't uniform to the majority (in Jersey) of similar tagging of other (surveyed) elements, either.

I see no reason why this whole set shouldn't be reverted. All you've done is undo my surveying corrections, by applying false values, for seemingly bogus reasons. Please cease & desist.

N.B.; these StreetComplete quest-answers were collected offline over ~2 years.

N.B.; these StreetComplete quest-answers were collected offline over ~2 years.

N.B.; these StreetComplete quest-answers were collected offline over ~2 years.

N.B.; these StreetComplete quest-answers were collected offline over ~2 years.

N.B.; these StreetComplete quest-answers were collected offline over ~2 years.

N.B.; these StreetComplete quest-answers were collected offline over ~2 years.

N.B.; these StreetComplete quest-answers were collected offline over ~2 years.

N.B.; these StreetComplete quest-answers were collected offline over ~2 years.

N.B.; these StreetComplete quest-answers were collected offline over ~2 years.