easiest to do is to build your own PBF from your custom data. and there again, easiest is https://osmcode.org/pyosmium/. needs some intimate knowledge of OSM tagging rules.

Can’t i just convert GeoJson to osm pbf?

Try. In any case, rather a stackoverflow question.

@prabaljainn There have been some tools like https://github.com/tyrasd/geojsontoosm written - the key problem is that you need topology in your data - the lines need to be connected to each other. GeoJSON doesn't have that information in the core format, so it's not usable for routing without being converted to a format that does.

@danpat thanks for these quick responses. Can you please refer me some docs, taking reference I think i have to process my data than do the following

@prabaljainn Probably the best description of the issue is in the documentation for TopoJSON - https://github.com/topojson/topojson

Ultimately, OSRM only knows how to parse OSM-formatted data, either in PBF or XML forms. It is up to you to figure out how to convert your GeoJSON data into usable OSM data.

Most folks that work with network format data do not use GeoJSON for this reason - it is not a useful format for graph/routing applications.

FWIW, neither is a OSM PBF :D

I need to look around some other way to deal with my geojson data. 🙁
Maybe, using Haversine formula to calculate the great-circle distance to trace the path and sum the distance up.

Thanks @nilsnolde @danpat for your time.

@nilsnolde What I meant was that at least topology can be derived from the OSM nodes/ways information, unlike GeoJSON.

All the open routing engines today are basically 50% routing engines, 50% "convert to an optimized format for routing" engines - I once upon a time toyed with making a routing engine that just used OSM data directly, but man, was startup time slow......

Even in GeoJSON you can fairly easily get around that using properties, which ain't pretty but the current protobuf definition isn't either (for routing or pretty much anything needing the geometry or even topology of ways/relations).

I once upon a time toyed with making a routing engine that just used OSM data directly

Hahaha yeah that sounds ambitious. The OSM PBF should have had an official routing optimized schema, so much work and time dumped in each single engine. The idea I'm still toying with is to at least normalize things a bit more for routing engines to e.g. put admin data on the ways, resolve some annoying relations to way info, some sane density derivation, elevation postings to ways etc. I tested the waters with Graphhopper & Valhalla, the interest was semi, which I can kinda understand. No one really wants to be dependent on a data conversion pipeline from a third-party sorta rando OSS project.