[OSM-dev] Osmosis: Bounding polygon does not support change data as input?

[Andreas Kalsch]

Thank you for your help.
The fourth point means that in my planned application I am not going to 
use OSM database but just a subset of it - so I need kind of trigger 
which updates my application data from my local OSM database.

I have tried to do this the way I described, but it still does not work. 
I described it in another post this morning. Either ...

osmosis/bin/osmosis --read-xml-change data/osm/20080916-20080917.osc 
--apply-change --write-mysql host=localhost database=osm_de user=user 
password=xxx

and ...

osmosis/bin/osmosis --read-xml-change data/osm/20080916-20080917.osc 
--read-mysql host=localhost database=osm_de user=root password=qay 
--apply-change --write-mysql host=localhost database=osm_de user=user 
password=xxx

do not work. What is the right syntax?

--

Apropos: Do you know geonames? They use tab splitted dumps and you just 
call "LOAD DATA INFILE" in MySQL - pretty easy and very quick ;)

Brett Henderson schrieb:
> Andreas Kalsch wrote:
>> This is a clear fact, of course. But Osmosis could retrive the nodes 
>> from the database instead and try to find it out, like you described 
>> below.
>>>
>>> All is not lost however.
>>> The simple answer is just to import the diff for the entire world.  
>>> It's approximately 10MB of compressed data per day so the database 
>>> will only grow steadily.
>>> The slightly more complicated answer is to import the entire world 
>>> diffs but then run an additional query to delete data not inside the 
>>> bounding box.  This would only have to be run occasionally.
>> OK, so a solution could be:
>> - load planet diff
>> - apply it completely
>> - make copy of current database with only points within the polygon 
>> and delete the old database - every n days
>> - after that triggering changes to my application database which uses 
>> just a subset of the whole data, so that I use no data which is 
>> outlide the polygon
>>
>> This is a compromise that would work for me.
> I didn't understand your fourth point but otherwise that sounds okay.  
> I would have thought it would be quicker to delete the data outside 
> the polygon than to copy from and delete the old database though ...
>>>
>>> A more complicated solution (involving some coding) could be as 
>>> follows:
>>> Before applying a changeset, re-order the changeset to preserve 
>>> referential integrity.  Osmosis can do this already with the --sort 
>>> task.
>>> Only write nodes that are inside the bounding box and check to see 
>>> if each node already exists in the database.
>>> For every way write, check the nodes that should by this point 
>>> already exist in the database to see if the way is inside the 
>>> bounding box.
>>> For every relation write, check to see if any members already exist 
>>> in the database.
>> I am sure this would take very much time. Sorting a file is surely 
>> not a very quick task ;)
> Osmosis uses a file-based merge sort for all sorting operations.  It 
> would take a huge amount of time for a file the size of a planet but 
> sorting small changesets is fast.  Each daily changeset is approx 10MB 
> compressed.  I just tested it and it took approximately 30 seconds to 
> sort on the dev server so plenty fast enough.
> But thinking about it a bit more it's probably not necessary to sort 
> anyway.  Sorting is necessary if you wish to maintain referential 
> integrity but in this case we just need all new nodes to be written to 
> the database before the ways.  It will result in incomplete ways at 
> the boundary of the box but that is typical for most bounding tasks 
> anyway.
>
> Anyway, I'm sure this will come up more and more.  I'll take a look at 
> it one of these days but if anybody urgently requires it they might 
> have to code it themselves.
>
> Brett
>
>