On Mon, May 12, 2008 at 7:57 PM, Steve Hill <[EMAIL PROTECTED]> wrote: > Brian Quinion wrote: > >> The only problems I can see is that because it >> is centralised it is somewhat out of user control - so maybe it should >> make sense to pull the list of presets from a wiki page (once a day?) >> and there would be a small amount of server side load to implement it. > > That would certainly be do-able. People do need to be aware that > exactly what a preset tag sets can change without notice as the wiki is > updated, and that the changes will only affect new uploads though.
You're not really thinking about this in the right way. There's very little point in inserting a filter on API uploads to implement some, by definition, one-way mapping, working off a hacked wiki-scraping. Inevitably that leads to data-loss. The filter should be applied in the other direction, on reads, and at the choice of the consumer. > >> I think some sort of quick marco language would be a bonus for all the >> editors esp. if they shared a standard format for defining them, >> although at that point I wonder if an api change is needed - >> downloading a formatted page from the wiki might be as easy esp. if it >> was cached by the editor. > > That could be quite cool. One thing that would be really useful is for > the editor to tell me what options could be set for an object, and what > their defaults are. I.e. when I set a way to "highway=tertiary" it can > tell me that I can set a name, ref, access restrictions, etc. Maybe > ordered by the popularity of the various tags and with tags that are > semi-mandatory (such as the name of a residential road) in bold. All > that data can be pulled from wiki pages and tagwatch. Sadly my Java > skills are nonexistent. :( Much more along the right lines, but seriously guys, web page scraping? If you do this thing, please do it properly. Dave _______________________________________________ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
