-
Notifications
You must be signed in to change notification settings - Fork 922
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ERROR: column "nearby" of relation "users" #2449
Comments
This is a bug in omosis, or rather osmosis needs updating to reflect recent schema changes - it is trying to fill in the |
Ouch, that's a bit of a headache, given that osmosis is unmaintained and any new release is unlikely. Arguably osmosis shouldn't have been trying to fill in that column anyway, since it had a default and so the insert could have ignored it. I think a workaround would be for the user to re-add the column, run the osmosis command, and then drop the column again. Alternatively, if you can compile osmosis from source, then edit the relevant line in the code first. Does anyone know of any other mechanism for loading an osm file into the database? I imagine it's a fairly common task for small deployments. |
This is definitely a part of the OSM ecosystem that I have struggled to understand. It seems there are a whole suite of tools for taking OSM data which have already been extracted from the database defined in this repository and importing into other tools, but I haven't come across anything but
Just to clarify, is there another tool you'd recommend for "large deployments" or am I reading too much into you comment? @gravitystorm if getting |
Well loading data into an API database is probably not a common requirement - it's certainly not something we ever need to do for example so we have no need ourselves to create tools for it. It's As to |
This is because there is no real use case that would require this (and actually reloading original OSM data is not something you would want to try except in a dire emergency), you are far better off with normal backups.
imposm does something completely different (it's an alternative to osm2pgsql for rendering databases). Dropping osmosis is a policy decision, explicit or not, it would be a small thing to pay somebody for further maintenance of osmosis until there is a full replacement. osmium is likely going to be taking over some of the functionality, but in the end suffers from the same issues (bus factor one). |
Sorry, I meant to distinguish other deployments from the main OSMF instance - afaik all secondary deployments are "smaller" than OSMF. For the OSMF instance, there's never going to be a need to load a blank database with fresh data. For many other instances, again people might start from an empty database, but they might also start by loading some data.
There's a real use case here, albeit a small one, which is organisations loading extracts in order to do things like exploring planning applications, or other mapping that's not being done in the OSMF instance like subjective or confidential humanitarian work. It's something that I've been contracted to work on in the past. But it's not a huge production use-case. However, it's also a reasonable development use-case, since building the UI on an empty database is tedious for developers - particularly things like paging navigation on the relations browse pages. If you can't load an extract, you have to do a lot of fake mapping via id or JOSM to get 10,000 relations into your local db. Loading existing data, like an extract, makes more sense here.
As @tomhughes says, if not |
I came here because this issue popped up here again: https://help.openstreetmap.org/questions/72166/populating-database-on-rails-port-osmosis-fails Given that we have pending fixes for osmosis production issues since quite some time (openstreetmap/osmosis#51) I have zero hope for this tool. It should be completely removed from the ecosystem. taking over any kind of maintenance looks like it’s not going to happen at all. |
It is already largely removed from production as far as the core project is concerned. The only thing that still uses it is the diff generation I believe. There is ongoing work to redo the diff generation to work with newer versions of Postgres and that should also remove osmosis from the equation. |
Right, @zerebubuth mentioned that some new diff replication should be available real soon now, although I haven’t really found out where this is happening or who’s working on it. Seems to be some kind of undercover operation. |
@joto is working on it... |
Came here because I'm stuck on the same issue. For anyone looking for a temporary workaround to import you can create a migration file and add class AddNearbyToUsers < ActiveRecord::Migration[6.0]
def change
add_column "users", "nearby", :integer, :default => 50
end
end |
Agree. Although osmosis is somewhat slow, it used to be a valuable option to set up an OSM clone based on some country extract. In particular, creating identical user accounts (with fake email addresses) and object ids like on osm.org is really helpful. Hopefully we can somehow migrate this osmosis feature to a new tool, too. |
There is a solution for this "Unable to insert user with id -1 into the database" issue? |
As of version 0.47.1, Osmosis now correctly omits the |
Was trying to setup API DB using regional extract (and running into import issues such as https://lists.openstreetmap.org/pipermail/osmosis-dev/2011-March/000949.html). @caduguedess's issue might be a case of not having the schema in place - the steps up till
It is unfortunate that a lot of guides on OSM data imports (even the official docs https://github.com/openstreetmap/openstreetmap-website/blob/master/CONFIGURE.md) still reference the use of osmosis (for lack of a better alternative), despite caveats and known issues etc. This poses a challenge for those hoping to leverage OSM dev stack and understand its actual workings. |
Unfortunately, it seems that loading an extract into a Rails-schema database isn't on a happy path because it isn't something anyone does very frequently. On the downside, this means you're likely to encounter problems, but on the upside you're a pioneer! 😉 I'm not aware of any better tool than Osmosis to do this, sorry (even taking into account the high likelihood of encountering further problems). The first item of advice in the mailing list post you referenced is the one I would take if I wanted to load an extract: drop the table constraint, load the data, then repair the data so that the Hope that helps! |
@zerebubuth thanks for your response, I will try that since there is nothing better. It is probably the same problem as explained by Simon here. I also found the related discussion at #2543 which explains why there is no little/no support on seeding the API DB using data exports (as it is not required for the official workflows including testing). Even if that is the case, the documentation should be more explicit about this so that known issues can be made clear to new users. |
I’ll explore ways that Osmosis can handle this. |
Im pretty new to this so I am not sure if this is a new bug or not. I am following the install guide. I saw this
#2417
and thought it might be related to the change.
when I do an import using the following command:
/osmosis/bin/osmosis
--read-pbf /data.osm.pbf
--bounding-polygon file="/data.poly"
--write-apidb host="localhost"
dbType="postgresql" database="openstreetmap"
user="openstreetmap" password="myPass" validateSchemaVersion="no"
I get the following error:
The text was updated successfully, but these errors were encountered: