GoMap!! already supports live OCR to fill in opening_hours by scanning a sign with the camera. It would be great to extend this to the destination tag family (destination, destination:ref, destination:street).
A natural and uncontroversial starting point is the tourism=information + information=guidepost use case. Guideposts (hiking, cycling) are simple nodes whose content is well-defined and consistently tagged by the OSM community. The node records the physical existence of the sign; the destination=* values are then placed on the ways departing from it to serve routing. Scanning the arms of a guidepost directly into the tag field would significantly speed up this workflow in the field.
The same principle extends naturally to road destination signs: here too, the sign attests its own existence, while the destination values live on the way (the road segment leaving the junction) for navigation software to consume. Two separators are at play: ; between multiple destinations on the same element, and | between lanes when using destination:lanes.
The approach would mirror the existing opening_hours implementation: a camera button appears when editing a destination-family key, the recognised text lines are proposed as selectable candidates, and the confirmed values are written to the tag.
GoMap!! already supports live OCR to fill in opening_hours by scanning a sign with the camera. It would be great to extend this to the destination tag family (destination, destination:ref, destination:street).
A natural and uncontroversial starting point is the tourism=information + information=guidepost use case. Guideposts (hiking, cycling) are simple nodes whose content is well-defined and consistently tagged by the OSM community. The node records the physical existence of the sign; the destination=* values are then placed on the ways departing from it to serve routing. Scanning the arms of a guidepost directly into the tag field would significantly speed up this workflow in the field.
The same principle extends naturally to road destination signs: here too, the sign attests its own existence, while the destination values live on the way (the road segment leaving the junction) for navigation software to consume. Two separators are at play: ; between multiple destinations on the same element, and | between lanes when using destination:lanes.
The approach would mirror the existing opening_hours implementation: a camera button appears when editing a destination-family key, the recognised text lines are proposed as selectable candidates, and the confirmed values are written to the tag.