Daniel Kastl

It's good to have something consistent, not a different tool in every repository. But personally I would prefer Markdown, because the files render nicely in the Github repository view already...

This is a limitation of osm2pgrouting that has been there from the beginning. With additional swap space you can work around this limitation, though osm2pgrouting is definitely not doing well...

What do you mean with "wrong value"? That OSM contributors used wrong attributes? What would be wrong attributes for example? If there are common mistakes, then we could care about...

Germany is very big, and osm2pgrouting does stop working, when you run out of memory. You could split everything into smaller data files and run osm2pgrouting with each of them...

While I don't disagree, that PBF support is a good idea, it doesn't necessarily solve the issue of running out of memory. It definitely helps to work with smaller files...

@josh-mccord , are you sure, that these nodes were created though osm2pgrouting and didn't already exist before?

I haven't downloaded the data myself, but if there are ways, that are excluded from import, aren't the nodes there already in the original OSM data? Or is the filter...

If there are too many nodes, then this is caused by the original OSM data. This doesn't necessarily mean, that OSM mappers create more road segments than necessary, but these...

It's correct that sometimes you see `gid` and sometimes `id` in spatial datasets, and we didn't really declare one as "default" in pgRouting, probably because pgRouting is supposed to work...

Well, I don't know that well about the `gid` vs. `id` history ;-) But somehow I like in our documentation that we always write like ``` SELECT * FROM pgr_dijkstra(`SELECT...