[osmosis-dev] WayKeyFilter

[Andrew Byrd]

Hi Peter (and others),

I think you've got something there, grouping all possibilities  
together in one or two tasks. The difference between node/way and key/ 
keyValue filtering in the code is minimal, and it might make sense to  
put it all in one class. I had to reread your post before I caught the  
really nice bit: mapping the parameters directly to the tag keys. By  
making the entity type the default argument, the entire space of  
possible keys can be given as arguments... except those containing the  
= character. As Osmosis splits the arguments at the first occurrence  
of '=', this character would have to be represented by something else  
entirely.

Other characteristics of your filter syntax:

There are two tasks: --include and --exclude. Their default argument  
specifies which entity type is concerned, all other type pass through  
unaffected. I like this, except that the filter code for include and  
exclude will be almost identical, so it would make more sense to put  
it all in one  place. Include/exclude and entity type could be  
combined in the default argument (only 6 possibilities to enumerate.)

Ideally there would be no need for a separator character, because the  
same key could be specified several times for one filter. However,  
Osmosis stores task parameters in a hashmap, so each parameter can  
have only one value per task. This means that having the same one  
appear several times ( --tag-filter key=x key=y ... ), while it would  
be convenient and easily readable, is contrary to the design of  
Osmosis. Separator character seems unavoidable.

A wildcard character (probably *) can be given as either key or value,  
matching anything. This avoids needing different key and key-value  
lists, and clarifies the syntax at the expense of another reserved  
character.

A way-with-nodes default argument filters ways, then passes through  
only the nodes that go with it. This shortens the command line... but  
we lose some clarity about the process. To me it's reasonable to leave  
--used-node as a separate task. Since you must filter the ways before  
you know which nodes to keep, this task really does happen after the  
initial filtering, and someone might use it outside way filtering.

Taking all this into account:

The common thread is that we are filtering based on tags, so i'll call  
it a 'TagFilter'. It would have a default unnamed option:
[ accept | reject ]-[ nodes | ways | relations | all ]

If no key-value parameters are specified, tag-checking is disabled,  
i.e. the filter matches all tags.

The wildcard character, the '=' character, and the separator must be  
escaped somehow. We cannot use \= because Osmosis will still split the  
parameter on the '=' character. Maybe something like @ASTERISK @COMMA  
@EQUALS and a double @@ to really insist on a true at character.

I was thinking about complex expressions like tags=" highway.* AND NOT  
( boundary.administrative ) " but I think this is not worth the  
trouble and can be more cleanly achieved by chaining filters together.  
It might be nice to have a pass_other_entities parameter, which  
defaults to True but can be switched off.

Here are some possible command lines:

# all ways with key highway or key-value pair boundary.administrative
# except motorways, plus all the nodes that make them up
osmosis \
--read-xml in.xml \
--tag-filter accept-ways \
    highway=* \
    boundary=administrative \
--tag-filter reject-ways \
    highway=motorway \
--used-node \
--write-xml out.xml

# remove all nodes
osmosis \
--read-xml in.xml \
--tag-filter reject-nodes \
--write-xml out.xml

# keep only ways
osmosis \
--read-xml in.xml \
--tag-filter reject-nodes \
--tag-filter reject-relations \
--write-xml out.xml

# keep only ways and their nodes (thus removing all nodes not in a way):
osmosis \
--read-xml in.xml \
--tag-filter reject-relations \
--used-node \
--write-xml out.xml

# keep only countries and islands
osmosis \
--read-xml in.xml \
--tag-filter accept-node \
    place=country,island \
--write-xml out.xml

I like the way this looks, I think it's very readable and clear what's  
going on. Any thoughts?

-Andrew