Hier zie je wat ik heb gedaan:
http://overpass-api.de/achavi/?changeset=114999580

Kan je een voorbeeld geven van wat volgens jou verdwenen is?

Bedankt voor de reactie. Ik had de nieuwe farmland multipolygoon in eerste instantie niet opgemerkt, waardoor ik die treerow way niet zomaar wilde verwijderen. Is ondertussen wel gebeurd.

Graag een reactie, want ik zie niet direct hoe dit opgelost kan worden, tenzij door het terugdraaien van de wijzigingenset.

Ik bedoelde "Krommebeekbos"

Uiteraard niet fijn om ongewenste bezoekers over de vloer te krijgen. Het (volledig) verwijderen van wegen is echter niet altijd een goede oplossing om dat te vermijden. Het is beter om duidelijk aan te geven in het kaartmateriaal dat een weg enkel toegankelijk is voor privaat gebruik. Op die manier vermijd je ook dat iemand op basis van luchtfoto's de weg opnieuw intekent en geen informatie geeft over de toegangsvoorwaarden.

In jullie wijzigingen hadden jullie ook de grens tussen Proven en Krombeke verlegd, wat wellicht niet bedoeld was.

Ik heb jullie wijzigingen teruggedraaid en de door jullie verwijderde wegen als "privaat" aangeduid. Ik heb wel de passage over jullie erf ervan tussengelaten, aangezien je bezwaarlijk kan zeggen dat er daar echt een weg loopt.

Deze way heeft de tag natural=tree_row gekregen in jouw changeset: way/112604627/history
Wellicht een foutje.

Hi, good thing you spotted the typo. highway:virtual is mentioned as an alternative for this proposal: osm.wiki/Proposed_features/virtual_highway

So far from an 'official' status at this moment, but there is some use: https://taginfo.openstreetmap.org/keys/highway%3Avirtual#values

I think it's mainly used to cross pedestrian areas. In this case, I think we could just continue the path (without :virtual) and connect it to the main road

Zou uiteraard kunnen. Mapillary beelden zijn van twee maanden geleden, dus zou recent verwijderd moeten zijn.

Dag Dieter,
Het ging hier om een vrij ingewikkelde multipolygoon. Ik heb hem proberen fixen, maar best nog eens checken of het er nu goed uitziet.

Tof dat je deze bank en picknickbank hebt toegevoegd!

Ik vind die tags juist erg nuttig. Als ze er niet staan, dan zijn er twee mogelijkheden: 1) er is geen fietspad 2) er is wel een fietspad, maar dat is niet (nog) niet gemapt/getagd. Vandaag nog een query gedaan op wegen waar de maximumsnelheid 70 km/u is, maar waar er geen fietspad is. Voor dergelijke queries wil je die tags echt wel gebruiken en kan je niet zomaar veronderstellen dat er geen fietspad is als er geen fietspad-tags zijn.

I've reverted your change set because of this.

@Poutape: when mapping a MTB route, please add existing roads to a route relation. Do not simply draw a path on top of existing roads. See osm.wiki/Relation:route

Op way/24791432/ heb je de highway-tag verwijderd, waardoor dit segment niet meer als weg herkend wordt en ook niet meer gebruikt wordt voor routering. Ik heb opnieuw highway=cycleway aan deze weg gehangen zoals ervoor, al zou het goed zijn om eens grondig te bekijken of cycleway wel de beste waarde is voor deze weg.

Hallo S_Torre, bij highway=construction gebruiken we osm.wiki/Tag:construction=... om aan te geven wat de weg na de werken zal worden (zie highway=construction). Ik ben er van uitgegaan dat dit "footway" zal blijven en heb het in die zin aangepast.

Dag Dieter,
Je kan in zo'n situatie kiezen om ofwel
a) het fietspad te laten aantakken op de Grintweg en het stuk Grintweg onder de brug te taggen met cycleway=lane of cycleway=track
b) het fietspad volledig apart in te tekenen, parallel met de Grintweg, maar waar je oversteekt een verbinding te voorzien.

Ik heb in een kleine aanpassing voor de tweede optie gekozen.

fout gemaakt in deze changeset, rechtgezet changeset/111419581

I agree with you, it should be one of those two options.

I'm not on the tagging mailing list because of its reputation of endless discussions, but I guess it's the place to go to if we want to settle this :-)

Personally, I liked the nuance hinted at in the wiki between no and not. It makes sense to me that if there are two different concepts, there are also two different prefixes.

Generalizing this case to the idea that we should always go for the the more common prefix / key to avoid subtle differences in meaning is a huge mistake in my opinion, I'm sure we would agree on this when we look at other cases.

For this specific case, I can understand your standpoint, but I don't think using the no prefix is a mistake, giving the description in the wiki. Therefore, I would have appreciated a changeset comment more than just a blunt editing of the tag.

Hi mueschel,
I carefully read the wiki (both no=*: and not=*:) before mapping these. The idea I got was that not: is better suited to avoid confusion with something else that exists in reality, while no: is better suited to indicate that something you would expect to be on the ground does not exist in reality. In these cases, a traffic sign that should be there is not there in reality, there is no confusion with other traffic signs or other objects. That's why I chose "no".

Is your changeset solely based on "not:" being more common? Or do you disagree with the wiki or my reading of it?