> > I like this - but would suggest a small change: > > highway=crossing > > crossing=zebra|toucan|pelican|... > No, get rid of the UK specific classifications of crossing completely - > they require too much background knowledge to interpret and are pointless if > you have already split out the various properties into separate tags.
OK - but this means that even for the simple cases you have to enter 4 times as many tags. People are lazy (well I certainly am!) and tend to use the easier method - which means people stick with the existing solution and ignore the new method. > I'm not a big fan of having many alternative ways of defining exactly the > same feature. A better way to implement "shortcuts" is to have presets in > the editors which automatically set the appropriate tags. Implementing presets for this in the editor is a viable alternative. But they need to be implemented in all editors - which could be tricky? Presets could also be implemented centrally server side as part of the 0.6 api change - i.e. an uploaded tag of crossing=zebra|toucan|pelican|... could be 'fixed' on the server and returned back to the client for display (I'm sure almost everyone will absolutely hate this idea!) > > My feeling is this leaves lots of room for future expansion without > > breaking backwards compatibility with most of the existing data. > > What do people think? > IMO It just adds lots of redundent data, which massively complicates > anything interpretting it (e.g. the renderers). A clean change over to a > totally new system would require no more complexity, but would make it > possible for the complexity to eventually be reduced since the old tags > could gradually be replaced with new ones (or there could be a bulk > search/replace, but I know some people are opposed to this). As far as I can see the choice is either to make the renderers or the editors work hard :-) Unfortunately the only centralised location in the current system is the database and I suspect most people will not be happy with the DB changing the data any more than mass search and replace. -- Brian _______________________________________________ talk mailing list [email protected] http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
