Talk:Thames Path

From OpenStreetMap Wiki
Jump to navigation Jump to search

Data structures used to store long distance walking routes. I presume that some walks, such as those across unpopulated areas, will have natural sections decided by the limited availability of transport access, overnight accommodation or whatever. Others, especially those in urban areas, abound with places to start and end a walk along the defined route. Walks within a long-distance route can be packaged according to the walkers' needs, whether they be a 15-mile-a-day hiker or an 5-mile stroller. In urban areas the routes provide the opportunity to visit numerous places of interest, and for some users this will be a primary interest and little mileage will be covered. These choices should be made by the user, not written in to the data structure. If the divisions exist physically on the ground (e.g. unpopulated areas) OK, but unless they do the relation should not be subdivided at its data level. All these structures can be superimposed when it comes to extract and present the data.

Therefore, arbitrary data structures imposed on relations cut across the needs of the various user groups. 15-mile sections will be of little use to someone interested in visitng places along the route and 5-mile sections are an unnecessary complication for the long-distance walker. One of the current problems with long-distance walk relation is the time taken to render the relation, and the temptation is divide the walk by imposing arbitrary user-based divisions on the relation so that it renders quickly. This is not the answer - don't map for the renderer!

If a big relation needs better access algorithms then this is a matter for the database administrators and may involve the creation of some tree-like structure to reduce search times. There is no need to create these from one user perspective to the disadvantage of another. Multiples of miles/kilometers might be an appropriate alternative and useful for searching/planning. UrbanRambler 13:40, 17 January 2010 (UTC)