[mkgmap-dev] [PATCH V2] stop/continue scheme extended to style-rules without conversion
From Marko Mäkelä marko.makela at iki.fi on Tue Sep 1 20:37:21 BST 2009
On Tue, Sep 01, 2009 at 08:14:43PM +0100, Steve Ratcliffe wrote: > > Hi > > As an aside, I always planned to have lists of values which might > be useful in this case. Eg. the following > > > #set mkgmap_surface values to either paved or unpaved > > highway=*& surface=asphalt {set mkgmap_surface=paved ... > > highway=*& surface=cobblestone {set mkgmap_surface=paved ... > > highway=*& surface=concrete {set mkgmap_surface=paved ... > > could be represented by > > highway=* & surface=(asphalt, cobblestone, concrete, ...) {set > mkgmap_surface=paved > > (or with the keyword 'in' instead of = perhaps) > > does that sound useful? It would shorten some rules, such as this rule from my patch for bus/railway/tram stop names: (highway=bus_stop | railway=tram_stop | railway=halt | railway=station) & (shelter=yes | covered=yes) { name '${name|def:} ${ref|def:}+${operator|def:}'; } If you allowed the same syntax for keys, this rule would shorten to (highway=bus_stop | railway={tram_stop,halt,station}) & {shelter,covered}=yes Above, I used the {,} syntax that is familiar from tcsh and bash. The (,) or (|) syntax could be easier to implement in the grammar. Marko
- Previous message: [mkgmap-dev] [PATCH V2] stop/continue scheme extended to style-rules without conversion
- Next message: [mkgmap-dev] [PATCH V2] stop/continue scheme extended to style-rules without conversion
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the mkgmap-dev mailing list