NOTICE: is no longer in use from 1st March 2024. Please use the OpenStreetMap Community Forum

Dear community,

we currently are creating indoor maps for our university campus. Unfortunately we are not allowed to upload all this data to the official OSM servers, but we had to set up our own one. Since we can't use the official one, we made the database and the processes working with its data to work with negative osm ids.

The problem now is that JOSM behaves as following: When creating new elements these elements get negative ids. Once the just-saved file gets loaded, all negative ids within it will be replaced with new negative ids. That means there's no consistency of the same file thanks to JOSM.

So my question is: Is there a way to reserve / allocate "real" OSM-IDs for the created ways, relations and nodes without uploading the data itself.

I assume we could just upload a node/way/relation without containing useful information, but I'm frightened someone could remove due to its uselessness and the very same ID could be assigned to some other element.

And since our database data is not stativ but will be upgraded from time to time we cannot just chose any positive ID not yet included in the database because some day it might.

Any help is welcome! Thank you!

asked 12 Jan '14, 17:02

Henry%20Moews's gravatar image

Henry Moews
accept rate: 0%


Not a very good idea to work with negative IDs. Editing software all expect negatives to be NEW items without real IDs assigned yet.

(12 Jan '14, 21:22) MCPicoli

Sorry, but AFAIK there is no way to reserver/lock IDs without real payload.

If you start from an empty dataset, you might use your own (nonnegative) IDs and keep them in a local xml file. Another way would be to setup your own rails port server with own API etc. that keeps your stuff seperated from OSM DB, while allowing multiple users to edit this data.

I'm not an expert but I guess there might be legal problems if you mix OSM data with non free (as you aren't allowed to publish) informations on a dataset level.

There is also a small but nice existing indoor community at OSM :)

permanent link

answered 12 Jan '14, 18:20

iii's gravatar image

accept rate: 10%

Thanks for pointing out the legal problems. Indeed, we're working with these indoor definitions.

(12 Jan '14, 19:52) Henry Moews

Use positive IDs for your own data file, starting at 1. If you need to mix your data with data from OSM for some processing, use a small script to re-number your file to using IDs above the highest in OSM at that time.

permanent link

answered 12 Jan '14, 19:30

Frederik%20Ramm's gravatar image

Frederik Ramm ♦
accept rate: 23%

Yeah, actually the data gets immediately in touch with (our own) OSM database. But your idea of re-numbering made me think of re-numbering all of our own OSM elements in the database whenever we update from the official OSM servers having an ID conflict.

(12 Jan '14, 19:57) Henry Moews

appending to Frederik's hint:

can this be a solution?

(13 Jan '14, 17:14) stephan75

Reserving IDs is a very bad idea... Aside from the obvious management complications, there are other complications whenever you encounter conflicts of IDs, software not aware of the reservations, etc.

Also, you're trying to use a tool (JOSM) that wasn't designed to work with "mixed" (OSM and private) data. JOSM will keep renumbering your IDs internally, and it wouldn't matter to it, because even if different between different loads of the same file, it'll be consistent at the moment of the upload to the OSM servers (which will replace the negative numbers with valid IDs)

The ID that'll be used is the next sequence number of the relevant tables. If by some reason the upload fails, the whole transaction is rolled back and the IDs used are "lost" forever.

However, not everything is lost... One workaround I thought is relatively simple, emulates the reservation system, but has some limitations. Let me explain...

  • Change the sequences in your local copy of the OSM database, setting the next value to a very high number. The IDs are all bigints, use something like 1 x 10^18, totally out of reach of anything that "normal" OSM will reach in the next billion years. And still leaving trillions of IDs for your usage.
  • Install the full rails port, including the APIDB server, etc.
  • Modify JOSM to point to your LOCAL server. Very easy, in the configurations. Maybe, even change the look and feel (also in the configurations) to make clear that data processed with this version should NEVER be uploaded to the public servers.
  • Add your data and upload to your LOCAL server.
  • Update using the daily/hourly/minutely from the official OSM.

The limitations are:

  • Your data will never be compatible again with the OSM data without more processing - the IDs would have to be stripped and replaced with negative IDs before it could be uploaded to the public OSM server. And probably there'll be many conflicts. Maybe someone else will do a survey and upload some version of a map to the same place?
  • Your data will have to be fully new. Not even one node, one way can be shared with the public OSM database, not because of copyright, but because if someone changes this item in the public OSM database, your private data will be changed as well, probably in ways that you do not intend to.
  • If someone else uploads something in the area you privately mapped, it'll overlap your data, and you can't remove it without almost surely breaking the possibility of further updates to you LOCAL database, because it'll fail when it doesn't find the conflicting items.

Updates to the APIDB using osmosis, or other tools, from the daily/hourly/minutely changes all come with the IDs already assigned, therefore the sequence number is never touched when you apply them. Your own changes, on the other hand, do not have valid IDs yet, and the API server will use the default (implicit or explicit, can't remember) of the ID column which is "nextval([name_of_sequence])".

EDIT: I didn't fully understood Frederick's answer cited before. Corrected!

permanent link

answered 12 Jan '14, 21:07

MCPicoli's gravatar image

accept rate: 24%

edited 12 Jan '14, 21:15

Why do you even worry about conflicting IDs if you don't intend to upload your results anyway ? Put your objects in your own db, and use a mashup to display your indoor map on top of the osm basemap.

You can "seed" your work using an extract of OSM data if you want, say the town your school resides in. That would just be a snapshot of osm data; updating said data after you modified it should be possible, but is likely to run into problems now and then. Also, remember that if you seed your own map this way, it certainly constitute a derived work and you would have to redistribute it, making the whole effort of keeping your work separate a bit pointless.

If you ever want to merge your data with the osm data (assuming you didn't seed it with osm data, and kept it separate), just extract your db as a *.osm file, negate all the ids, load it into josm, check for problems, and upload to osm.

permanent link

answered 13 Jan '14, 09:31

Vincent%20de%20Phily's gravatar image

Vincent de P... ♦
accept rate: 19%

You can't upload to your own local DB and update it from the diffs unless you take care about conflicting IDs.

(13 Jan '14, 10:08) MCPicoli

That's part of the problems you could have. You'd have to fix them manually on a case by case basis.

Not that I'm advocating this method. I really think you should either upload directly to osm, or use a completely separate db.

(13 Jan '14, 12:45) Vincent de P... ♦

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here



Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text]( "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:


question asked: 12 Jan '14, 17:02

question was seen: 10,787 times

last updated: 13 Jan '14, 17:14

NOTICE: is no longer in use from 1st March 2024. Please use the OpenStreetMap Community Forum