Hi Guys, If a patch for new functionality conforms to these conditions: * Isolated addition not impacting existing tasks. * No changes to pipeline design. * No additional library dependencies. * Not highly specialised to one persons need.
Then I'm unlikely to have any issues with it. Not meeting above conditions is certainly not bad, but I should try to review it first. The real issue is that I'm not getting much time to review code (or write code for that matter) so I'll have to trust everybody to do the right thing. One final thing is that there are a large number of changes in SVN that have been made since the 0.24 release. I need to get some time to finalise and test my latest postgres based dataset bounding box functionality and hopefully can make the new release. I'm wondering whether I should just create a new release anyway and finalise the new dataset stuff later. Brett Karl Newman wrote: > On Wed, Mar 26, 2008 at 8:47 AM, Frederik Ramm <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > Hi, > > > I have in the works another method to filter ways based on tag > > content. Cristoph's method is straightforward and simple and can be > > completely contained on the command line, which is nice. Mine is > > file-based because I plan to use the same file to control how > > tiling works and also how routable Garmin GPS maps are generated. > > With this method you could have a single rule file which could be > > used for all these things--filtering to select the elements you > > want, slicing an OSM file into tiles, then creating routable maps > > from those tiles. > > Maybe it would be possible to use your more complex filter system > internally, but still offer an alternative fully command-line based > entry with limited functionality. So that people would not be forced > to create a filter file jsut because they want railroads only. > > Bye > Frederik > > > Yes, that's what I was suggesting, to keep Christoph's easy method > available. I was just mentioning that I had another implementation, in > order for BrettH to be able to consider any necessary architectural > changes to support both methods. > > Karl > ------------------------------------------------------------------------ > > _______________________________________________ > dev mailing list > [email protected] > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev > _______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
