Hi,
Brett Henderson wrote:
> There is a new (as yet undocumented) task in osmosis called
> --simplify-change which allows a full history diff to be collapsed into
> an older style delta diff.
In a scenario where you use --rri to retrieve a set of combined minute
diffs, and if you continue wi
Once again: Thanks for all your work on this!
After taking a stab at it myself I certainly have a new appreciation
for what you've done.
> The "history" diffs are in the process of being generated and are well
> through 2008 as we speak. These are effectively daily diffs but aren't
> getting dele
Hi All,
I thought I should give an update on recent Osmosis replication changes.
The existing "minute" diffs are irreparably broken. The timestamp approach
for extracting changes only works if a long delay is used. 1 hour is
probably a minimum and unacceptable for supposedly minute diffs.
The e
On Sat, Nov 14, 2009 at 5:50 AM, Maarten Deen wrote:
> I'm using osmosis 0.31.2 to insert some data (from XAPI) in a mysql
> database and
> I get the error
> Cannot add or update a child row: a foreign key constraint fails
> (`osm06/nodes`,
> CONSTRAINT `nodes_ibfk_1` FOREIGN KEY (`changeset_id`)
On Fri, Nov 20, 2009 at 11:15 AM, Andrew Byrd wrote:
>
> On 19 Nov 2009, at 23:11, Brett Henderson wrote:
>
>>
>> I think filters should behave consistently rather than having each entity
>> type treated differently for a particular use case convenience. Usually I
>> try to avoid changing existi
On Fri, Nov 20, 2009 at 11:00 AM, Andrew Byrd wrote:
>
> Ideally there would be no need for a separator character, because the
> same key could be specified several times for one filter. However,
> Osmosis stores task parameters in a hashmap, so each parameter can
> have only one value per task.
On 19 Nov 2009, at 23:11, Brett Henderson wrote:
>
> I think filters should behave consistently rather than having each
> entity type treated differently for a particular use case
> convenience. Usually I try to avoid changing existing behaviour,
> but only if there's a reasonable alternati
Hi Peter (and others),
I think you've got something there, grouping all possibilities
together in one or two tasks. The difference between node/way and key/
keyValue filtering in the code is minimal, and it might make sense to
put it all in one class. I had to reread your post before I caught
On Thu, Nov 19, 2009 at 11:27 PM, Andrew Byrd wrote:
> On 19 Nov 2009, at 07:30, Brett Henderson wrote:
> >
> > Can you please update the wiki detailed usage page to reflect the
> > new task?
> > http://wiki.openstreetmap.org/wiki/Osmosis/DetailedUsage
>
> Done. I noted that it is currently only
> should entities belonging to entity types not being
> filtered be passed through or thrown away?
This is how I'd like it from the user perspective
remove all nodes
osmosis \
--read-xml in.xml \
--exclude node \
--write-xml out.xml
keep only ways
osmosis \
--read-xml in
On 19 Nov 2009, at 07:30, Brett Henderson wrote:
>
> Can you please update the wiki detailed usage page to reflect the
> new task?
> http://wiki.openstreetmap.org/wiki/Osmosis/DetailedUsage
Done. I noted that it is currently only in svn.
> On this note, if anybody is keen Osmosis could really d
11 matches
Mail list logo
