[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