Missing Roads in pannet_osm Database

Missing Roads in Database
I have been using the osm.xml style sheet, mapnik and a little C language programming to render maps on a laptop. I travel the smallest roads and tracks in the US western deserts and while proving the system I noticed many ‘highway-track’ (may be others?) size features not appearing on the renderings. These features appear on earlier versions of the osm renderings and I have older opencyclemap renderings that show the features. They are definitely roads on the ground and mapped in some database someplace. You can see them clearly from google earth and drive on them if you go slow.

I built my gis database from http://download.geofabrik.de/ extracts using osm2pgsql. I used openstreet-carto for symbols and styles. Now I know the most likely cause of the issue is “The guy got it wrong.”, but I think I the test technique down right.

My test procedure is to choose a feature on the map at a high zoom, a dotted brown line for example, then Select that feature from the database using:
SELECT * FROM planet_osm_line where ST_Intersects (way, selection area box) is true
Thus I could identify the brown dotted line is a ‘highway’ ‘track’ and then find where that entity is processed in the osm.xml file at various zooms. As I was increasing zoom up I saw that features that appeared on a zoom layer (from a previous rendering) no longer appeared on the new rendering. ‘track’ features are the most often gone. Examination of the data in the database using ST_Intersects (…) confirms the data are AWOL. This appears to be the same for data extracts from weogeo and everybody else including new opencyclemap online renderings.

I looked in database tables planet_osm_line, _point, _roads and _nodes for where the missing features may be hiding, but no luck. I know these little roads and tracks may look insignificant, but here in the desert they are often the only way to get some interesting places so being able to find them is valuable.

Do you know:
is this a new computer program that generates the map data? If so it is maladjusted and needs to be reported; to whom?
Is there some table where additional roads and tracks are kept. A planet_osm_justwhatImlookingfor table?
Is there some place where one may extract past planet_osm archival data?
Got any good ideas?

Thanks
RickBrown in Reno, NV

I think we have two key questions here:

  1. Are the desert ways you mentioned contained in your database? How can you prove it? How are thy tagged?

  2. Are these ways considered by the rendering style you are using in your own software stack? So tell us about your style file in detail!

When you have your raw OSM data in a database, you can even try to render that data via http://wiki.openstreetmap.org/wiki/TileMill or some other rendering program … with a style that shows every way/track/path.

“””””””””
I think we have two key questions here:

  1. Are the desert ways you mentioned contained in your database? How can you prove it? How are thy tagged?
    “””””””””

Not in daatabase…

Notice the point on the Surprise Valley Road at -119.8300 40.4877
Expand a search box about that point and convert to mercator

gdaltransform -s_srs WGS84 -t_srs EPSG:3857
-119.8362 40.4930 upper left
-13340104.7626009 4937844.4655386
-119.8200 40.4877 lower right
-13338301.38685 4937068.68460095

Select features that intersect that box

SELECT *,St_AsText(way) FROM planet_osm_line where ST_Intersects(way, St_SetSRID(St_MakeBox2D(St_SetSRID(St_Point(-13340104.76, 4937844.46),900913)::geometry, St_SetSRID(St_Point(-13338301.38, 4937068.68),900913)),900913)::geometry) is true and waterway is null

Notice osm_id 14370117 The Smoke Creek Road
Notice osm_id 14383069 The Surprise Valley Road
and 14378965 The unnamed track to the north.

There are also several tracks in the vicinity of that point that do not show in my version of the database. I will send to you a pair of screen shots ( when you tell me how you want to get them) that show a older version of an opencycle rendering that shows the tracks and a newer version that does not. Those were rendered by the opencycle.org and so get my style and database files out of the picture.

Also, using google earth look at point -119.8424 40.4682 and notice the road going north west toward a ranch and beyond. That road shows on the older opencycle maps, but is not in the database. That road also shows on the USGS Kumiva Peak 1:100,000 quadrangle. There are similar issues in many places.

Thanks fgor your interest.
-Rick

This appears to be the area
40.4877, -119.8300 http://www.openstreetmap.org/search?query=40.4877%20-119.8300#map=13/40.5006/-119.8277
Cycle layer http://www.openstreetmap.org/search?query=40.4877%20-119.8300#map=13/40.5113/-119.8337&layers=C

40.4682, -119.8424 http://www.openstreetmap.org/search?query=40.4682%2C%20-119.8424#map=15/40.4671/-119.8429

Looks like vandalism to me
http://simon04.dev.openstreetmap.org/whodidit/index.html?lat=40.4682&lon=-119.8424&zoom=12&layers=BTT&age=1000

Bummer about the vandalism. I expect you will also find damage at around -117.5 41.5
I down loaded the geofabrik extract I was working with on 07/17/2014
call on me if I can help.
-Rick

If you select one of the red squares from my previous bottom link, then select the ‘A’ link, you will be shown what was altered.
It appears the original data may be related to a ‘tiger import’ which in many respects was deficient, so I am told, and generally requires further editing. We don’t have such data in my country so I don’t know anything about the problems.
If you are traveling over these roads, I suggest you are in a very good position to judge what is on the ground, and how it should be mapped.
Have a close look at the edits and if you think the latest edits are deficient or worse, and a large portion of the edits need to be redacted (returned to a previous state I guess), then contact the Data Working Group http://wiki.openstreetmap.org/wiki/Data_working_group and get some advice from them.
But if you decide what has been done seems to be generally agreeable, then you may be able to do further edits on the current data to bring it up to scratch. Many people try to do their best with only the satellite imagery to guide them, and these edits often need further editing from the ground truth of someone like you in the area.
If the tracks exist on the ground they should not be deleted, but it is important that they are tagged correctly.

Darn! I think vandalism would have been better as easier to fix.
Tiger data, while not perfect, at least tells you more than nothing. The person who removed those tracks may not have been familiar with what is considered to be a road by a Nevada dessert traveller. A quick look at point -119.8424 40.4682 with google earth shows a real road that goes to real places and is shown on usgs maps. Removal of that track suggests heavy handed editing and such appears to be wide spread. The little group of tracks at the location I used to demonstrate the issue draws attention to a historic ranch that once operated there. See the photo on google earth. I agree those tracks do not look much like roads, but they are significant.
I petition to have the entire set of changes done by SimMoonXP around December 2012 reversed as they reduce the value of your product. I’ll follow your link and present my case to the Data Working group.
Congratulations for the amazing technology and group of people that you have brought together as openstreetmap.org
-RickBrown

Heavy handed edits and changes by SimMoonXP? That doesn’t sound very friendly.
I’ll just change my petition to “please restore the tiger data to the database”.
Thanks for any forbearance
-Rick