[OSM-dev] bringing up rails port with empty user table

Brian Cavagnolo bcavagnolo at gmail.com
Sat Jan 26 22:13:34 GMT 2013


I'm following the instructions on the wiki for bringing up the rails port:


I want to bring it up with an empty user table, and I've tried both
the options mentioned.  The first is using the --drop-author option to
osmfilter before importing.  I tried this method using commands
something like this:

$ osmosis --rb ~/src/osmsf/planet.pbf --bp file=berkeley.poly
clipIncompleteEntities=true --wx file=tmp.osm
$ osmfilter tmp.osm --drop-author > no-author.osm
$ osmosis --rx file=no-author.osm --write-apidb-0.6
populateCurrentTables=yes validateSchemaVersion=no

(auth info omitted for clarity).  This fails with:

SEVERE: Thread for task 1-rx failed
org.openstreetmap.osmosis.core.OsmosisRuntimeException: The entity
timestamp attribute is missing.
        at org.openstreetmap.osmosis.core.domain.common.UnparsedTimestampContainer.<init>(UnparsedTimestampContainer.java:34)
        at org.openstreetmap.osmosis.xml.common.BaseElementProcessor.createTimestampContainer(BaseElementProcessor.java:90)

I'm not sure if --drop-author must strip the timestamp, or if osmosis
can be told to tolerate this.  Anyway, I tried the other method of
using the omitmetadata=true option to osmosis' --wx task using
commands like this:

$ osmosis --rb ~/src/osmsf/planet.pbf --bp file=berkeley.poly
clipIncompleteEntities=true --wx file=tmp.osm
$ osmosis --rx tmp.osm --wb file=tmp.pbf omitmetadata=true
$ osmosis --rb file=tmp.pbf --write-apidb-0.6
populateCurrentTables=yes validateSchemaVersion=no

This worked, but then when I bring up the rails port and attempt to
edit a feature, I get:

"A server error occurred. Do you want to retry? (The server said: Version
mismatch: Provided 4294967295, server had: -1 of Node 286080990)"

Of course  4294967295 = 0xffffffff = -1.  So the question is how
should I fix this?  I figured I'd just set all the version numbers in
nodes, ways, relations, and their current_* counterparts to 1.  But
this causes an integrity problem:

# update nodes set version=1;
ERROR:  update or delete on table "nodes" violates foreign key
constraint "node_tags_id_fkey" on table "node_tags"
DETAIL:  Key (node_id, version)=(34351117, -1) is still referenced
from table "node_tags".

Any recommendations on either of these two approaches?


More information about the dev mailing list