Typos in real words are easier to detect than a mistake in entering a number.
On Sat, May 10, 2008 at 2:45 AM, elvin ibbotson <[EMAIL PROTECTED]> wrote: > On 9 May 2008, at 12:21, Dave Stubbs wrote: > > > The mapping to numbers doesn't gain us anything. It doesn't let us do > anything we can't already do, or make it any easier as far as I can > see. > > > If the database, which is accessed by programmers, was numerically based, > it would be be more amenable to algorithmic logic. At the simplest level, > selecting elements with values above/below certain levels. The numbers would > of course have to follow some logical pattern. Similar procedures using the > current tags involve clumsier code like 'motorway OR trunk OR primary' and, > if users are actually typing these words in (rather than selecting from > human-friendly menus presented by the editor) a typo such as 'secodnary' > cold corrupt the database and prevent the feature being seen by map viewers > or routing engines for example. > > > I think you were actually suggesting something like "type=11" -- where > 10-20 means roads, 30-40 could mean railways etc. But as far as this > argument goes it doesn't really make much difference, other than > leaving us with a massive allocation problem which has been neatly > sidestepped by using free-form tagging. > > > Yes free-form tagging avoids having to decide on a pattern and allows for > open-ended evolution, but it doesn't work if it's completely free-form. I > could describe many roads around here as 'highway=country lane" but would > they get rendered? The fact that there are tagging recommendations > acknowledges that anarchy would not work. But a data structure would have to > allow change and evolution (at the simplest level, leaving spare numbers for > future use) and this is a challenge. > > > Indeed point missed again. > We DON'T DO (sorry Richard) highway=red. We do highway=primary and you > can make that any colour you like... same as you can do with > highway=13/type=13 -- it makes no difference is my point. Numbering > the highways won't help. > > > Now I'm confused. I'm not suggesting numbers to avoid red highways for > goodness' sake! > > > It could yes. There are a couple of issues with this mostly to do with > actually maintaining the style sheets and providing the processing > power/disk space. > > > Moore's Law should take care of those :-) > > > > No problemo! Special viewers like the cycle map would simply apply their > own > filters. And with well-structured data a map viewer could even have > settings > (eg. cycle routes on/off) allowing it to be customised by the user, making > a > proliferation of specialist viewers unnecessary. > > > Hmm.. yes, maybe. But the point of your e-mail was essentially > numbering everything, and that really doesn't help us with this goal. > > > It's just that numbers are easier for programmers (see above). Users would > never see them. They would see words in their own language and the > viewer/editor would map words to numbers. > > elvin > > > _______________________________________________ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk > > -- http://bowlad.com
_______________________________________________ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
