Hi,
On 7 September 2012 08:26, Komяpa m...@komzpa.net wrote:
Augmented diffs is one of the most awaited features for me, thanks for
implementing :3
It makes possible to eliminate the need for slim tables in osm2pgsql
database.
It doesn't seem that this was specifically the purpose of
Hi
Wouldn't it be simpler to augment all changed elements with finished
WKT-Descriptions? It would mean even less work for Clients and smaller
Extracts, though it would not help clients needing topology (ie routing).
Peter
Am 27.08.2012 20:14, schrieb Roland Olbricht:
Dear all,
Overpass
On Monday 10 September 2012, Peter Körner wrote:
Hi
Wouldn't it be simpler to augment all changed elements with finished
WKT-Descriptions? It would mean even less work for Clients and smaller
Extracts, though it would not help clients needing topology (ie routing).
This makes some massive
Am 10.09.2012 12:10, schrieb Robert Scott:
On Monday 10 September 2012, Peter Körner wrote:
Hi
Wouldn't it be simpler to augment all changed elements with finished
WKT-Descriptions? It would mean even less work for Clients and smaller
Extracts, though it would not help clients needing topology
Hello,
However, these diffs address developer, not end users, because there is no
software yet that can process these diffs. Therefore, I would be happy for
comments and suggestions on this matter that arise when writing such a
software. If there are good reasons to change the format, I'll
Hello,
thanks for the idea of augmented diffs!
It's advantageous to have related data in the same file.
However I am not sure if it is wise to reinvent the wheel. Two questions /
suggestions:
1. Tagging
Why did you not use solely the existing XML tags create, modify and
delete?
That data an
1. Tagging
Why did you not use solely the existing XML tags create, modify and
delete?
Because they don't properly describe what's happening. The core idea of the
augmented diffs is to include some unchanged but related elements. This
doesn't happen in diffs. Thus, the new category keep is
Hi Roland,
sorry, I did not want to just criticize the idea of augmented diffs, I merely
wanted to understand the reasons why the tags have been defined in the way they
are.
1. Tagging
Altogether, please note: the augmented diffs aren't an extension of the
normal
diffs and even less
Dear all,
One complete different thing that would also been very interesting to
have in even more augmented diffs is the previous version of an
object.
This would allow to do analysis on edits without the need of a
database... and also apply diff backwards.
Of course, the side effect will
2012/8/30 Roland Olbricht roland.olbri...@gmx.de:
Dear all,
One complete different thing that would also been very interesting to
have in even more augmented diffs is the previous version of an
object.
This would allow to do analysis on edits without the need of a
database... and also
On Tue, Aug 28, 2012 at 12:28 PM, Roland Olbricht
roland.olbri...@gmx.de wrote:
Similarly osmChange or osc files are already maybe you should call
2. The sections are a bit confusing in that the order is very
important. That makes parsing a bit more difficult than it might need
to be if
BRAVO !
I started a talk on the same idea on the french osm-dev-fr list.
About relations, the need to reconstruct their geometry is depending
on their final use where ways geometry are mostly needed and I feel
they are more resource hungry.
A few questions...
When the change on a node or way
On Mon, Aug 27, 2012 at 2:14 PM, Roland Olbricht roland.olbri...@gmx.de wrote:
The details are documented in the wiki
http://wiki.openstreetmap.org/wiki/Overpass_API/Augmented_Diffs
The docs you list are a bit confusing, so I went to the XML itself,
and that has some issues, mainly
A few questions...
When the change on a node or way is just a tag change and does not
involve geometry change, are the diff still providing all linked
nodes/ways ?
Yes, they do.
Thank you for pointing this out.
I think it would be resonable to not include a way when the only change is a
The docs you list are a bit confusing, so I went to the XML itself,
and that has some issues, mainly name/document related.
1. The osm tag name is already used for a format, so I suggest not using
it.
Similarly osmChange or osc files are already maybe you should call
this something else?
The idea behind my questions is to differentiate as much as possible
tag edits and geometry edits.
The idea is that updating tags in a database is a straightforward job
compared to updating geometries that usually needs much more
resources.
Any improvement in the database update process that can
Dear all,
Overpass API now offers Augmented Minute Diffs. The idea goes back to a talk
of Matt Amos at SOTM 2010. These diffs allow e.g. to keep a geographically
limited database extract up to date.
The details are documented in the wiki
Hi Roland,
Overpass API now offers Augmented Minute Diffs. The idea goes back to a
talk
of Matt Amos at SOTM 2010. These diffs allow e.g. to keep a
geographically
limited database extract up to date.
This looks really good and may be useful for a project that I'm working
on.
Quick
Hi Paweł,
This looks really good and may be useful for a project that I'm working
on.
Quick question - have you considered adding relation members data to
these diffs?
Yes, I have considered it. The reason not to do this so far are the really
huge relations. Examples for these are
19 matches
Mail list logo
