At least one way created in this changeset has been removed, due to it not existing -at least on compatible aerial imagery-;
osm.org/changeset/133557689
following user feedback from
osm.org/note/3261130

See this wiki page to learn more
osm.wiki/Verifiability

-

(is: https://resultmaps.neis-one.org/osm-discussion-comments?uid=8739140 )

Hey Anne,

osm.org/way/1034576117
looks like a driveway on someone's private property, enclosed by walls, which happens to measure a car's length, and may not have a gate in front of it (one of many). I would suggest to remove it and add a way from the road, tagged as usual
highway=service
service=driveway

I personally do not use parking for individual houses outside exceptional cases where it looks like an open, standalone parking spot, located directly alongside the road, which may have a barrier (i.e. removable bollard), sign or marking indicating it is private/restricted. Or, where it is parking along a service road, say for an office/shop/... .

Regards,

Daniel

Hey Anne,

See osm.org/way/161760101
Are you sure Penston's Garden derives its name from the River Breaghagh?

Regards,

Daniel

*correction: added two trees

Consider also moving the wheelchair tag to the POI node. This tag is more commonly associated with the POI. It is often missed by accident when moving POI information from a building to an address node and vice versa.

Could you message b-unicycling regarding this as well, please? Thanks in advance.

Ok. I'm exaggerating quite a bit since people tend to tag everything with a lifecycle prefix. Sorry.
I'll leave it as a seperate node for now and maybe it can be surveyed in the future if the building/rooms have any ref, eventhough they may not be signed anymore.

Source should be (use as reference only)
https://www.archaeology.ie/sites/default/files/media/publications/po19v1-all-counties.pdf

I would suggest using lifecycle prefixes only for main keys, not for properties such as mapillary, as this is redundant.
I would add this information to the proper object instead -which I was hesitant to do-, namely the rectangular building it is on, since it has multiple entrances which IIRC seem to lead to the same space.
or, alternatively, add a main key
demolished:tourism=information
information=sign

Regards,

Daniel

Hi,

I'm using
- mapillary for the best image of an object; and
- *:image for one property of the object. This is intended for mappers, not for general users of the data. Noteably, some of these images lie in unexpected locations and there may be many other traces hiding them.
I'm aware I've been inconsistent with the use of mapillary id vs full url, since this an uncommon approach.

b-unicycling has also used *:image for the etymology of street names in this area.
I would appreciate if you'd discuss the use of tags with both of us before changing them. This prevents removal of correct data / (un)intended vandalism and issues with other mappers.

Also, usually an object only has a single mapillary value, which would be the best image of an object rather than any number of mapillary images available for said object. A single value is also better understood by applications.
I'm using *:image preferably only for exceptions. Elsewhere in Castle Yard I used it to refer whether the name came from the map board or a sign, since these may differ.

Regards,

Daniel

Looks good to me.

Regards,

Daniel

This may be a duplicate of osm.org/node/9825025724
or inaccurately positioned inside the back area of the hardware store. Make sure this is the correct position and the other object still exists. If the position is ambiguous (in front of / behind fence, close together), it may be a good idea to add a location tag to both objects.
(Sidenote: occasionally, such signs may be inside a property but be meant to be read from outside the property. It may therefore be useful to add a direction tag.)

This object is already tagged as disused with disused=yes. As such another lifecycle tag is redundant. Alternatively, you may remove it and instead add it as lifecycle prefix to the POI (disused:amenity=cinema). Both apply to the building as well as the POI unless otherwise mapped/noted.

was:* is usually used on physical objects to indicate they are still visible(recognizable) on aerial imagery, but no longer exist on the ground, or have intentionally changed use (i.e. nature conservation explicitly closes path to the public to let nature take over)

(Sidenote: If the building has since been in use again, please add/change the proper tags. Any information is welcome.)

This changeset has been reverted by
osm.org/changeset/131247841

Ja, ziet er naar uit dat ze daar beplanting neergezet hebben. Dit is duidelijk slechts een voetpad, zonder enige logische plek of bebording voor fietsers. De fietsstrook zelf is in zijn geheel verplaatst naar de andere kant van de weg.
https://www.mapillary.com/app/?pKey=1288760338360830&focus=photo
(Mapillary is een bron die is toegestaan voor gebruik in OpenStreetMap, private / copyright bronnen zoals Google Maps/Streetview zijn dit niet.)

Ter informatie: Pas alleen dingen aan als je het zeker weet. Iets wat een voetpad lijkt op de luchtfoto kan nog altijd (bebord als) een fietspad zijn. Als je er recent langs bent geweest om dit na te gaan kan je als bron in je wijzigingenset "survey" toevoegen, of als je er (minder recent) wel langsgekomen bent en dit gezien hebt kan je "local knowledge" als bron erbij zetten.

Bedankt voor de aanpassing.

Groeten,

Daniel

bus=yes is op zich optioneel, ligt er ook aan hoe dicht je een van de bestaande tagging schema's wilt volgen. iD kiest ervoor om bus=yes voor te stellen als het een bushalte betreft. Ook deze soort oplossingen van de bewerker kun je dus negeren wanneer je begint met mappen.
(zeg maar gewoon alle oplossingen.)

Hey thickness,

De gebouwen komen in Nederland uit de BAG (Basisregistratie Adressen en Gebouwen). Veel gebouwen zijn nog niet ingemeten en hebben een plaatsvervangend vlak. Wanneer ze ingemeten zijn kun je een verse import aanvragen op het forum:
https://community.openstreetmap.org/t/bag-importverzoeken/3394

Je kunt de BAG hier bekijken:
https://bagviewer.kadaster.nl/

Als je dit nu handmatig zou veranderen zou het later waarschijnlijk ongedaan gemaakt worden met een nieuwe import.

Als er een gebouw ergens staat wat er niet langer is, kan je dit terugmelden bij de BAG zelf (wel even checken of het ook in de BAG zelf voorkomt).

(Ter informatie: Neem oplossingen van de software niet over zonder goed te kijken of het echt een probleem is / er niet iets anders voor problemen zorgt en raadpleeg indien nodig de gemeenschap.):
osm.wiki/Contact_channels

Maak je geen zorgen, alle dingen kan je leren. Het is dan ook goed dat je deze wijzigingenset voor controle hebt gemarkeerd.

Ik heb de gebouwen in deze wijzigingenset hersteld:
osm.org/changeset/130839221

Groeten,

Daniel

Two empty ways:
- osm.org/way/1126142325
- osm.org/way/1126142338

One abandoned outer member
- osm.org/way/1126142318

Hey Victor,

You only need to add a lifecycle prefix to the main key (here: highway) in order for it to no longer render on the standard style (Carto). It is also easier to maintain.

Keeping name as name (not old_name or name:YYYY) is fine for no longer existing physical objects. It will also be easier to find for other projects using the data (if they'd like to know it at all).

Sidenote: the name of an abandoned highway, unlike that of an abandoned railway with the tag railway=abandoned, won't be indexed in the standard search (Nominatim).

Regards,

Daniel

Ansonsten ist es sehr verständlich, dass Sie einige Fragen dazu hatten, und danke, dass Sie den Entwicklern des Tools ein Problem gemeldet haben.

Otherwise, it is very understandable that you had some questions about this and thanks for submitting an issue to the tool's developers.

Zu Ihrer Information:
Unter keinen Umständen sollten Sie in großem Umfang (halb-)automatisch Tags in etwas anderes in der Datenbank ändern, ohne sich an den [Verhaltenskodex für automatisierte Bearbeitungen](osm.wiki/Automated_Edits_code_of_conduct) zu halten. Jede solche Änderung wird rückgängig gemacht.
Sie sollten wirklich wissen, was Sie tun!
(Fehler zu machen / es aus Versehen falsch hinzuzufügen ist natürlich in Ordnung)

Bitte lesen Sie [Key:wikidata](osm.wiki/Key:wikidata#Secondary_Wikidata_links) im Wiki, um die Struktur der Kennzeichnung zu verstehen. Beachten Sie, dass Objekte, die für ein `subject:wikidata`-Tag in Frage kommen, normalerweise auch eine `wikidata`-Seite haben, die sich auf das Objekt selbst bezieht. Achten Sie darauf, dies zu überprüfen.

In diesem Fall wird schnell klar, dass die bestehenden wikidata bereits auf das Objekt selbst verweisen.

Hinweis: Sie können sich auf wikidata und wikipedia durchklicken, um zu sehen, was ein Begriff bedeutet, auch in verschiedenen Sprachen.

wikidata=Q1424213
Instanz von:
Verbrennungsanlage => (siehe Wikipedia-Liste):
Müllverbrennungsanlage

"Land" "in einer Verwaltungseinheit gelegen" "Koordinatenort"
Sie alle verweisen auf etwas, das einen Standort hat. Dies ist in der Regel das Objekt selbst.

wikipedia=de:Müllverbrennungsanlage Dürnrohr

Im Wikipedia-Titel - und im OSM-Namen - ist ein Ort enthalten. Dies ist sehr wahrscheinlich das Objekt selbst.

"Die Müllverbrennung Dürnrohr [...] ist eine

Müllverbrennungsanlage

[...] in Dürnrohr."

Dies bezieht sich eindeutig auf das Objekt selbst, nicht auf den physikalischen Prozess.

Wenn Sie auf den Wikipedia-Artikel für "Verbrennungsanlage" / "Müllverbrennungsanlage" klicken
klicken, werden Sie zu einer Seite über den physikalischen Prozess "Verbrennung" / "Müllverbrennung" weitergeleitet, da Wikipedia selbst nicht, wie Wiktionary (das Wörterbuch von Wikipedia), ein Wörterbuch für jedes Wort ist. Es konzentriert sich darauf, das Gesamtbild zu erklären.
(Außerdem gehe ich davon aus, dass Sie wissen, was das Wort bedeutet)

Außerdem sollten Sie, wenn Sie "ein Thema" erwähnen, andere Beiträge zu diesem Thema verlinken.
https://github.com/matkoniecz/OSM-wikipedia-tag-validator/issues/11

For your information:
Under no circumstances should you (semi-)automatically change tags to something else in the database on a large scale without conforming to the [automated edits code of conduct](osm.wiki/Automated_Edits_code_of_conduct). Any such change will be reverted.
You should really know what you are doing!
(making mistakes / incorrectly adding it by accident is fine of course)

Please read [Key:wikidata](osm.wiki/Key:wikidata#Secondary_Wikidata_links) on the wiki to understand the tagging structure. Note, objects which are eligible for a `subject:wikidata` tag usually also have a `wikidata` page to refer to the object itself. Make sure to check this.

In this case, it quickly becomes clear the existing wikidata already points to the object itself.

note you can click through on wikidata and wikipedia to see what a term means, also in different languages.

wikidata=Q1424213
instance of:
incinerator => (see Wikipedia list):
Müllverbrennungsanlage

"country" "located in administrative entity" "coordinate location"
These all point to something with a location. This usually is the object itself.

wikipedia=de:Müllverbrennungsanlage Dürnrohr

There is a location in the Wikipedia title -and in the OSM name-. This is very likely the object itself.

"Die Müllverbrennung Dürnrohr [...] ist eine

Müllverbrennungsanlage

[...] in Dürnrohr."

Clearly, this is refering to the object itself, not the physical proces.

Noteably, when clicking on the Wikipedia article for "incinerator" / "Müllverbrennungsanlage"
you will be redirected to a page about the physical process "incineration" / "Müllverbrennung" because Wikipedia itself is not, as Wiktionary (Wikipedia's dictionary), a dictionary for every word. It focuses on explaining the broader picture.
(besides, I assume you know what the word means)

Also, when mentioning "a issue", you should link other contributors to said issue.
https://github.com/matkoniecz/OSM-wikipedia-tag-validator/issues/11