<br><div><span class="gmail_quote">On 04/04/07, <b class="gmail_sendername">Lester Caine</b> <<a href="mailto:lester@lsces.co.uk">lester@lsces.co.uk</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

Robert (Jamie) Munro wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > SteveC wrote: >> David Earl wrote: >>>> * to be consistant, shouldn't bridleway be replaced with horseway?

>>>> highway=bridleway tags to horseway :-) >>>> >>>> If only we had some way of getting a machine to do this tedious, >>>>> repetitive work ... >>> This whole thread has to be an April Fool's joke surely.

<br>>>><br>>>> WHY? Why make unnecessary work changing bridleway to horseway?!<br>>>><br>>>> Why on earth bother changing the common term for something to something<br>>>> nonsensical. And it's just a tag value. It could be wibblewobble as long as

<br>><br>> Absolutely.<br>><br>>> Not taking sides - but there is one reason, is bridleway the normal term<br>>> in Iraq or Germany?<br>><br>> Tags names and preset values are in British English. We would be crazy

<br>> to try to change that, no matter how bad it is from a politically<br>> correct point of view, at least not until we can support multiple<br>> languages simultaneously. The only exception is if there are items that

<br>> only exist in other languages, in which case using the local language is<br>> fine.<br>><br>> The only way I can see to do that is to have a layer of abstraction<br>> between the data users see and what the database calls the tags

<br>> internally. Once we have done that, the internal name may as well stay<br>> with the English name. Anything else would be lots of work for no gain<br>> whatsoever.<br><br>This is one of the major reasons that XML is simply not a sensible storage

<br>medium ;)<br>Scrap the use of full text for all these items and create a simple lookup<br>table of values, with sets for each language. The tools then store the number<br>and present the user with the currently approved list of values for their

<br>language.<br>Solves a number of problems with one simple step?</blockquote><div><br><br>Sounds good to me...  At the end of the day, arguing about bridleway vs horseway vs footpath etc makes no real sense... I'd say use anything unique for the real tags (either current form of tags or random/sequential unique identifiers, current form has the advantage of not needing to change everything) and get the editors to just implement lookup tables that give more information, perhaps different languages, perhaps descriptions of the rendering and default associated properties etc... There are of course a number of ways this could be done, downloadable table, downloaded each time by the editor, or local copy etc... JOSM has something a little similar with it's presets... Hell, they could be publicly modifiable... Then if people didn't like the tag, they could change it locally 

e.g. bridleway -> horsey_type_footpath_where_bikes_can_go but there would still be consistent tagging behind their view... The key thing has got to be to hide/protect some of the back end and bring the work to the user interface to make it easy and understandable and try to avoid wasting time over key/value names in the database as really, it should be irrelevant, as long has we have enough with the correct meanings to record all the information...

<br><br>d<br></div><br></div><br>