Unwanted road types when using import.sh about barefoot HOT 4 CLOSED

Is it possible that you have imported an older dataset before where the road wasn't under construction? If so, it could be that you have an old version of the bfmap file that is used by the matcher instead of the new map version from the database. If you just delete that file, the matcher will read the new data from the database and the road should be ignored if it's under construction.

EDIT: I just tried myself and the mentioned road (http://www.openstreetmap.org/way/408473772#map=13/-30.6873/152.9470) is not included in the roadmap even with the standard road types configuration. Let me know if it's still not working for you. Note that roads for map matching are (split into segments) in the database table "bfmap_ways" while all the osm ways of the area are included in the "ways" table which is just the standard dataset that is imported with osmosis.

from barefoot.

Hi again, sorry for the delay in responding.

The road is brand new (so it was never not under construction) and I only downloaded the data about 6 weeks ago, but to see if it was merely an error in the old data I removed and purged the docker container and then created it again with a new geofabrik extract.

But unfortunately I've come across a new error which has prevented me from seeing if the new extract worked. Since I'm concerned with the roads, my processing script takes the road id and converts it back into a gid (by subtracting one if odd, and dividing by two), and then matches it against a a list of gids and osm_ids I exported from the the docker container using psql (ie \copy (select gid, osm_id from bfmap_ways) to gids.csv with csv). This worked perfectly with the prior extract, but when I try to match this time the process is awry. Matches are clearly wrong, but also a large number of the gids calculated from the ids barefoot returned are larger than any gid in the table exported from the docker container. For instance, with one vehicle barefoot returns 1916 distinct road ids (including imputed ones on the routes) that transform into 1488 distinct gids, of which 472 are higher than 2203202, which is the length of the table exported from the database.

I'm not sure how this can happen, or why it is only happening now. The only changes are a new extract, with new table export, and updating barefoot to the latest version whilst preserving the changes I made to return road ids.

--edit--
On a whim I tried the old table I exported and the merge worked - even though the export from the bfmap_ways table in the container I had used for the matching (at least thought I was doing the matching) was not, and even though the old container was purged. I'm bewildered but next week I'll try to sort out this to make sure I'm matching on the actual current data.

Thanks for your patience on this!

from barefoot.

Having successfully cleared out caches etc I have concluded this is was a data issue (mainly inconsistencies between different forms of the data and a misshapen shapefile) and the import script was working correctly.

Feel free to close this, and thankyou dearly for your time nonetheless

For the record, barefoot was matching to this osm_id http://www.openstreetmap.org/way/345717453 which is clearly not under construction, but in prior data which was the basis for my shapefiles this osm_id was associated with the entire in construction bit.

from barefoot.

Glad to hear that it worked out. Thanks, anytime again!

from barefoot.