comm2osm creates an OSM (OpenStreetMap) PBF/XML/etc. file from commercial shapefiles to be able to use OSM tools on the data.
The architecture is plugin based. Currently there is a plugin (navteq) for converting routable Navteq data from the "NAVSTREETS Street Data Reference Manual v5.4" format into OSM format.
WARNING: DO NOT UPLOAD CONVERTED DATA TO OSM. Even if you were legally allowed to do so, imports into OSM are problematic due to the following reasons:
CAUTION: Have a look at install_prerequisites.sh
before executing it.
Install prerequisits with the install_prerequisites.sh
. You may have to make this executable
(e.g. with chmod +x install_prerequisites.sh
).
build with: make -j2
run with: ./comm2osm /path/to/navteq/data/ output_file.{desired-output-format}
e.g.
./comm2osm ~/navteq-testdata/ ~/navteq-testdata/routable.osm
to produce
an XML file
or ./comm2osm ~/navteq-testdata/ ~/navteq-testdata/routable.pbf
to produce a PBF file.
If you want to test this program and you don't have data of your own you may get sample downloads from the following list:
no_straight_on
. To do this
correctly, we will have to check the direction of the geometries. This is
currently not implemented because the correctness is not guaranteed and the
router only uses the information to show the correct traffic sign to the
user. The actual turn restriction will be respected. In Navteq the z-levels are applied per node. In OSM z-levels are applied per way. Hence the data must be converted from the Navteq style to the OSM style. This simplification can lead to the two datasets not being the same. e.g. the following five nodes (with 3 different z level values) would be mapped to the two ways (with 2 different z level values) below:
node---node---node---node---node
z0 z1 z0 z2 z0
|
V
|-----way-----|-----way-----|
z1 z2
To understand the mapping look at the test cases in test_comm2osm.cpp
.
Feel free to add plugins to convert data from other suppliers.
There is only a single real test. More tests are welcome.
builder.add_user("");
Otherwise the buffer is not aligned and
buffer.commit()
will cause a crash.buffer.commit()
you have to be sure that the
builders destructor is called, because osmium alignes the buffer in the
destructor of the builder.When creating objects with tags and/or objects which reference other
objects, you have to create several builders successively.
E.g. to create a relation with tags and members you first have to
create a RelationBuilder
, then a TagListBuilder
, and then
a RelationMemberListBuilder
.
It is crucial that the destructor of the TagListBuilder
is called
before the RelationMemberListBuilder
writes anything to the
buffer, otherwise the buffer may not be aligned.
The easiest way to call the destructor of TagListBuilder
is to
make the TagListBuilder
go out of scope.
(see process_admin_boundaries()
in navteq.hpp
)
If your program fails with: Assertion buffer.is_aligned()
failed, then you have probably fallen for one of these pitfalls.
Testing is done with Catch. Currently we are using this Catch fork so that eclipse can process catch.hpp correctly. Also see this pull request. As soon as eclipse fixes this issue you may switch to the Catch master branch.
If you run tests from terminal use the project root directory and call it with:
./tests/navteq_test
If you run tests with eclipse simply execute the test-binary.
Tests are currently only covering the z_level
mapping from Navteq nodes to
OSM ways.
z_level
More tests are welcome.
morituri is licensed under the GNU General Public License v3 (GPL-3). See LICENSE.txt.
morituri was developed at Geofabrik as part of the TOTARI project, which is sponsored by the German Ministry of Education and Research (Bundesministeriums für Bildung und Forschung)