[OSM-talk] Re: osm-filter.pl observations

Wed Aug 9 15:12:25 BST 2006

On Wednesday 09 August 2006 15:15, you wrote:
> Joerg, I have made some study of osm-filter.pl. I have comments about
> the straight line filter (reduce_filter), allow and deny waypoints, and
> using osm.txt.

Thanks 

> Overall I think the effect of the osm-filter.pl script is great. Once I
> figured out how to use it the results are impressive, in terms of
> eliminating certain types of error and removing redundant points from my
> track data.

Thanks for your patience :-)

> Straight line filtering (--use_reduce_filter)
> *********************************************
>
> osm-filter.pl -h and -man do not mention --use_reduce_filter.  For
> several days I thought the only way to get straight line filtering was
> --filter-all, until I found this in the source.  Once found I was very
> happy with the straight line filtering.

Just fixed

> One usage error I initially made was in filtering data I collected on a
> dual carriageway. I had two gpx files, one for each direction. If I ran
> both files into osm-filter.pl at once, it thinks there is only one road.
> If I run the files separately I get two very nice well simplified roads,
> as needed, 

We/I should think about this again. Maybe I have an Idea how to solve this.

> although they do not get the adjacent nodes as suggested in 
> the OSM style guide.

This is probably much more difficult. But as time comes, maybe I have an idea.

> Waypoints (--limit-area)
> ************************
>
> osm-filter.pl -h and -man say filter.deny and filter.allo are the terms
> to use in ways.txt, but the code (line 1212) seems to use filter.allow.
>
> I have defined two filter waypoints in ~/.gpsdrive/way.txt.  When file
> 00_filter_areas.gpx is generated, the filter.allow circle has a halo of
> points every 10 degrees, on the outside. The filter.deny circle has a
> halo of points every 10 degrees, on the inside. Are those halo's
> intentional?

Yes, this way you can destinguish between deny and allow areas. I normally 
look at then with "show-lines" on. The lines describe the _deny_ area which 
is either outside or inside the circle.

> I find that a waypoint deny filter only works if I also have an
> encompassing waypoint allow filter, as a way.txt entry.  Basically in
> order to deny, it seems I first must explicitly allow.  So I have an
> allow filter with a 50000 radius, and a deny filter with a 1000 metre
> radius embedded within the allow filter. Am I missing something?

The default area-filter rule is deny. And the filtering is done in the order 
the areas are found in the File(~/.gpsdrive/way.txt first then 
~/josm/filter.xml). So the last filter should be an allow all.
 all 0.0 0.0 allow 0 0 0 40000000

> As a separate issue, if I uncomment the "World" allow block, in
> areas_allowed_squares, this seems to override the waypoint filters
> entirely and my waypoint deny filter no longer operates.

This is because the allow world filter in this case was(change just comitting) 
added before every other area was loaded.

> Can I suggest that osm-filter.pl --filter-all not just exit in the case
> that osm.txt is not found, but instead writes out the option list that
> is next best, 

It now writes a comment why it stops and how to resolve it.

> such as --split-tracks --filter_duplicate_tracepoints 
> --use_reduce_filter --limit-area. Is there a reason that --filter-all
> does not include --limit-area?

Yes, the reason was that I sometimes wanted it with and sometimes without 
filters ;-) I think normally (later osm-filter Version) using filter-all 
should in the end only have the segments not already in osm. So it might be 
ok so. But if desired by more people we can change this.

> osm.txt (--check_against_osm)
> *****************************
>
> I found it fairly straightforward to download just my area with JOSM,
> and then convert that to osm.txt, as you described.  I did not use the
> create.sh method, as this other method makes it possible to keep my own
> osm.txt up to date, after I commit my edits. The steps I used are:

....

> Having got all that set up, --filter-all became usable. The filtering
> against existing segments seems good too.

I was thinking about downloading or getting imput for this feature from 
an .osm file/.osm-download directly. But for this to programm i wanted to 
wait for something like a local cache server to be programmed. Maybe I do 
write a direct osm-file-import in the near futore. So this would be something 
like --osm=file:saved-file-from-josm.osm. Shouldn't be too hard to code, 
sonce the parser already exists inside osm-check, OSM.pm(gpsdrive) and ...

-- 
Jörg (Germany, Munich)

http://www.ostertag.name/
TeamSpeak2: ts2.ostertag.name, user: tweety, Channel: "GPS Drive"
irc://irc.oftc.net/#osm