Don't tag for the renderer. File bugs with them if you want them to support it.

Lifecycle prefixes are broadly used and are valid tagging. If someone chooses that approach, redoing their work is not appreciated.

Waarom? Er is niks mis met ruins:building. Lifecycle prefixes zijn breed gedragen en goed gedocumenteerd.

Teruggezet naar de versie van TrickyFoxy.

Nee klopt. Algemene nummers horen daar niet thuis.

Ik zie het nummer wel staan bij Zwolle, maar Amsterdam noemt geen nummer.

Ik kan die telefoonnummers niet terugvinden op de bron die je noemt. Het zijn ook allemaal 088-nummers. Horen die wel bij de vestigingen? En zo ja, zijn ze wel openbaar?

If you really dislike the way portage is used on waterways, you could propose an alternative which keeps the information (like 'use_portage'), but that would require coordination with other canoe mappers.

Either way, replacing these with 'no' results in loss of valid data, so please do revert.

I've documented ice_skates=kluning myself. I used canoe=portage as an example, so I am familiar with both. I've made some edits to the canoe documentation as well, which I've discussed with others using that tag at the time.

At that point the use of portage on a waterway was analogous to use_sidepath: it is a 'no' which indicates the why as well (a detour is available and either mandatory or physically required).

That is useful, because data consumers rendering a map for non-powered boats can indicate that that stretch of water is part of the route, but requires portage, as distinct from a blocked part of the route with no mapped portage alternative.

If you want to change the meaning of an existing tag, opening a discussion would be step one. By making edits in small areas you are changing an existing tagging scheme quite under the radar. That is not the right way to approach this.

canoe=portage on a waterway is defined as meaning that you cannot pass there using a canoe (ice_skating is similar). Is this a misunderstanding on your part, or did I miss the discussion about this? The wiki shows nothing on the talk-page for canoe or canoe=portage.

What you are doing is not in line with how the wiki documents this. Are you just unilaterally deciding that this tagging method is not OK?

Bijvoorbeeld: way/952082146

Als je van een track een service maakt, dan moet je tracktype vervangen door surface. Dus tracktype=grade1 (of grade2) wordt dan surface=paved, grade3 en hoger wordt surface=unpaved of surface=grass.

Die tracktype hoort alleen bij highway=track namelijk.

Bij highway=footway laten we bicycle=no weg, die is impliciet.

This change was reverted. Please don't assume that 'paad' is a misspelling. In this province names can be written in Frisian, Dutch, or a local dialect.

Wat doet connect:lanes? Ik zie geen documentatie voor die tag of prefix.

Zou je iets uitgebreider kunnen zijn in je changeset-commentaar? Alleen de plaatsnaam zegt erg weinig over wat je doet.

Zie ook:

osm.wiki/Good_changeset_comments

Snel gedaan ook; ze openen vandaag.

@dmjab13: In this case, defensible.

@Pieter: Thanks for fixing this.

(Ze zouden namelijk eigenlijk nobrand=yes moeten gebruiken.)

Ik zat even wat verder te kijken, en ik vermoed dat dit een bug is in MapComplete. Die voert not:brand=yes in wanneer je aangeeft dat iets niet bij een keten hoort. Waarschijnlijk heb jij daar als gebruiker van MapComplete geen invloed op. Ik heb de bug daar gemeld.

Met de adressen en de andere namen zoals Hogepol botst dit verder niet echt. De Hogepol heeft als straat al een stevige aanwezigheid.