The refs for the routes I check are sparse, but they are signed here and there. The legs/sections have the same ref, e.g. LAW12, but nowhere on the streets can you find the section numbers. They are found on the official website and in the printed guides. Sometimes they were added to the ref, but then you get refs like LAW01-1-06A-1, showing on hiking maps (Netherlands Coast Trail =LAW01, part 1, section 6 alternative, day 1). That doesn't help anyone and just clobbers the map!
Just having 06A-1 as a ref is even worse for the user. The answer is to keep the ref as LAW06, and put the section information in a section ref. The two together can be used for ordered lists, the map just displays the ref, and the section ref is helpful when editing/ordering the relation hierarchy. This does not solve the problem for international superroutes. These tend to be more like collections of routes with very different attrbutes and tagging styles. But I think it does not hurt either. That issue can be addressed later! Peter Elderson Op za 23 mei 2020 om 20:47 schreef Kevin Kenny <kevin.b.ke...@gmail.com>: > > For now, I just want an alternative for the section/segment/leg numbers > or refs that are often in the name tag now. > > They are there to get neat ordered lists in tools and applications. That > seems to work fine, but it abuses the name tag, which I am told is a > problem for searching routines. A name tag should contain a proper name as > found on the street, and nothing else, that's the short version of some > very long rants I have encountered... > > > > At the moment, I move comments, descriptions, distance and trail refs to > the appropriate tags. > > From-via-to information I copy to the from, via and to tags. > > I just need a nice and intuitive tag to copy the ordering information to. > > If the section number is an official identifier, then it's a ref (or > possibly an unsigned_ref). There should be no collision because > nothing keeps a superroute from having a ref of its own. > > If you're identifying a section number in order to sort the members of > a superroute, Don't Do That. Keep the superroute in order. > https://www.openstreetmap.org/relation/919642 remains a worked > example; the sections are listed from south to north. Route relations > are ordered; they're not just buckets of members. > > _______________________________________________ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging >
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging