Unwanted nodes created on import

[josh-mccord]

Hi,

I'm finding what appears to be an import bug when I try to create a network using the "for cars" config file. The imported network creates nodes at crosswalks despite being absent from both the config file and the configuration table in the schema.

I'm running PGR version 2.5.2 on PostgreSQL 10.5/PostGIS 2.4.4 for Windows 7 x64.

[cayetanobv]

Hi @josh-mccord ,

Could you copy/paste your the bounding box of your example to test this issue? What is your osm2pgrouting version?

Thanks,

[josh-mccord]

Hi Cayetano,

I'm running osm2pgrouting version 2.3.4.
Bounding box is: [ -88.02172, 41.70033, -87.92858, 41.75897 ]

Thanks!

[dkastl]

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

[josh-mccord]

Hi @dkastl,

For clarity, the steps I'm taking for network creation are:

1. download the Illinois state pbf file from https://download.geofabrik.de/north-america.html
2. using osmconvert.exe, extract the area of interest with a .poly file from the downloaded file using the following tags: --drop-broken-refs --complete-ways --complete-multipolygons --complete-boundaries --drop-author --out-osm
3. using osm2pgrouting.exe, import the extracted data into postgres with the clean import tag and a slightly modified config_for_cars.xml file (commented out some road types)

I believe I misspoke when I wrote that osm2pgrouting creates the specified nodes - these nodes exist in the OSM data and appear to be intersections of highway:residential and highway:footway type ways. The nodes at the intersections generally appear to be either highway:crossing or unset.

[cayetanobv]

Hi @josh-mccord ,

I've reviewed your issue loading your dataset and I think you are right. Nodes which are placed in the intersection of two ways, and one of them is filtering with XML config file, should not be imported as ways vertices.

We need to review importers to avoid this issue.

Thanks for reporting it.

What do you think about this issue @dkastl @cvvergara ?

[dkastl]

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 applied after new nodes have been created? Then it's probably the order of how data is processed, that is wrong, and we should first apply the filtering and after that create nodes, where nodes are missing.

In case the nodes are there, because they were part of the original OSM data, then I wouldn't say this case is wrong? I don't think the importer should remove unnecessary nodes and merge ways.

[jourquin]

Hi,

In the following example (see picture), I've tries to create a routable network with the main roads (highway = motorway*, trunk* or primary*) for Luxemburg. As you can see, osm2pgrouting creates a lot of vertices, as one is created at the begining and end of each network chunk. However, many of these chunks could be merged (at least if they have identical characteristics, which is most often the case). Therefore, if a vertice is connected to (excatly) 2 ways, and that these ways have the sames characteristics, both ways can be merged into a single way.
Is there anyway to achieve this ?

[dkastl]

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 could be also intersections of ways, that are excluded from export. Or there could be attribute changes, which lead to a different road segment.

You can use PostGIS and PostgreSQL queries to itentify records where exactly 2 road segments have the same source or target ID. If they also have the same attributes, you can then ST_UNION them into one.

Or you can try the new network contraction functions to apply linear contraction on your network. But these functions are still marked as "experimental": https://docs.pgrouting.org/latest/en/pgr_contractGraph.html#pgr-contractgraph

[jourquin]

Thank you very much for your quick answer. These chunks are indeed present in the original data and many of the unneeded vertices correspond to intersections with smaller roads (not exported).
The resulting graph is, however, too complex for my needs, and I'll try the two options you suggest to simplify it.

[cvvergara]

Hello @josh-mccord
The configuration file is about edges not nodes.
osm2pgrouting what it does:
suppose the following 3 line geometries saved in OSM:

X------*------*------o------*-------o------X-----X-----o------*-------o------X

where X, *, o are nodes and:
X are start/ending vertex of a geometry in OSM
o are node used in 2 line geometries that intersect in the o node (basically a road intersection) or ha is a "point of interest" that is, that has more than lat/lon information.
* are nodes of that only belong to one line geometry

So for the example above:
The pgRouting, topology that is generated for routing will be

S------*------*------S------*-------S------S-----S-----S------*-------S------S

Basically, node used in more than one geometry, are used to create the routing segments

Details:

For the first OSM geometry:

X------*------*------o------*-------o------X

it will generate the following pgRouting segments

S------*------*------S------*-------S------S

For the second OSM geometry:

X-----X

S-----S

For the third OSM geometry:

S-----S------*-------S------S

For your image example: (which does not show the nodes that make up the complete geometry)

            X
            |
            *
            |
            *
            |
            x
            |
X--*--------0--x---*----X
            |
            o
            |
            *
            |
            X

The unwanted nodes might be endpoints of geometries or have more than lat/lon information, therefore the topology will include them.
If you don't want that, you can modify the topology as explained above by Daniel, as it would be too complex to go and modify the OSM data.