0> In article <20090427055113.GA14867@x60s>, 0> Marko Mäkelä <URL:mailto:marko.makela@iki.fi> ("Marko") wrote: Marko> 0x2a0a is restaurant/pizza. There is no Garmin code for Marko> cuisine=kebab, as far as I know. A few restaurants were Marko> labelled pizza;kebab around here. That is why I added this Marko> label. Yes, that makes sense (at least for the short term). Marko> What did you think about my idea of introducing a partial * match Marko> and a "split" operator? In this case, it would allow us to write Marko> Marko> amenity=restaurant & cuisine=pizza;* [0x2a0a resolution 20] Marko> Marko> so that cuisine=pizza;fish&chips would be mapped to 0x2a0a as Marko> well. Marko> Marko> The "split" operator would be needed in other cases, such as Marko> amenity=fuel;post_office, like this: Marko> Marko> amenity=*;post_office { split amenity=*, amenity=post_office } Marko> Marko> I can try to produce a patch for this, if there is interest. I think that the long-term solution perhaps requires more than that (and perhaps the Wiki is the right place to record some ideas). There are two cases that seem important to me, both demonstrated in this example: /-------- | shop=supermarket, amenity=atm;toilet \-------- In this case, we really ought to split the amenity value so that (logically) it's /-------- | shop=supermarket, amenity=atm, amenity=toilet \-------- and then produce POIs for all three matches. Perhaps we need some way to flag a rule as non-final - or look at the rule grammar and perhaps consider a nested list structure. This latter may appeal less to those without a Lisp background... Another example I often see - quite often a river is also an administrative boundary. Only one match is rendered to the map (just now I forget which one).