Though this may not be the right thing to do, the fact is most geojson generating libraries (i.e. GDAL OGR) do generate "type": "FeatureCollection" root element, even if there is only one polygon or multipolygon in features array.
Could be great if osmium extract accepts this geojson format, so there won't be any effort to reformat geojson (extract the feature element) to fit the expected osmium format.
It could simply use the first object in features array ignoring all the others, if there are more than one feature.
@joto What do you think of it?

Osmium comes with several man page. Their source code is in Markdown format and on Linux/Mac they are compiled with Pandoc into man pages. What should happen with them on Windows?

/cc @BergWerkGIS

I import data into openstreetmap-website container ,and edit it ,then import another data into container. Steps below:

1、Renumber several osm files at the same directory . the last id of node.idx is 1000 ,for example.
2、Merge osm files into one osm.pbf file .
3、Import this pbf file into openstreetmap-website container using osmosis tool.
4、Change sequence in postgresql database
5、Edit and save new elements in ID Editor,and node's id added from 1001 to 1020,for example.
6、At this time I renumber another osm file at the same directory,which node.idx's last id is 1000 . and after renumber the node.idx's id added from 1001 to 2000. and I want to import this new osm file to openstreetmap-website container. Error occurs "Key (id)=(1000) already exist"

Do you have any suggestion to avoid key error?Thanks for any help.

Hi!

I'm trying to convert a ~130 GB osm file to geojsonseq using the code from the export branch.

The exact command I'm using is: osmium export -vi sparse_file_array -u type_id -r filtered.osm -o filtered.geojsonseq

But I'm getting the following error:

[ 0:00]   other options:
[ 0:00]     index type: sparse_file_array
[ 0:00]     add unique IDs: type and id
[ 0:00]     keep untagged features: no
[ 0:00] First pass through input file (reading relations)...
[31:01] First pass done.
[31:01] Second pass through input file...
osmium: /home/ubuntu/libosmium/include/osmium/storage/item_stash.hpp:157: const size_t& osmium::ItemStash::get_item_impl(osmium::ItemStash::handle_type) const: Assertion `offset < m_buffer.committed()' failed.
21847 Aborted                 (core dumped) osmium export -vi sparse_file_array -u type_id -r $1 -o $2

This worked previously (the file did have about 10 GB less data though), so I'm not sure if it's a regression in the export branch, in libosmium or if I just need more RAM?

I'm going to try to use the code from rev 2511be9 to try and identify the regression, but if you have any ideas please let me know :)

PS: Amazing tool!

I found a subtle difference in how the merge command handles two-way and n-way merges. It's possibly a bug that the output of a two-way merge can contain the same version of an object twice, if the inputs have them with differing timestamp metadata.

This code behaves slightly different than the more general n-way merge path, because set_union uses the < operator under the hood, where libosmium takes an object's timestamp also into account, not like the == used below.

I found this after merging two osh files which contained both the same version of an object with slightly different timestamps (I guess because of a software bug/glitch/bitflip/? during the creation of one of the input files). After reading the man page, I expected that only one of these versions should be included in the output, but found both.

Appveyor build fails for some reason that seems not to be related to recent changes in Osmium. There are similar errors in https://github.com/osmcode/osm-gis-export .

@BergWerkGIS Can you take a look?

[stupid, please remove me]

I might be missing something in the documentation, but I'm unable to get make to work unless I explicitly specify the directory for libosmium/include in CMakeLists.txt

include_directories(/home/UserName/Downloads/libosmium/include)

Specifically, the issue seems to be that the code has include statements for hpp files which are only located in the libosmium git repository.

hi

I've managed to install version 1.3.0 and i'd like to upgrade it to 1.6.1
downloaded the latest version ran cmake and it installed successfully but when i run osmium it still sees the 1.3.0 version. could you please guide me on how to make the changes?

Is it possible to set options.timestamp header in the output osmium apply-changes?
Setting headers isn't documented much, so couldn't find it in the docs yet.

When I try to merge 2 pbf files containing duplicates, the output still has the duplicates.
merge file1.osm.pbf file2.osm.pbf -o result.osm.pbf

But if I use one of the file a second time, the output does not contains duplicates anymore.
merge file1.osm.pbf file2.osm.pbf file1.osm.pbf -o result.osm.pbf

The issue seems to come from the specific treatment made to process only 2 files, which seems to only do an union between the files.

} else if (m_input_files.size() == 2) {
        // Use simpler code when there are exactly two files to merge
        m_vout << "Merging 2 input files to output file...\n";
        osmium::io::Reader reader1(m_input_files[0], osmium::osm_entity_bits::object);
        osmium::io::Reader reader2(m_input_files[1], osmium::osm_entity_bits::object);
        auto in1 = osmium::io::make_input_iterator_range<osmium::OSMObject>(reader1);
        auto in2 = osmium::io::make_input_iterator_range<osmium::OSMObject>(reader2);
        auto out = osmium::io::make_output_iterator(writer);

        std::set_union(in1.cbegin(), in1.cend(),
                       in2.cbegin(), in2.cend(),
                       out);
    }

There are several osmium commands that select some OSM objects from a file (getid, extract, tags-filter currently, probably more in the future). In many, but not all cases, the user not only want's the objects matching the selection criteria (an ID, tag, or so) but also the objects referenced by the matching objects. So the nodes for ways and the members for relations.

Currently the getid command and the tags-filter command have the --add-referenced option for that. the default is to only include matching objects. The extract command has its "strategies" here.

Often new users stumble about this and expect the default version of the command to "do the right thing" and include everything needed. But on the other hand this is a lot of extra work for the commands and a lot more data they generate, so having a default that is much more expensive seems wrong.

The other question is whether the current --add-referenced is enough. For the extract we already have a different way of specifying essentially the same issue, because there are more options that make sense. And I have already been thinking about adding an option to getid and tags-filter to add parent ways and/or relations.

Still failing on Appveyor. This current code has worked at some point. See #3. Somebody with access to a Windows machine has to debug this.

[00:06:03] C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\algorithm(3516): error C2280: 'boost::iterators::function_output_iterator<CommandApplyChanges::run::<lambda_ec429f2f6ec2842e3635f64232f11c96>> &boost::iterators::function_output_iterator<Comman
[00:06:03] dApplyChanges::run::<lambda_ec429f2f6ec2842e3635f64232f11c96>>::operator =(const boost::iterators::function_output_iterator<CommandApplyChanges::run::<lambda_ec429f2f6ec2842e3635f64232f11c96>> &)': attempting to reference a deleted function [C:\projects\os
[00:06:03] mium-tool\build\src\osmium.vcxproj]
[00:06:03]   c:\projects\osmium-tool\libosmium-deps\boost\boost/function_output_iterator.hpp(47): note: compiler has generated 'boost::iterators::function_output_iterator<CommandApplyChanges::run::<lambda_ec429f2f6ec2842e3635f64232f11c96>>::operator =' here
[00:06:03]   C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\algorithm(3530): note: see reference to function template instantiation '_OutIt std::_Set_union<_Iter,osmium::io::InputIterator<osmium::io::Reader,osmium::OSMObject>,_OutIt,_Pr>(_InIt1,_InIt1
[00:06:03] ,_InIt2,_InIt2,_OutIt,_Pr)' being compiled
[00:06:03]           with
[00:06:03]           [
[00:06:03]               _OutIt=boost::iterators::function_output_iterator<CommandApplyChanges::run::<lambda_ec429f2f6ec2842e3635f64232f11c96>>
[00:06:03]   ,            _Iter=osmium::ObjectPointerCollection::iterator
[00:06:03]   ,            _Pr=osmium::object_order_type_id_reverse_version
[00:06:03]   ,            _InIt1=osmium::ObjectPointerCollection::iterator
[00:06:03]   ,            _InIt2=osmium::io::InputIterator<osmium::io::Reader,osmium::OSMObject>
[00:06:03]           ]
[00:06:03]   C:\projects\osmium-tool\src\command_apply_changes.cpp(188): note: see reference to function template instantiation '_OutIt std::set_union<osmium::ObjectPointerCollection::iterator,osmium::io::InputIterator<osmium::io::Reader,osmium::OSMObject>,boost::ite
[00:06:03] rators::function_output_iterator<CommandApplyChanges::run::<lambda_ec429f2f6ec2842e3635f64232f11c96>>,osmium::object_order_type_id_reverse_version>(_InIt1,_InIt1,_InIt2,_InIt2,_OutIt,_Pr)' being compiled
[00:06:03]           with
[00:06:03]           [
[00:06:03]               _OutIt=boost::iterators::function_output_iterator<CommandApplyChanges::run::<lambda_ec429f2f6ec2842e3635f64232f11c96>>
[00:06:03]   ,            _InIt1=osmium::ObjectPointerCollection::iterator
[00:06:03]   ,            _InIt2=osmium::io::InputIterator<osmium::io::Reader,osmium::OSMObject>
[00:06:03]   ,            _Pr=osmium::object_order_type_id_reverse_version
[00:06:03]           ]
[00:06:04]   command_cat.cpp

/cc @alex85k

On OS/X the crypto++ library is named cryptopp, the Makefile needs to take this into account.

The check-apply-changes-mixed1 & check-apply-changes-mixed2 caused the osmium-tool 1.4.0 builds on mips & mipsel to fail due to segfaults in these tests:

        Start  20: check-apply-changes-mixed1
 19/198 Test  #20: check-apply-changes-mixed1 ................***Exception: SegFault  0.10 sec

        Start  21: check-apply-changes-mixed2
 21/198 Test  #21: check-apply-changes-mixed2 ................***Exception: SegFault  0.10 sec
[...]
99% tests passed, 2 tests failed out of 198

Total Test time (real) =  29.51 sec

The following tests FAILED:
     20 - check-apply-changes-mixed1 (SEGFAULT)
     21 - check-apply-changes-mixed2 (SEGFAULT)
Errors while running CTest

Full buildlogs: mips, mipsel

I've run the tests manually on the mips porterbox under gdb.

check-apply-changes-mixed1:

(gdb) run
Starting program: /home/sebastic/git/pkg-grass/osmium-tool-1.4.0/obj-mips-linux-gnu/src/osmium apply-changes test/apply-changes/input-data.osm test/apply-changes/input-change.osc -f osh
warning: GDB can't find the start of the function at 0x77fc6b8c.

    GDB is unable to find the start of the function at 0x77fc6b8c
and thus can't determine the size of that function's stack frame.
This means that GDB may be unable to access that stack frame, or
the frames below it.
    This problem is most likely caused by an invalid program counter or
stack pointer.
    However, if you think GDB should simply search farther back
from 0x77fc6b8c for code which looks like the beginning of a
function, you can increase the range of the search using the `set
heuristic-fence-post' command.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/mips-linux-gnu/libthread_db.so.1".
warning: GDB can't find the start of the function at 0x77fc7648.

Program received signal SIGSEGV, Segmentation fault.
0x5559bd80 in main (argc=6, argv=<optimized out>) at ./src/main.cpp:111
111             std::cerr << e.what() << std::endl;
(gdb) bt full
#0  0x5559bd80 in main (argc=6, argv=<optimized out>) at ./src/main.cpp:111
        e = @0x0: <incomplete type>
        command = "apply-changes"
        arguments = std::vector of length 4, capacity 8 = {"test/apply-changes/input-data.osm", "test/apply-changes/input-change.osc", "-f", "osh"}
        cmd = std::unique_ptr<Command> containing 0x556879a0

check-apply-changes-mixed2:

(gdb) run 
Starting program: /home/sebastic/git/pkg-grass/osmium-tool-1.4.0/obj-mips-linux-gnu/src/osmium apply-changes test/apply-changes/input-data.osh test/apply-changes/input-change.osc -f osm
warning: GDB can't find the start of the function at 0x77fc6b8c.

    GDB is unable to find the start of the function at 0x77fc6b8c
and thus can't determine the size of that function's stack frame.
This means that GDB may be unable to access that stack frame, or
the frames below it.
    This problem is most likely caused by an invalid program counter or
stack pointer.
    However, if you think GDB should simply search farther back
from 0x77fc6b8c for code which looks like the beginning of a
function, you can increase the range of the search using the `set
heuristic-fence-post' command.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/mips-linux-gnu/libthread_db.so.1".
warning: GDB can't find the start of the function at 0x77fc7648.

Program received signal SIGSEGV, Segmentation fault.
0x5559bd80 in main (argc=6, argv=<optimized out>) at ./src/main.cpp:111
111             std::cerr << e.what() << std::endl;
(gdb) bt full
#0  0x5559bd80 in main (argc=6, argv=<optimized out>) at ./src/main.cpp:111
        e = @0x0: <incomplete type>
        command = "apply-changes"
        arguments = std::vector of length 4, capacity 8 = {"test/apply-changes/input-data.osh", "test/apply-changes/input-change.osc", "-f", "osm"}
        cmd = std::unique_ptr<Command> containing 0x556879a0

I had some trouble building on OSX (what else is new?), curious if you have any insight. The full log is here: https://gist.github.com/rclark/0794bcec93f14ae224ec

It appears to me that there's some kind of version discrepancy in my protobuf lib? I've installed it via homebrew:

$ brew info protobuf
protobuf: stable 2.6.0 (bottled)
http://code.google.com/p/protobuf/
/usr/local/Cellar/protobuf/2.6.0 (80 files, 6.9M) *
  Built from source with: --c++11
From: https://github.com/Homebrew/homebrew/blob/master/Library/Formula/protobuf.rb
==> Options
--c++11
    Build using C++11 mode
--universal
    Build a universal binary
--with-python
    Build with python support
==> Caveats
Editor support and examples have been installed to:
  /usr/local/Cellar/protobuf/2.6.0/share/doc/protobuf

I tried this with and without the --c++11 flag.

There is a faulty configuration for finding Boost in the CMakeList.txt file. My system admin tried to replace the following lines in the 'osmium-tool-1.3.1/CMakeLists.txt' file (lines 45-46):

find_package(Boost REQUIRED COMPONENTS program_options)
include_directories(SYSTEM ${Boost_INCLUDE_DIRS})

with:

find_package(Boost 1.55.0 COMPONENTS program_options)
if(Boost_FOUND)
    include_directories(${Boost_INCLUDE_DIRS})
endif()

and the program successfully compiled. I am using a server which has a different version of boost installed.

mapuser@mapsrv:~/data/florinb/test/osmium-tool-1.6.0$ make
mkdir -p build && cd build && cmake .. && make
-- The C compiler identification is GNU 5.4.0
-- The CXX compiler identification is GNU 5.4.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
CMake Warning at /usr/share/cmake-3.5/Modules/FindBoost.cmake:725 (message):
Imported targets not available for Boost version
Call Stack (most recent call first):
/usr/share/cmake-3.5/Modules/FindBoost.cmake:763 (_Boost_COMPONENT_DEPENDENCIES)
/usr/share/cmake-3.5/Modules/FindBoost.cmake:1332 (_Boost_MISSING_DEPENDENCIES)
CMakeLists.txt:44 (find_package)

CMake Error at /usr/share/cmake-3.5/Modules/FindBoost.cmake:1677 (message):
Unable to find the requested Boost libraries.

Unable to find the Boost header files. Please set BOOST_ROOT to the root
directory containing Boost or BOOST_INCLUDEDIR to the directory containing
Boost's headers.
Call Stack (most recent call first):
CMakeLists.txt:44 (find_package)

CMake Error at cmake/FindOsmium.cmake:75 (file):
file STRINGS file
"/home/mapuser/data/florinb/test/osmium-tool-1.6.0/OSMIUM_INCLUDE_DIR-NOTFOUND/osmium/version.hpp"
cannot be read.
Call Stack (most recent call first):
CMakeLists.txt:47 (find_package)

-- Found ZLIB: /usr/lib/x86_64-linux-gnu/libz.so (found version "1.2.8")
-- Looking for pthread.h
-- Looking for pthread.h - found
-- Looking for pthread_create
-- Looking for pthread_create - not found
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - found
-- Found Threads: TRUE
-- Looking for protozero
-- Looking for protozero - not found
CMake Warning at cmake/FindOsmium.cmake:143 (message):
Osmium: Can not find some libraries for PBF input/output, please install
them or configure the paths.
Call Stack (most recent call first):
CMakeLists.txt:47 (find_package)

-- Could NOT find EXPAT (missing: EXPAT_LIBRARY EXPAT_INCLUDE_DIR)
-- Could NOT find BZip2 (missing: BZIP2_LIBRARIES BZIP2_INCLUDE_DIR)
CMake Warning at cmake/FindOsmium.cmake:169 (message):
Osmium: Can not find some libraries for XML input/output, please install
them or configure the paths.
Call Stack (most recent call first):
CMakeLists.txt:47 (find_package)

CMake Error at /usr/share/cmake-3.5/Modules/FindPackageHandleStandardArgs.cmake:148 (message):
Could NOT find Osmium: Found unsuitable version "unknown", but required is
at least "2.12.0" (found OSMIUM_INCLUDE_DIR-NOTFOUND)
Call Stack (most recent call first):
/usr/share/cmake-3.5/Modules/FindPackageHandleStandardArgs.cmake:386 (_FPHSA_FAILURE_MESSAGE)
cmake/FindOsmium.cmake:294 (find_package_handle_standard_args)
CMakeLists.txt:47 (find_package)

CMake Error: The following variables are used in this project, but they are set to NOTFOUND.
Please set them or make sure they are set and tested correctly in the CMake files:
Boost_INCLUDE_DIR (ADVANCED)
used as include directory in directory /home/mapuser/data/florinb/test/osmium-tool-1.6.0
used as include directory in directory /home/mapuser/data/florinb/test/osmium-tool-1.6.0

-- Configuring incomplete, errors occurred!
See also "/home/mapuser/data/florinb/test/osmium-tool-1.6.0/build/CMakeFiles/CMakeOutput.log".
See also "/home/mapuser/data/florinb/test/osmium-tool-1.6.0/build/CMakeFiles/CMakeError.log".
Makefile:3: recipe for target 'all' failed
make: *** [all] Error 1
mapuser@mapsrv:~/data/florinb/test/osmium-tool-1.6.0$

It would be nice if it were possible to set header options for pbf files in osmium extract. They would need to be set individually for each output file, so probably best in the json config.

CC @woodpeck

Hello everyone,

I am trying to stream the planet pbs file from a local http mirror using curl or wget to osmium tags-filter and experience a broken pipe at 3.51G being transferred.

Commands to reproduce:

wget -O - http://host/planet-latest.osm.pbf | osmium tags-filter - --omit-referenced --input-format pbf --output extract.osm.pbf [FILTER-EXPRESSION]
curl -o - http://host/planet-latest.osm.pbf | osmium tags-filter - --omit-referenced --input-format pbf --output extract.osm.pbf [FILTER-EXPRESSION]

wget output is:

HTTP request sent, awaiting response... 200 OK
Length: 37616433113 (35G) [application/octet-stream]
Saving to: ‘STDOUT’

-                    10%[=>                  ]   3.51G  13.3MB/s    in 4m 38s  


Cannot write to ‘-’ (Broken pipe).
failed to uncompress data: data error

I tested the same with a state-level extract and it completed fine. I also throttled the data transfer but this did not change the behavior. Are you able to reproduce this? I could not find the location of the code handling stdin so far but it seems it's located somewhere in libosmium, right? Can you please give me some thoughts on this issue?

Thank you very much in advance :-)

New osmium renumber is great, thank you.

A command-line option to renumber only nodes, not ways, would be really useful. Nodes are usually the reason to run renumber (especially now they've topped 2**32) and it can be good for data debugging purposes to retain original way IDs.

There is a problem that bothers me. if I run the command: "osmium renumber -i. -o 1_renumber.osm 1.osm",it works well. How to renumber another file from the last number that 1_renumber.osm used? I have trying to run "osmium renumber -i. -o 1_renumber.osm 1.osm -o 2_renumber.osm 2.osm" and "osmium renumber -i. -o 1_renumber.osm 1.osm 2.osm", both of them occur "Error parsing command line: too many positional options have been specified on the command line".How to rename multiple osm files？Thanks for your reply.

(I'm running osmium-tool's current master including the fix for #42, compiling against libosmium v2.11.0)

When extracting a region that is defined by a geojson file containing a MultiPolygon geometry, the output does only contain data from the first of the polygons of the multipolygon.

Here's my test input: map.geojson.zip (a couple of roughly drawn bboxes over a few cities in Germany). I'm running osmium-tool like: …/osmium extract -p map.geojson germany-latest.osm.pbf -o map.pbf. The resulting file is idential to just an extract of the Hamburg bbox.

This happens both in normal as well as --with-history mode. Using a different strategy (simple, complete ways, smart) also doesn't affect the result.

PS: I haven't tested this with anything other than geojson input. It may or may not be limited to that geometry input format.

I'm trying to build osmium, but it fails with multiple definition of OSMPBF::version

Linking CXX executable osmium
CMakeFiles/osmium.dir/command_merge_changes.cpp.o:(.data+0x0): multiple definition of `OSMPBF::version'
CMakeFiles/osmium.dir/command_fileinfo.cpp.o:(.data+0x0): first defined here
CMakeFiles/osmium.dir/command_cat.cpp.o:(.data+0x0): multiple definition of `OSMPBF::version'
CMakeFiles/osmium.dir/command_fileinfo.cpp.o:(.data+0x0): first defined here
CMakeFiles/osmium.dir/command_apply_changes.cpp.o:(.data+0x0): multiple definition of `OSMPBF::version'
CMakeFiles/osmium.dir/command_fileinfo.cpp.o:(.data+0x0): first defined here
CMakeFiles/osmium.dir/main.cpp.o:(.data+0x0): multiple definition of `OSMPBF::version'
CMakeFiles/osmium.dir/command_fileinfo.cpp.o:(.data+0x0): first defined here
CMakeFiles/osmium.dir/command_time_filter.cpp.o:(.data+0x0): multiple definition of `OSMPBF::version'
CMakeFiles/osmium.dir/command_fileinfo.cpp.o:(.data+0x0): first defined here
collect2: error: ld returned 1 exit status
make[2]: *** [src/osmium] Error 1
make[1]: *** [src/CMakeFiles/osmium.dir/all] Error 2
make: *** [all] Error 2

Ubuntu 14.04.2 LTS

Would it be possible to add SHA of the current git objekct in --version, if sourcecode has been pulled from GIT?

Right now, I'm using a small shell-script, which modifies CMakeList.txt like this:

set(OSMIUM_COMMIT_GIT    6ba6903f56aa2dd99d8911bfa3cbc69bea3c8e70)

set(OSMIUM_VERSION "${OSMIUM_VERSION_MAJOR}.${OSMIUM_VERSION_MINOR}.${OSMIUM_VERSION_PATCH} commit: ${OSMIUM_COMMIT_GIT}")

Maybe it would be better to run execute_process(COMMAND ... with some error detection, f.e. if GIT has been installed at all ;)

Hi,
I'm trying to use the command line osmium tool to create historical extracts for the Copenhagen area.

I've build osmium 1.6.1 from a git clone on Ubuntu 16:

emil@emil-OptiPlex-7010:~/code/osmium-tool/build$ ./osmium --version
osmium version 1.6.1 (v1.6.1-4-gdf850c1)
libosmium version 2.12.2
Copyright (C) 2013-2017  Jochen Topf <[email protected]>
License: GNU GENERAL PUBLIC LICENSE Version 3 <https://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

I downloaded the lastest planet history:

emil@emil-OptiPlex-7010:~/Documents/cykelafstande$ ls -l history-latest.osm.pbf -rw-rw-r-- 1 emil emil 61479341460 May  2 16:13 history-latest.osm.pbf

I then extracted using a bounding box:

./osmium extract -b 12.3843,55.5694,12.7338,55.7766 /home/emil/Documents/history-latest.osm.pbf -o history-cph.pbf --with-history

And get a smaller file:

emil@emil-OptiPlex-7010:~/Documents/cykelafstande$ ls -l history-cph.osm.pbf 
-rw-rw-r-- 1 emil emil 37185282 May  3 13:04 history-cph.osm.pbf

But the resulting file contain many invalid node locations [214.7483647,214.7483647]:

lsemil@emil-OptiPlex-7010:~/code/osmium-tool/build$ ./osmium show '/home/emil/Documents/cykelafstande/history-cph.osm.pbf' 

header
  multiple object versions: no
  bounding boxes: 
  options: 
    generator = osmium/1.6.1
    pbf_dense_nodes = true

=============================================
[...]
node 118724
  version:   8 visible
  changeset: 457527
  timestamp: 2008-12-18T12:13:49Z (1229602429)
  user:      38985 "Johnny Carlsen"
  lon/lat:   12.5626748,55.6738531

node 118724
  version:   9 visible
  changeset: 457527
  timestamp: 2008-12-18T12:26:01Z (1229603161)
  user:      38985 "Johnny Carlsen"
  lon/lat:   214.7483647,214.7483647 INVALID LOCATION!

All invalid locations are placed at [214.7483647,214.7483647], and only occur at the last version of a particular node.

I'm able to use the time-filter command on the extract to make time-specific files, but the output files contain the same invalid locations, and cannot be read by e.g. OSRM, instead resulting in a messsage about invalid location:

emil@emil-OptiPlex-7010:~/code/osrm-backend/sandbox$ ../build/osrm-extract -p ../profiles/bicycle.lua /home/emil/Documents/cykelafstande/cph-2013.osm.pbf
[info] Using script ../profiles/bicycle.lua
[info] Input file: cph-2013.osm.pbf
[info] Profile: bicycle.lua
[info] Threads: 4
[info] Parsing in progress..
[STXXL-MSG] STXXL v1.4.1 (prerelease/Debug)
[STXXL-ERRMSG] Warning: no config file found.
[STXXL-ERRMSG] Using default disk configuration.
[STXXL-MSG] Disk '/var/tmp/stxxl' is allocated, space: 1000 MiB, I/O implementation: syscall autogrow delete_on_exit queue=0 devid=0
[info] input file generated by osmium/1.6.1
[info] timestamp: n/a
terminate called after throwing an instance of 'osmium::invalid_location'
  what():  invalid location
Aborted (core dumped)

I have a strange issue when making an extract with osmium extract command.
When I use just a command line options everything goes ok, but when I use a config file, I get the same log, but the resulting osm extract is empty - just osm headers set inside the file, but no data.

I've tried:

• using geojson instead of poly file
• changing "output_format" from "pbf" to "osm"
• setting strategies other than smart
• setting "polygon": instead of "multipolygon":

None of this helps. The extraction process takes the same amount of time like when running without config file, but the result is empty.

Running on

osmium version 1.7.0
libosmium version 2.13.0

Any clues?

osmium-tools 1.7.0 failed to build on mips64el due to unittest failing:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
unit_tests is a Catch v1.9.7 host application.
Run with -? for options

-------------------------------------------------------------------------------
Parse OSM files
  OSM file with simple polygon
-------------------------------------------------------------------------------
/<<PKGBUILDDIR>>/test/extract/test_unit.cpp:141
...............................................................................

/<<PKGBUILDDIR>>/test/extract/test_unit.cpp:143: FAILED:
  REQUIRE( parser() == 0 )
due to unexpected exception with message:
  Support for compression 'none' not compiled into this binary

-------------------------------------------------------------------------------
Parse OSM files
  OSM file with two simple polygons
-------------------------------------------------------------------------------
/<<PKGBUILDDIR>>/test/extract/test_unit.cpp:156
...............................................................................

/<<PKGBUILDDIR>>/test/extract/test_unit.cpp:158: FAILED:
  REQUIRE( parser() == 0 )
due to unexpected exception with message:
  Support for compression 'none' not compiled into this binary

-------------------------------------------------------------------------------
Parse OSM files
  OSM file with multipolygon relation
-------------------------------------------------------------------------------
/<<PKGBUILDDIR>>/test/extract/test_unit.cpp:174
...............................................................................

/<<PKGBUILDDIR>>/test/extract/test_unit.cpp:176: FAILED:
  REQUIRE( parser() == 0 )
due to unexpected exception with message:
  Support for compression 'none' not compiled into this binary

===============================================================================
test cases:  16 |  15 passed | 1 failed
assertions: 159 | 156 passed | 3 failed

Full buildlog

@joto I've been playing with osmium tags-filter, here is some opinions:

• make --add-referenced default. osmium extract has a default strategy of complete_ways and I guess it avoids user error to include as much as possible, then have the user decide to cut down if not needed.
• allow for exclusion. Right now tags-filter is inclusive. I guess a common use-case will be to slim down osm extracts so that they can be easier loaded into tools like JOSM. So the user might want to retain everything except a big class of tags, like building or highway.
• JSON as config format. the current config file feels a bit obscure and osmium extract has json config files, so tags-filter could as well. i understand that the current solution is nice because command line arguments and config file are the same, so i'm not sure how to solve this.

The correct diff between the two OSM files

   <osm version="0.6">
   </osm>

and

   <osm version="0.6">
      <node id="1" version="2" timestamp="2016-09-14T19:18:17Z" uid="16" user="User" changeset="15" lat="1.413" lon="1.211" />
   </osm>

is

   <osmChange version="0.6">
     <create>
       <node id="1" version="2" timestamp="2016-09-14T19:18:17Z" uid="16" user="User" changeset="15" lat="1.413" lon="1.211"/>
     </create>
   </osmChange>

but osmium-tool derive-change creates a "modify" block instead of the "create" block.

The problem does not appear when the new object has the version number 1.

mapuser@mapsrv:~/data/florinb/test/osmium-tool-1.6.0/build$ cmake ..
-- Boost version: 1.58.0
-- Found the following Boost libraries:
-- program_options
CMake Error at cmake/FindOsmium.cmake:75 (file):
file STRINGS file
"/home/mapuser/data/florinb/test/osmium-tool-1.6.0/OSMIUM_INCLUDE_DIR-NOTFOUND/osmium/version.hpp"
cannot be read.
Call Stack (most recent call first):
CMakeLists.txt:47 (find_package)

-- Looking for protozero
-- Looking for protozero - found
CMake Error at /usr/share/cmake-3.5/Modules/FindPackageHandleStandardArgs.cmake:148 (message):
Could NOT find Osmium: Found unsuitable version "unknown", but required is
at least "2.12.0" (found OSMIUM_INCLUDE_DIR-NOTFOUND)
Call Stack (most recent call first):
/usr/share/cmake-3.5/Modules/FindPackageHandleStandardArgs.cmake:386 (_FPHSA_FAILURE_MESSAGE)
cmake/FindOsmium.cmake:294 (find_package_handle_standard_args)
CMakeLists.txt:47 (find_package)

-- Configuring incomplete, errors occurred!

report for "osmium version 1.3.0" (57715b1)

Description of the issue

When merging multiple changefiles (gz-compressed osc) in combination with switch --simplify, the resulting changefile isn't merged correctly.

Download changefiles

Sporadic (aprox. daily) changefiles from Geofabrik. This commands needs bash for increment, otherwise simply increment filename by 1 (144.osc.gz, 145.osc.gz etc.):
wget http://download.geofabrik.de/europe-updates/000/001/14{2..6}.osc.gz

Do the merging and have a look at a way ID

osmium merge-changes *.osc.gz --simplify --output=test.osc
grep 414256828 -B1000 test.osc | grep -E 'delete|modify|create' | tail -n 1

Issue

As you can see, the last action is <create>, but that's wrong. The last action should be <delete>. Way 414256828 got created in 144.osc.gz and got removed in 142.osc.gz - so it shouldn't appear in the final changefile.

Different behaviour when dropping simplify

When dropping --simplify, the last action is correct. Of course, that's not what we want :)

Digging deeper

I've figured out, that the bug only appears on wrong file order!

## 1.osc
<?xml version='1.0' encoding='UTF-8'?>
<osmChange version="0.6" generator="tobwen">
  <delete>
    <way id="414256828" version="1" timestamp="2016-05-03T00:18:16Z" uid="3497527" user="MCalascione" changeset="38966372">
      <nd ref="1177121444"/>
      <nd ref="4154263790"/>
      <nd ref="4154263890"/>
      <nd ref="4154253492"/>
      <nd ref="4137072356"/>
      <nd ref="1177121454"/>
      <tag k="highway" v="unclassified"/>
      <tag k="oneway" v="yes"/>
    </way>
  </delete>
</osmChange>

## 2.osc
<?xml version='1.0' encoding='UTF-8'?>
<osmChange version="0.6" generator="tobwen">
  <create>
    <way id="414256828" version="1" timestamp="2016-04-28T20:44:16Z" uid="3497527" user="MCalascione" changeset="38966372">
      <nd ref="1177121444"/>
      <nd ref="4154263790"/>
      <nd ref="4154263890"/>
      <nd ref="4154253492"/>
      <nd ref="4137072356"/>
      <nd ref="1177121454"/>
      <tag k="highway" v="unclassified"/>
      <tag k="oneway" v="yes"/>
    </way>
  </create>
</osmChange>

Start a new test

• osmium merge-changes 1.osc 2.osc --simplify --output=test_01.osc
• osmium merge-changes 2.osc 1.osc --simplify --output=test_02.osc

Oops... First command gives the expected result, second doesn't. Seems like the order is important.

Checking bash's expansion & Conclusion

When you expand *.osc.gz to full filenames, you can detect that the order is correct: 142.osc.gz 143.osc.gz 144.osc.gz 145.osc.gz 146.osc.gz. So there might be an internal bug when using --simplify.

Hello everyone,
I want to renumber several osm files. When renumber the first osm after sorted ,everything works well ,the command is 'osmium renumber -i. -o a_renumber.osm a_sort.osm'. When renumber 2th osm after sorted in the same directory, like 'osmium renumber -i. -o b_renumber.osm b_sort.osm'.Error occurs 'Zero-sized mapping is not allowed'.
The 2th osm was downloaded from Mappzen website with 490M size. The 1th osm was created myself with 40G size.
What can I do to renumber osm files one by one ?Thanks for any help.

As adviced in osmcode/libosmium#33 , I decided to check osimum on Windows/Visual Studio platform by building osmium-tool.

After adding easy fixes for cmake and include lists
alex85k@7c98c10
alex85k@2d7934e
alex85k@076e75f
, two complex errors remain.

Osmium-tool should use cmake to build to work better on multiple platforms.

The last bit missing in osmium tool is ability to download and cumulate planet changesets like osmupdatedoes.
I guess if this can be done in some form with pyosmium, it would be great to port it from there.
If this tool is in place, then my whole workflow involving ogr2poly, osmupdate, osmfilter, osmconvert and would be replaced with just osmium, making it a universal tool, similar to osmosis, but times faster.

When issuing osmium fileinfo on a file that was generated with osmupdate or osmconvert (i.e. cumulated o5c changes file from osmupdate) it displays header options like

Header:
  Bounding boxes:
  With history: yes
  Options:
    o5m_timestamp=2017-08-25T08:00:02Z
    timestamp=2017-08-25T08:00:02Z

However, there is no -g header.option.timestamp key to diplay just the timestamp.
Could this please be added?

I'd like to be able to write this header with osmium apply-changes and read back with osmium fileinfo, so I don't have to mess around with timestamps - put them in filenames or external files or wherever.

[Not sure if this is an libosmium or osmium-tool issue. Don't actually need this, just to let you know.]

When using changesets-latest.osm.bz2 converted to OPL format with osmium-tool I got the following error:
OPL error: expected space or tab character on line 153996 column 79

That line (+1?) is without coordinates, but seems to work Ok:

$ head -n 153997 changesets-latest.opl | tail -n 1
c153997 k5 s2008-08-09T18:47:50Z e2008-08-09T19:47:52Z d0 i5748 upschonmann x y X Y T

But I noticed changeset 153980 with these coordinates in OPL:
x-0../,),(-*,( y-29.4993277 X-0../,),(-*,( Y-29.4982071
XML format:
min_lat="-29.4993277" min_lon="-214.7483648" max_lat="-29.4982071" max_lon="-214.7483648"

To reproduce:

$ wget -qO - http://www.openstreetmap.org/api/0.6/changeset/153980 | osmium cat -F .osm.xml -f .opl | osmium fileinfo -e -F .opl
...
OPL error: expected space or tab character on line 0 column 79

osmium-tool is build from current master on Ubuntu 16.04:

$ osmium --version
osmium version 1.6.1 (v1.6.1-11-gde9b3b5)
libosmium version 2.12.2

I am not sure if this is a problem with libosmium, or with osmium-tool. Build, installation and unit tests for libosmium (2.5.3) were all successful. When I try to build osmium-tool (both from GitHub, and also the latest release) on Ubuntu 14.04LTS I get the following error:

cmake .
make
[ 29%] Built target man
[ 29%] Building CXX object test/CMakeFiles/unit_tests.dir/**/src/command_cat.cpp.o
In file included from /usr/local/include/osmium/io/detail/output_format.hpp:45:0,
from /usr/local/include/osmium/io/writer.hpp:45,
from /usr/local/include/osmium/io/debug_output.hpp:36,
from /usr/local/include/osmium/io/any_output.hpp:48,
from /home/ryan/Documents/Software/osmium-tool/src/command_cat.cpp:29:
/usr/local/include/osmium/io/detail/string_util.hpp:42:18: fatal error: utf8.h: No such file or directory
#include <utf8.h>
^
compilation terminated.
make[2]: * [test/CMakeFiles/unit_tests.dir//src/command_cat.cpp.o] Error 1
make[1]: *** [test/CMakeFiles/unit_tests.dir/all] Error 2
make: *** [all] Error 2

I have libicu and libicu-dev installed on my system.

Recently a number of people reported issues on GIS SE to get osmium-tool up and running, mostly because it appears to be too difficult for them. As a windows version is created as part of appveyor scripts anyway I wonder if that binary file result could be published somewhere.

Analyzing Sample_Thailand 03_14.osm from "Imports osm mail list" with osmium tool

I have got:

osmium cat Sample_Thailand\ 03_14.osm -f opl |  grep "^w-" | cut -d" " -f8 | sort | uniq -c
[======================================================================] 100% 
      1 Tbridge=yes,highway=unclassified,import=yes,source=digitalglobe
      1 Thighway=primary,ref=109,source=sign,surface=paved
      1 Thighway=residential,import=yes,note=Connect%20%to%20%primary%20%highway%20%2/28/2017,source=digitalglobe
    206 Thighway=residential,import=yes,source=digitalglobe
      1 Thighway=residential,source=digitalglobe,import=yes
    263 Thighway=track,import=yes,source=digitalglobe
      3 Thighway=track,source=digitalglobe,import=yes
     74 Thighway=unclassified,import=yes,source=digitalglobe
      2 Thighway=unclassified,source=digitalglobe,import=yes
      2 Timport=yes,source=digitalglobe,highway=track

As I see, that same taggings has a different key orders - so different lines, And my favorite osmium cat tricks ( sort | uniq -c ) not working here. So I see 2 summary lines, but this is same taggings.

     74 Thighway=unclassified,import=yes,source=digitalglobe
      2 Thighway=unclassified,source=digitalglobe,import=yes

It is possible to add a keys sorted - OPL format ( higway= ; import= ; source= ) ?
So I will got only 1 lines for the same tag combinations. ( 74 + 2 = 76 )

     76 Thighway=unclassified,import=yes,source=digitalglobe

I have tried alternative versions, without the expecting result :

• a.)

osmium cat Sample_Thailand\ 03_14.osm -f pbf > thai.osm.pbf
osmium cat thai.osm.pbf  -f opl | grep "^w-" | cut -d" " -f8 | sort | uniq -c

• b.)
  osmium sort Sample_Thailand\ 03_14.osm -f opl | grep "^w-" | cut -d" " -f8 | sort | uniq -c

tested with :

 osmium --version
osmium version 1.6.0 (v1.6.0)
libosmium version 2.12.0
Copyright (C) 2013-2017  Jochen Topf <[email protected]>
License: GNU GENERAL PUBLIC LICENSE Version 3 <https://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

test data:
Sample_Thailand 03_14.osm.zip

I have checked the special options : http://docs.osmcode.org/osmium/latest/osmium-file-formats.html but I have not find any solutions.

The new osmium getid --add-referenced option lets you find all the dependencies of a single feature given its id. Would it be possible to run this in the opposite direction? Given an id (or list of ids), find all the features that it is a part of?

Hi,

I need to access the data of the index files which where created by "osmium renumber" to back reference the original ids. Just in case somebody else needs this too:

od -An -td8 -w8 node.idx | cat -n

produces a mapping from "new_id" to "old_id".

The issue I'm looking at is to recreate .osc files based on an existing history dump. Instead of creating a huge .osc file based on several years of history, the idea came up to split the history file into smaller chunks and create .osc files based on them, say with 1 day or 1 week granularity. The following thread on the Overpass API dev list gives some more context, but that's optional reading.

I somehow got the impression that osmium time-filter could be used to extract all changes pertaining to a certain timeframe. I tried the following command:

osmium time-filter -o swiss_diff.osh.pbf switzerland-padded-softcut.osh.pbf 2015-01-01T00:00:00Z 2015-01-07T00:00:00Z

... followed by a osmconvert swiss_diff.osh.pbf --out-osc.

Unfortunately, the resulting .osc file contains data outside of the specified timeframe:

<modify>
        <node id="172218" lat="46.265176" lon="6.1340822" version="8" timestamp="2010-09-03T20:53:20Z" changeset="5674130" uid="74847" user="Marc Mongenet"/>
        <node id="172219" lat="46.2635155" lon="6.1331579" version="9" timestamp="2012-04-29T11:03:44Z" changeset="11448508" uid="74847" user="Marc Mongenet"/>
        <node id="172220" lat="46.2615572" lon="6.1326461" version="9" timestamp="2012-04-29T11:03:44Z" changeset="11448508" uid="74847" user="Marc Mongenet"/>
        <node id="172221" lat="46.2597426" lon="6.1330302" version="8" timestamp="2012-04-29T11:03:44Z" changeset="11448508" uid="74847" user="Marc Mongenet"/>
</modify>

I'm not sure if I'm somehow misunderstanding what osmium time-filter is supposed to do on .osh.pbf files. I checked the man page, but somehow I couldn't figure out, what If both FROM-TIME and TO-TIME are given, the result will also have history data is supposed to mean related to my question.

Original file location: http://planet.osm.ch/history/switzerland-padded-softcut.osh.pbf (521MB file size)

Hi,

I work on a planet full history PBF file and use osmium extract to select a smaller bounding box (France or a region of France). Then I use the pyosmium lib to extract some OSM features.

The launched command looks like:
osmium extract --with-history --config=config.json --fsync history.osm.pbf with a config.json such as:

{
    "extracts": [
        {
            "output": "latest-region.pbf",
            "output_format": "pbf",
            "description": "extract OSM history for a smaller region",
            "bbox": {"left": -1.428,
                     "right": 1.813,
                     "top": 45.275,
                     "bottom": 42.940}
        }
    ],
    "directory": "/path/to/output-dir"
}

Unfortunately, when I look the header of the output file given by osmium fileinfo, I don't have a with_history set to true neither a defined bbox. I thought the --output-header could help me but the documentation said to read the libosmium manual and...well, I didn't find a mention to the list of allowed header options. I naively add a JSON field to my configuration file as:

output_header: {
    "with_history": true
}

inside the first element of the extracts JSON list but without success.
How can I write a well header in my generated PBF file? The following problem is: when I parse the generated file with pyosmium, the visible attribute of each OSM entity is always set to true. So, three suppositions:

• the header value with_history: no shows that the PBF is not a history file, and then the optional visible attribute is set to its default value true
• Or if the generated PBF file doesn't have this specific information (i.e. visible)
• a third reason that I don't have known

Can you enlighten me about this --output-header option, the way to well-written the header and to have the real visible value of my history PBF file please? I feel that all this is related but maybe I'm wrong...

Best,
Damien

I'm running the following command on Ubuntu 14.04, latest versions of osmium-tool + libosmium:

osmium time-filter -o swiss.osm.pbf switzerland-padded-softcut.osh.pbf 2015-01-01T00:00:00Z

Original file location: http://planet.osm.ch/history/switzerland-padded-softcut.osh.pbf (521MB file size)

For some unknown reason, osmium's progress appears to be quite slow.
vmstat shows almost no CPU activity both on user/system/wa:

procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   Frei Puffer  Cache   si   so    bi    bo   In   cs US SY ID WA st
 1  0      0 13228888 150492 1100716    0    0     0     0 17926 36223  1  1 98  0  0
 1  0      0 13224796 150500 1100708    0    0     0    44 17582 35575  1  1 98  0  0
 0  0      0 13220484 150500 1101448    0    0  1024    36 18761 40186  3  2 95  0  0
 0  0      0 13218844 150500 1101740    0    0     0     0 17850 37390  2  1 97  0  0
 0  0      0 13221752 150500 1101740    0    0     0     0 17990 39777  2  2 96  0  0
 0  0      0 13229756 150500 1101740    0    0     0     0 17934 39061  4  1 95  0  0
 0  0      0 13237068 150500 1101740    0    0     0     0 18559 41281  3  1 96  0  0
 0  0      0 13230292 150500 1102764    0    0  1024     0 19369 40726  3  0 96  0  0
 3  0      0 13229488 150508 1102756    0    0     0    60 18600 38850  5  1 94  0  0
 2  0      0 13222424 150508 1104236    0    0     0     0 17973 37274  4  1 96  0  0
 0  0      0 13220332 150508 1104236    0    0     0  3092 18833 39557  4  1 95  0  0
 0  0      0 13223132 150508 1105012    0    0  1024     0 17653 35971  2  1 97  0  0
 0  0      0 13220880 150508 1105260    0    0     0     0 18607 38803  4  1 96  0  0
 0  0      0 13221572 150508 1105260    0    0     0     0 17899 36158  2  0 98  0  0
 0  0      0 13231340 150508 1105260    0    0     0     0 19129 39781  3  1 96  0  0
 0  0      0 13225912 150516 1106036    0    0  1024    56 18443 37533  2  1 98  0  0
 0  0      0 13220240 150516 1106284    0    0     0     0 18753 40094  5  1 94  0  0
 0  0      0 13219860 150516 1106284    0    0     0     0 17698 36013  1  1 98  0  0
 0  0      0 13226572 150516 1107448    0    0     0     0 18125 37004  3  0 97  0  0

I traced a few seconds of the respective process and it appears to be waiting on something.

 strace -c -p <pid>

% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 99.69    0.249140           1    249730    124849 futex
  0.31    0.000784         112         7           madvise
------ ----------- ----------- --------- --------- ----------------
100.00    0.249924                249737    124849 total

My expectation would be either higher io wait times or CPU user/system time.

Is this a known issue? Do you have any ideas on how to speed this up?

Hi,

May be I'm making an error somewhere. I successfully built osmium v1.6.1 from the git repository. However, when I use the filter-time command with both FROM_TIME TO_TIME, the results are not restricted by the FROM_TIME. Therefore, the results containing all history data up to the TO_TIME and not between the FROM_TIME to TO_TIME.

Example Command:
./osmiumv161/build/osmium time-filter -O -o test.osm Antarctica.osh.pbf 2010-01-01T00:00:00Z 2015-01-01T00:00:00Z

Did anyone have a similar issue?

Thanks for your help.

P.S. I'm using Ubuntu LTS 16

Ask travis to enable OSX support for this repository.

I've read the man pages but I'm still stuck as to why:

1.osm:

<?xml version='1.0' encoding='UTF-8'?>
<osm version="0.6">
    <node id="-1" lat="-33.7077207" lon="151.1745444"/>
    <node id="-2" lat="-33.7078497" lon="151.1746207"/>
</osm>

osmium sort --output=2.osm 1.osm

Is keeping the order -1 then -2. So when I then run

osmium renumber --output=3.osm 2.osm

There is the error:

Node IDs out of order.
This command expects the input file to be ordered: First nodes in order of ID,
then ways in order of ID, then relations in order of ID.

osmium help sort says that Objects are sorted by ID and it works with OSM data files and change files. The 1.osm file was created by saving new data from JOSM.

The point of running osmium renumber is to keep the IDs small and use positive integers, but it requires input to be sorted first.

osmium renumber works when I manually change the order to -2 then -1.

I used to use osmium renumber without pre-sorting the data which seemed to work fine but due to changes to renumber in 1.3.1 I now run into this issue.

Thank you for this tool!

What is the official status of checking super relations ? As I realized the "Relations in relations missing " is not correct in my test case.

my simple test case:

wget http://www.openstreetmap.org/api/0.6/relation/1124369 -O superrel.osm
cat superrel.osm
osmium check-refs -r -v -i  superrel.osm
osmium version

now:

Relations in relations missing: 0

probably the correct:

Relations in relations missing: 5

my test case log:

root@cf0cd2ea8b0f:/# wget http://www.openstreetmap.org/api/0.6/relation/1124369 -O superrel.osm
--2016-01-14 18:34:35--  http://www.openstreetmap.org/api/0.6/relation/1124369
Resolving www.openstreetmap.org (www.openstreetmap.org)... 193.63.75.100, 193.63.75.99, 193.63.75.103, ...
Connecting to www.openstreetmap.org (www.openstreetmap.org)|193.63.75.100|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/xml]
Saving to: ‘superrel.osm’

superrel.osm                                   [ <=>                                                                                      ]     984  --.-KB/s   in 0s     

2016-01-14 18:34:35 (58.7 MB/s) - ‘superrel.osm’ saved [984]

root@cf0cd2ea8b0f:/# cat superrel.osm
<?xml version="1.0" encoding="UTF-8"?>
<osm version="0.6" generator="CGImap 0.4.0 (6991 thorn-01.openstreetmap.org)" copyright="OpenStreetMap and contributors" attribution="http://www.openstreetmap.org/copyright" license="http://opendatacommons.org/licenses/odbl/1-0/">
 <relation id="1124369" visible="true" version="84" changeset="35194338" timestamp="2015-11-09T15:09:13Z" user="jleedev" uid="1960922">
  <member type="relation" ref="1206310" role=""/>
  <member type="relation" ref="1205151" role=""/>
  <member type="relation" ref="1205149" role=""/>
  <member type="relation" ref="4039486" role=""/>
  <member type="relation" ref="4039900" role=""/>
  <tag k="name" v="Great Lakes"/>
  <tag k="name:de" v="Große Seen"/>
  <tag k="name:en" v="Great Lakes"/>
  <tag k="name:fr" v="Grands Lacs"/>
  <tag k="name:ru" v="Великие_озёра"/>
  <tag k="name:vi" v="Ngũ Đại Hồ"/>
  <tag k="type" v="group"/>
  <tag k="wikipedia" v="en:Great Lakes"/>
 </relation>
</osm>
root@cf0cd2ea8b0f:/# osmium check-refs -r -v -i  superrel.osm
[ 0:00] Started osmium check-refs
[ 0:00] Command line options and default settings:
[ 0:00]   input options:
[ 0:00]     file name: superrel.osm
[ 0:00]     file format: 
[ 0:00]   other options:
[ 0:00]     show ids: yes
[ 0:00]     check relations: yes
[ 0:00] Reading relations...
There are 0 nodes, 0 ways, and 1 relations in this file.
Nodes     in ways      missing: 0
Nodes     in relations missing: 0
Ways      in relations missing: 0
Relations in relations missing: 0
[ 0:00] Done.
root@cf0cd2ea8b0f:/# osmium version
osmium version 1.3.0
Copyright (C) 2013-2015  Jochen Topf <[email protected]>
License: GNU GENERAL PUBLIC LICENSE Version 3 <http://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
root@cf0cd2ea8b0f:/# 

osmium tool version :

root@cf0cd2ea8b0f:/osm/osmium-tool# git log
commit a7e70da3dcab1e09350382e73d3e0b68eeb34aa0
Author: Jochen Topf <[email protected]>
Date:   Wed Jan 6 16:42:07 2016 +0100

libosmium version :

root@cf0cd2ea8b0f:/osm/libosmium# git log
commit 04305c13e30475f6eebc94785340ba91491b5ac2
Author: Jochen Topf <[email protected]>
Date:   Tue Jan 12 16:48:59 2016 +0100

    Make Buffer::swap non-member non-friend.