Nee, dat klopt niet. Ik zou ze zelf uitsluitend mappen als ze nodig zijn voor het routeren, en in dat geval als wegpunten, intersecties waar je een keuze moet maken. En dat zou ik dan op de weg willen zien, doordat de bordjes aanwijzen naar welk punt je gaat als je het pijltje volgt.
Voor kilometerpaaltjes, of volgnummertjes waar je vanzelf langskomt als je een keuzevrije route volgt, zie ik zelf bij de huidige stand van de toepassingen geen meerwaarde om te mappen. Maar als iemand anders dat wel ziet, dan is het wel OSM dat-ie het mag mappen. Tenslotte zijn het verifieerbare objecten.
Als je dan de objecten zelf mapt, dan ook op de exacte plaats waar ze zich bevinden.
Ik vind dan wel dat er een objecttype op zou moeten, een tag die een object aangeeft. Een node met alleen een of ander refnummer is vreemd. (Dat geldt natuurlijk evengoed voor knooppuntpaaltjes, maar die boot is allang weggezeild: daar is gekozen om voor het routeerbare netwerk logische intersecties te gebruiken die zelf helemaal geen object zijn).
En áls er dan een objecttype is, dan kun je volstaan met de ref tag. Bijvoorbeeld marker=post, ref=10. Oftewel, dit is een paaltje met nummer 10 erop.
Maar, stel dat je besluit toch lcn_ref te gebruiken, dan denk ik wel dat je rekening moet houden met hoe dat in het verleden gebruikt is. Dan moet je MI bouwers van toepassingen de gelegenheid geven om te kijken wat het gaat betekenen, en eventueel hun filters of stijlen aan te passen.
Dus eerst dokumenteren, gevolgen inventariseren, wat ruimer aankondigen, feedback verwerken, en werken met een ingangsdatum. Een proeflokatie mag wel, vind ik, want velen hebben een voorbeeld nodig om te snappen waar het over gaat.
Dat is niet erg leuk werk, maar het zorgt wel voor bekendheid en draagvlak.