[OSM-dev] Osmosis patch for filtering ways
brett at bretth.com
Thu Mar 27 12:06:52 GMT 2008
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
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.
Karl Newman wrote:
> On Wed, Mar 26, 2008 at 8:47 AM, Frederik Ramm <frederik at remote.org
> <mailto:frederik at remote.org>> wrote:
> > 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.
> 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.
> dev mailing list
> dev at openstreetmap.org
More information about the dev