Am 26.08.2010 00:19, schrieb Peter Körner:
The first snapshot is out.
And here's the next status update:
The history plugin is now able to calculate minor way versions, either
by using the --write-pgsql-history-dump task with
enableMinorVersionBuilder="true" or by using the --write-pgsql-history
task with an appropriate schema
(import pgsql_simple_schema_0.6_history_minor_version.sql).
In the current, simple implementation every node change triggers a minor
way, for example:
create node 1v1, 2v1
create way 100v1 (consisting of 1v1 and 2v1)
move node 1v2
implicit minor way 100v1/1 is generated (consisting of 1v2 and 2v1)
There are some situations, where this behavior might not be intended,
like this:
create node 1v1, 2v1
create way 100v1 (consisting of 1v1 and 2v1)
move node 1v2
implicit minor way 100v1/1 is generated (consisting of 1v2 and 2v1)
move node 2v2
implicit minor way 100v1/2 is generated (consisting of 1v2 and 2v2)
if the two node moves happened in one changeset, while somebody moved
the whole way, this simple algorithm will create an intermediate way
(100v1/1) where only one node has been moved, thus changing the geometry
of the way in another way then the original uploader was.
To handle such special cases I'd like to introduce different
implementation of something I'd call a MinorVersionAggregator. One might
want to condense all changes, made in a single Changeset into one minor
version (solving the problematic example above) or condense all changes
made within 5 seconds into one minor version. Another aggregation class
might condenses all changes made by one user into a single minor version.
There's another situation that can produce undesired results:
create node 1v1, 2v1
create way 100v1 (consisting of 1v1 and 2v1)
move node 1v2
implicit minor way 100v1/1 is generated (consisting of 1v2 and 2v1)
change tagging of way 100v2 (consisting of 1v1 and 2v1)
between the minor version 100v1/1 and the new real version 100v2 no
change in the geometry has taken place and if we only look at the way
geometry, the minor version 100v1/1 looks redundant to us.
I'm not sure how to handle this. Shoukld the minor way 100v1/1 be
generated or not? I think it should, because it would carry the meta
info of the uploader who changed the geometry of the way, but it would
result in two versions of the way having the same nodes in the same
versions as members. Does anyone think that it would need an extra
option to suppress such "redundant minor ways"?
Finally the NodeStore-Problem is still not solved. All my tests use the
example implementation with HashMaps. I was thinking about implementing
a DatabaseNodeStore, that would only work with the database task (not
the dump task), relying on the nodes-table being already imported.
For diff imports I'm going to implement a DualNodeStore, that takes
another node store as primary source and a DatabaseNodeStore as backup
store, thus allowing the tasks to read information of nodes already
imported.
Regarding Change-Files I'm also planning to implement
changefile-to-history an history-to-changefile actions. They would
require access to an existing database, too, but I didn't think too much
about that. Another task I thought about was read-historical-map task
that extracts a part of the map from the database as it was at a
specific timestamp. But that's just some idea, too.
Peter
_______________________________________________
osmosis-dev mailing list
osmosis-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/osmosis-dev
