[OSM-talk] Disappearing footpaths

[D Tucny]

On 04/04/07, Lester Caine <lester at lsces.co.uk> wrote:
>
> 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.
> >>>
> >>> WHY? Why make unnecessary work changing bridleway to horseway?!
> >>>
> >>> Why on earth bother changing the common term for something to
> something
> >>> nonsensical. And it's just a tag value. It could be wibblewobble as
> long as
> >
> > Absolutely.
> >
> >> Not taking sides - but there is one reason, is bridleway the normal
> term
> >> in Iraq or Germany?
> >
> > Tags names and preset values are in British English. We would be crazy
> > to try to change that, no matter how bad it is from a politically
> > correct point of view, at least not until we can support multiple
> > languages simultaneously. The only exception is if there are items that
> > only exist in other languages, in which case using the local language is
> > fine.
> >
> > The only way I can see to do that is to have a layer of abstraction
> > between the data users see and what the database calls the tags
> > internally. Once we have done that, the internal name may as well stay
> > with the English name. Anything else would be lots of work for no gain
> > whatsoever.
>
> This is one of the major reasons that XML is simply not a sensible storage
> medium ;)
> Scrap the use of full text for all these items and create a simple lookup
> table of values, with sets for each language. The tools then store the
> number
> and present the user with the currently approved list of values for their
> language.
> Solves a number of problems with one simple step?



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...

d
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20070404/435ce9e8/attachment.html>