[Rebuild] Another issue to consider: Osmosis replication

Simon Poole simon at poole.ch
Thu Feb 16 20:49:10 GMT 2012


I suppose you could make the case that it is at least not an issue with
anybody syncing with osm2pgsql, since it doesn't actually update (AFAIK)
the "objects" in the database. It deletes the entries in question and
inserts new ones. Since everything tainted will either be completely
deleted or be replaced with a new version I doubt that it is any more a
derived work than the original DB.

Don't ask me what will happen when a diff (or a series of diffs)
actually delete and reinsert something like 8% of the database though.

I did raise the question once in the LWG I believe and the feeling then
was that sites would have to reimport (however that was when we were
contemplating technically complex transitions).

Simon



Am 20:59, schrieb Frederik Ramm:
> Hi,
>
> (CC'ing this to Brett Henderson, Osmosis inventor+maintainer)
>
>    most of you will be familiar with the standard way of running one's
> own replicated OSM database - all based on Osmosis' --rri task which
> automatically loads the hourly or minutely diffs since it was last run
> and does with them whatever you ask it to.
>
> I've asked Grant for the figures today, and according to the access
> logs there seem to be approximately 150 replicated instances of OSM
> "out there" - the majority of them, one would assume, for rendering,
> but some do other things - for example, Matt Amos runs his "OWL"
> database off of such diffs, or MapQuest's Nominatim will likely do the
> same.
>
> Many of these databases run on auto pilot - they just have Osmosis
> polling for new stuff all the time and if our server hands out
> something then they'll process it.
>
> Now what happens after we change the license and boot up our servers?
>
> Will we produce one gigantic "diff" that encapsulates all the changes
> we had to make to get from the last CC-BY-SA version to the first ODbL
> version of our database, so that these users can simply continue to
> gobble up our diffs and they will magically be ODbL after the switch?
>
> Or do we tell them: This is all too complicated, you will have to kill
> your old databae and do a fresh import if you want to be on the ODbL
> train?
>
> Is it even possible, legally, that there is someone out there who has
> our current database (which is licensed CC-BY-SA only), and we provide
> them with a diff that deletes 5% of their objects and modifies anohter
> 5%, and after that their database has magically become ODbL?
>
> If this isn't possible or feasible, then some of them will face quite
> a bit of work - someone running a world-wide nominatim would have to
> schedule about two weeks of data import time after the license change
> during which they would have to serve old data. Also, if sticking to
> the current mode of operations is not an option, then maybe we need to
> rename the download directories of everything so that we can make sure
> that there's not a CC-BY-SA database somewhere updating itself on auto
> pilot with new ODbL diffs, creating all sorts of trouble for everyone
>
> Bye
> Frederik
>





More information about the Rebuild mailing list