[OSM-dev] area filtering on change streams?

Brian Cavagnolo bcavagnolo at gmail.com
Tue Jan 22 20:12:05 GMT 2013


On Mon, Jan 21, 2013 at 12:13 AM, Peter Wendorff
<wendorff at uni-paderborn.de> wrote:
> Am 21.01.2013 08:00, schrieb Frederik Ramm:
>
>> Hi,
>>
>> On 01/21/13 07:54, Brian Cavagnolo wrote:
>>>
>>> I'm kinda hooked on the appeal of only working with the changeset.  I
>>> poked around the osmosis source and learned a bit about the change
>>> format.  It looks like changes could be filtered using the same code
>>> used for the polygon and bounding box filters.  Does this sound
>>> intuitively correct?
>>
>>
>> No.
>>
>> The fact that changesets cannot be filtered by region is not a software
>> limitation, it is a design limitation.
>>
>> Changes can occur in nodes, ways, or relations; but only nodes have a
>> geometry given in the .osc file. For example, an .osc file might contain the
>> information "way #17 has been changed from highway=residential to
>> highway=unclassified" but you won't know if that is relevant to you because
>> the nodes of that way are not included in the changeset (unless by chance
>> they have been modified at the same time).
>
> While in fact you would know that (out of the fact, that the way already is
> in your database), the other way around it's a problem:
> If a node changes it's location towards your area of interest, that has been
> outside before, every way connected to this node is of interest for you, but
> these ways are neither in your database (outside your area before) nor in
> the change stream (as the way object itself didn't change).

I see.  Thanks for the explanation.  Here's what I came up with as my
final solution.  Apply all changes in the change set:

$ osmosis --rri --simc --wpc authFile=mydb.auth

..then somehow trim the db down.  Stephan's method above achieves this
for a bounding box using SQL directly.  But I want a bounding polygon,
and I'd rather use osmosis.  For the record, here's what I came up
with:

$ osmosis --rx empty.osm --rp authFile=mydb.auth --dd --bp
file=area-inv.poly --dc --wpc authFile=mydb.auth

empty.osm looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<osm version="0.6" generator="CGImap 0.0.2">
</osm>

...and area-inv.poly is the polygon that I originally used to clip the
planet file.  I achieved this by prepending a polygon with the whole
earth to the top of the poly file and inverting the rest:

area-inv
1
   -1.800000E+02   1.800000E+02
    1.800000E+02   1.800000E+02
    1.800000E+02  -1.800000E+02
   -1.800000E+02  -1.800000E+02
END
!2
   -1.230011E+02   3.777205E+01
   -1.229975E+02   3.777078E+01
<snip>

This isn't exactly right because entities on the border will fall into
both the regular and inverted poly files.  I don't think this will
matter for my application.  Just something I noticed.  Also, I noticed
that the number of nodes, ways, and relations changes a bit more from
day to day than I expect.  But the extent of the nodes and ways in the
db seems about right.  I think this approach will work nicely, but if
somebody can spot any problems with this approach, I'd be grateful.

Thanks for your help.

Ciao,
Brian

>> If you really want to pursue this further, read up on "augmented diffs"
>> which are reference-complete and would therefore allow such filtering:
>> http://wiki.openstreetmap.org/wiki/Overpass_API/Augmented_Diffs
>>
>> Bye
>> Frederik
>>
>
>
> _______________________________________________
> dev mailing list
> dev at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/dev



More information about the dev mailing list