Am 08.03.2011 14:39, schrieb Martijn van Exel:
Hi Peter,

On 3/8/2011 1:03 PM, Peter Körner wrote:
Am 08.03.2011 12:47, schrieb Martijn van Exel:
Do you mean to say there is a history .jar in that build? I don't see
one. Or do you mean that I can use the history plugin with that build?
You can use the history jar you build during the last days with this
version of osmosis.


So do I just copy the osmosis-history.jar to the 0.37 osmosis? Does it
go into lib/default?

I think so but I'm not sure.

This is done using the HistoryNodeStore interface. It's only
implementation ExampleHistoryNodeStore uses two instances of
java.util.Map to store the nodes. This is not efficient enough to run
with larger datasets but it's well tested and good enough for developing.

Is it possible to mimic osm2pgsql's --slim behaviour, create temporary
tables in postgres to hold all the nodes and work from those instead of
memory?

I don't think it's really necessary to create another set of tables. The nodes-table that is imported before the first <way>-Tag occurs should be sufficient.

The process would be like that:

import all <node>-Tags, when the first <way>-Tag occurs, create the indexes and commit the transaction. Then start importing the <way>-Tags. Use the alredy finished node-Table with an index on the timestamp-column to fetch the node-version and -coordinates matching a way-version and build the way-geom as well as the way-nodes-table (with version) from it.

A quick look shows that the linestring-builder should be in a usable
state despite the storage problems. The last thing I was working on was
the minor version builder, that aims to create a "half version" of a way
each time one of its nodes got modified. This is somehow experimental.

Peter

_______________________________________________
osmosis-dev mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/osmosis-dev

Reply via email to