<div class="gmail_quote">On Thu, Nov 19, 2009 at 11:27 PM, Andrew Byrd <span dir="ltr"><<a href="mailto:andrew@fastmail.net">andrew@fastmail.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">On 19 Nov 2009, at 07:30, Brett Henderson wrote:<br>
><br>
> Can you please update the wiki detailed usage page to reflect the<br>
> new task?<br>
> <a href="http://wiki.openstreetmap.org/wiki/Osmosis/DetailedUsage" target="_blank">http://wiki.openstreetmap.org/wiki/Osmosis/DetailedUsage</a><br>
<br>
</div>Done. I noted that it is currently only in svn.<br></blockquote><div><br>Great, thanks.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

<div class="im"><br>
> On this note, if anybody is keen Osmosis could really do with<br>
> somebody to take on creating a consistent set of filtering tasks for<br>
> all entity types (at a minimum it appears that relations are missing<br>
> from the existing set of tasks).  I'm not sure what the requirements<br>
> would be and I don't do any filtering myself so don't have much<br>
> experience with it.  I think all existing tasks have a bug at the<br>
> moment where they don't handle ',' characters in the key names which<br>
> probably should also be fixed.<br>
<br>
</div>It should be rather simple to extend the existing filter set to<br>
relations. I have little experience with OSM/Osmosis myself, yet the<br>
task architecture was easy to understand. One thing needs to be<br>
clarified, though: should entities belonging to entity types not being<br>
filtered be passed through or thrown away? Currently, the node filters<br>
pass only nodes through, while the way filters pass non-way entities<br>
through unchanged. I see the practical reason for this, but it's not<br>
consistent. Maybe there should be an option to choose between behaviors.<br></blockquote><div><br>I think filters should behave consistently rather than having each entity type treated differently for a particular use case convenience.  Usually I try to avoid changing existing behaviour, but only if there's a reasonable alternative.  If the current filters are inconsistent I think we should change them.  If we are going to break existing behaviour though I think we should attempt to make all the breaking changes at once rather than dribbling them in over a longer period.<br>
<br>But I didn't write the original tasks and haven't used them so I'm not well placed to decide how they should work.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

<br>
According to the wiki, a tag is a "Key-Value pair of Unicode strings<br>
of up to 255 characters (full Unicode characters, not bytes)."  There<br>
is no mention of excluded list separator characters, so if it was<br>
changed from comma to something else, there would still be a bug and<br>
it would cause havoc with people used to using commas.  One reasonable<br>
solution is some kind of escape character (backslash?) for non-<br>
splitting commas that are in the key name.<br></blockquote><div><br>Yep, I think we'd have to escape the separating character if it is included in the key.  Given the rarity of something like a ',' in a tag name, I don't think there's an issue with requiring users to escape it when it does occur.<br>
 </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
It would also be helpful to have a switch to invert filter logic from<br>
accept to remove, e.g. so you can accept everything with a highway tag<br>
then remove everything that has the highway=motorway value. This would<br>
make for a cleaner operation (and command line) than trying to make an<br>
exhaustive list of every key-value you want to keep.<br>
<br>
It would be nice to have comments from users and developers about how<br>
the filter set should be designed, and once that's clear I think the<br>
new tasks would show up, since they are useful to a lot of people, but<br>
not major undertakings.<br></blockquote><div><br>I'm gonna take a back seat on this one :-)  If you have some time to gather some requirements, tidy up the existing tasks, and add new features then go for it.<br><br>
Don't feel the need to get full consensus before you do something.  Obviously it's a good idea to gather ideas, but feel free to come up with what you think works well, implement it, and then get feedback.<br><br>
Brett<br></div></div><br>