The description is not very talkative. What did you want to achieve with this changesets?

Tatsächlich trifft "the primary usage of the area is for dog-owners to exercise their pets unrestrained" nicht auf das Hundeauslaufgebiet zu – ein Satz, der die Definition von "leisure=dog_park" darstellt.

Der Hundeauslauf ist schon möglich, aber nicht die Hauptnutzung (Erholung und Natur haben laut Website Vorrang).

Demnach würde ich mich dir anschließen und statt "leisure=dog_park" "dog=unleashed" verwenden wollen.

Ah, den Issue wollte ich gerade auch verlinken ;)

Danke fürs Wiedereinfügen.

Ja, die vom restlichen Wald verschiedene Darstellung ist hier auf jeden Fall störend.

Das heißt, es ist jetzt kein Hundeauslaufgebiet mehr?

osm.wiki/Changeset#Geographical_size_of_changesets

Zusätzliche Quelle: Eigene Bilder

Done, ich habe den Knoten in die Linie eingefügt und seine (zusätzlichen) Eigenschaften übertragen

Hinweis: node/5898713292 hat eine westdeutsche Adresse, liegt aber in Berlin. Ich weiß nicht, ob das so gewollt war.

Rövershagen hat aber eine große Umgebung! ;)

Yes, I did indeed mean "colour" and corrected it now. Thanks for noticing.

Das Problem hatte ich auch schon mal.

Dann schlage ich vor, die beiden zu mergen und den Namen zum existierenden hinzuzufügen.

Du meinst nicht zufällig way/104677645?

Moin, das eine Wohngebiet ist ein Multipolygon mit nur einem Mitglied. Du willst vermutlich entweder einen ganz normalen Way oder eine unterbrochene Fläche für alles.

Äh, „layer“ statt „layers“.

(Ich glaube auch, dass dieses Dach den ganzen Gebäudeteil überspannt und nicht nur diese Eingangs-Ecke. Aber müsste ich nochmal gucken.)

Moin. Ja, der „levels“-Tag von vor deiner Änderung war auf jeden Fall verbesserungswürdig. Aber „layer=5“ scheint mir hier nicht ganz passend zu sein, da „layers“ nur die Ordnung zwischen Elementen bestimmen soll. „layers=1“ würde beispielsweise reichen.

Zusätzlich könnte die Höhe mit „building:min_level“ angegeben werden.

Moin! Zusätzlich zu building:parts wird stark empfohlen, das Gesamtgebäude als building-Linie zu kartieren. Es sollte selten building-parts geben, die nicht von einer Gebäude-Linie umschlossen werden.
osm.wiki/DE:Key:building:part

> Only the L7 protocol is specified.

Encryption is another matter. You're assuming that HTTP is non-encrypted, based on the HTTPS pseudo-protocol. There are actually several modes of encryption for HTTP.

Which of these modes is implemented by Wikimedia or how else could that be relevant? The answer is: It is not, "https:" URLs are the only way to retrieve resources from Wikimedia using HTTP. Also, do not confuse protocols with URL schemes. While HTTP does not exclude the usage of TLS, an "http:" URL does most certainly.

What you are referring to is that HTTP is specified separately from encryption. Which is true: A plain HTTP connection will not be encrypted. An "http:" URL refers to such a connection (or an alternate encryption mode, which is not relevant in this case, like in most other cases; and would also involve unencrypted HTTP communication before upgrading the connection).

With an "http:" URL, the client will not immediately know that it has to use a TLS connection until it gets the redirection.

Unless it has some state that tells to rewrite the URL to "https:" in the first place. Which you even mentioned, with HSTS and HTTPS Everywhere. But you wanted to convince me of the advantage of "http:" URLs. If these are only used for the redirect and avoided when the client has better knowledge, why not link to the resource directly?

> > You just assume the client would know to use https instead
> Not at all. You're projecting.

Above, I can read you speaking about HSTS. According to https://https.cio.gov/hsts/, "HSTS exists to remove the need for the common, insecure practice of redirecting users from http:// to https:// URLs." Note that redirecting is considered insecure here.
Where available, it is a good tool to avoid requesting "http:" resources and heading for "https:" URLs instead.

But with your statement "That's what HSTS and HTTPS Everywhere are for" you seem to assume that something alike is present. What about the bot you mentioned? What about a user who has no state from a previous visit? They will first use the URL that is written, thus using an unencrypted HTTP connection, weakening the advantage of HTTPS. If the link itself referred to the secure and correct location, everything would be fine and such mechanisms are not needed.

There are many cases with good reasons to leave redirecting links, e.g. shortlinks. This is not one of those cases.

> > So let me put your question the other way round. Why should it stay "http"?
> Already answered that. See my earlier response.

My fault, now I see it. You claim that "http:" URLs would be more "robust & future-proof". What makes you think this might be the case?

Also, you connected that with another assumption ("when encryption is done using the default port, over the same original connection"); an assumption that just did not hold up in this case.

Furthermore, your salty side-note "instead of 2⁸, because each protocol demands 2" leads me to think you might just not be a fan of dedicated protocol-over-TLS ports.
By the way: half of 2¹⁶ would be 2¹⁵, not 2⁸.

Also, from the same comment: "You're also defeating caching for a resource which is ideal for caching.".
The pictures are not subject to caching by middleware, as they will always be sent out encrypted. Caching a few redirects would be still possible, but is less benecificial than to avoid them.

> The burden of proof is yours; you're asserting that s/^http:/https:/g should be so. This is your changeset, too.

The correct behaviour of OSM is to link to resources by using the correct URL. I tried to replace outdated links by securer and more direct links.

> > "Besides, not all User-Agents need encryption (bots)."
> > They do, because Wikimedia does not support unencrypted HTTP connections. See https://meta.wikimedia.org/wiki/HTTPS for more info.
> LOL, you assume much.

I believe I have proven my "assumption" well, with an article that directly tells that the transition to HTTPS-only has ended.

A "LOL" is a possible answer, but does not help you in making a counter argument.

> Besides scope, Wikipedia insisting on HTTPS isn't a matter of the bot (assuming one which is concerned about fetching from WP) itself needing HTTP+TLS, but the site requiring it. The bot would be perfectly happy without.

Maybe the bot would be "happy" without TLS, but it is still required, so what choice does the client have? What does "happy" mean, by the way?

> Wikipedia does indeed respond to TCP/80, else how does it redirect to TCP/443?

Which is all you will get from "http:" URLs at Wikimedia: A redirect. They redirect to the correct resource, which is behind an "https:" URL. Which in turn is the correct resource locator.

Try it out right now: `curl -v http://meta.wikimedia.org/wiki/HTTPS` for example, if you have curl installed.
You will not get the desired resource, but a redirection to its correct location: "Location: https://meta.wikimedia.org/wiki/HTTPS"

The TCP/80 webserver is only present for backwards compatibility with older URLs and the like.

I have to rephrase my sentence to "Getting content on Wikimedia requires requesting an HTTPS URL", though. Requesting the "http:" resource beforehand is not necessary or constructive, as the location has changed.

> Sounds like you don't understand relevant networking, either.

Your opinion that "http:" URLs have to stay indefinitely is not the prevailing one in the IT industry and seems technically not very grounded. It staggers me you have no insight in this and even start to make insulting assumptions about people.

> > "the bbox is nebulous."
> > Which is the case every time you edit France or the United Kingdom.
> Relevance for this changeset?

In this changeset, I edited at least one country which generates a big changeset bounding box when changed. When noting a "nebulous" bbox, I assumed you were referring to its size.

> Your failure to read documentation causes extra changesets, due to the needed reversion.
It is still 2 changesets – versus many more, if I used one CS for one country. Your impression of "extra changesets" seems to be not correct.

> > I could understand the whish to remove the "flag" tags everywhere. But not the whish to keep "http" links.
> That's not a technical or OSM matter / problem.

I do not fully understand the motivation behind this sentence. Both intents would be only fulfilled by adjusting tags, which could be achieved by a changeset like this.

Again, this was not a mechanical or half-automated edit. I just selected objects with iD and discovered and changed tag values that were a bit outdated. Just that countries are a bit harder to select than other objects.

I think smaller changeset bounding boxes would be nice. These are only a few benches added, one of them not even in Europe.

See osm.wiki/Changeset#Geographical_size_of_changesets

Hey, welcome to OSM.

May I recommend this wiki article to you? osm.wiki/Changeset#Geographical_size_of_changesets