Cycleway ways are not being imported under some conditions

[ja3n]

Under some conditions, cycleways e.g. <tag k="cycleway" v="lane"/> are not being imported into the ways table. Since most cycleways are tagged to ways that are also tagged as highways, this is not a critical issue. However, if you associate costs with class_id's this can be a problem.

I've attached two osm2pgrouting config files: mapconfig.xml and bikes.xml. If you run osm2pgrouting with the bikes.xml file, cycleways will be imported into your ways table. if you use the mapconfig.xml file, you get highways, but no cycleways.

[ja3n]

mapconfig.xml (cycleway types missing)

[ja3n]

bikes.xml (cycleway types imported OK)

[ja3n]

Another example of this problem is where you have <tag k="highway" v="footway"/> and <tag k="bicycle" v="yes"/> on the same way. osm2pgrouting keeps the <tag k="highway" v="footway"/> tag, but does not keep the <tag k="bicycle" v="yes"/> tag. So you lose the fact that some footways are accessible by bicycle.

[ja3n]

It looks like when osm2pgrouting calls pCallback->EndElement? in these cases, the class and type are empty. I get a bunch of output that says "We DON'T need a way of type and class ".

[ja3n]

I spent a little time on this over the weekend.

The current implementation of osm2pgrouting accepts the first acceptable tag as the class_id for the way. That makes some sense, but is not ideal if you derive routing information from multiple tags e.g. bicycle=yes is really only useful in combination with other tags. For example, a way with highway=motorway and bicycle=yes means something completely different from a ways with tags highway=footway and bicycle=yes.

I created a version of osm2pgrouting that works a little better for my case (where I want to preserve multiple tags per way), and may work better for others too. It creates a way_tag table that maintains relationships between ways and the type_ids and class_ids.

Then I can do selects like:

UPDATE ways SET facility = 'I' 
WHERE gid in (SELECT way_id FROM way_tag 
WHERE class_id = 202 OR class_id = 414 or class_id = 417 or class_id = 419 or class_id = 420 or class_id = 305 or class_id = 413) 
AND gid in (SELECT way_id from way_tag WHERE class_id = 101 OR type_id = 3 or type_id = 2);

The SQL above basically sets a bike facility type (which is something I add to my table after running osm2pgrouting) that must match more than one class_id or type_id. I use this bike facility type in future routing calculations.

I'm not sure if I am able to create a branch off of trunk in svn, but I'm happy to do so (or to otherwise provide this version to Daniel or someone else for review).

Note that I've also incorporated Ticket #208, and made a couple minor changes. 1) I made the name field in the ways table character varying(200) rather than char(200); 2) I checked tables using IF EXISTS before dropping them.

[ja3n]

Patch to add way_tag table (works w/ trunk revision 357)