You are correct and that is what I get for madly rushing this out in the middle of a sleepless night. I have revised that to:

First, the OSM terms/tags of footway and path are not really used in my dialect of English. Second, OSM tag names and values are more code words, somewhat based on UK English, with OSM.specific meanings. It might be easier if something like “h1” were used as a value rather than, say, “trunk”. Then the baggage of your own local dialect of English would not get in the way.

OpenStreetMap is not a monolithic thing that “refuses to remove the once marked path”. It has contributors that map what they see fit to map. Sometimes they map things that should not be mapped. Or map things incorrectly. But you can fix these yourself.

If a path does not actually exist, then you should remove it.

If there is a path but it is illegal or unauthorized, then tag it with access=no and informal=yes. By leaving it in the database but tagged so no one uses it you avoid an issue where an “armchair mapper” will add it back in because they see in on some aerial imagery.

On that video it seems it took a year from the OSM edit until it showed up on the car’s nav system. To me that means either Tesla is really, really slow at pulling in new data from OSM or that Tesla is not using OSM data at all.

To your question about keeping speed limit data accurate and current: It is typically done by volunteers and you know your area best. So when you see a speed limit in OSM that is wrong you fix it as soon as you can.

I use either OsmAnd (which has a monthly release of new maps) or maps.me (which has an irregular release of maps but is usually about once a month) so from the time I see something I fixed get updated can be from a few days to just under two months depending on when I made the change and when those organizations pull data from OSM.

The GPS on my old low end Android phone was horrible too. I ended up getting an external Bluetooth GPS and pairing it with my phone. It gave me much faster time to first fix and much more accurate tracks for mapping. You might want to look into that as it is probably cheaper than getting a newer higher end phone with a better GPS.

I don’t know where you are located but here is a search on the US version of Amazon: https://www.amazon.com/s?k=bluetooth+gps+receiver

I got the cheapest Dual model as I didn’t want to waste too much money. Only GPS, no GLONASS, etc. but it did the job. I’ve moved on to a high end phone with a good GPS but I am keeping the Dual Bluetooth GPS just in case. . .

Concur with impiaaa: The general rule in OSM is to use the long form. There is a one to one translation from the long form to an abbreviation. But the reverse, trying to get the long form from an abbreviation, can sometimes end up as a more error prone many to many problem.

Also, at least in the US the post office is not the official arbiter of the name of a street. The official name is set by the city or county that has jurisdiction for the area. The post office then munges that into something they like to deal with.

And the post office might not have it at all. In at least two places I know there is no local mail delivery, everyone picks up their mail at a post office box. However the streets have names and the houses on those streets have numbers all of which are used by emergency services.

It would not surprise me if other countries work the same way.

@Richard I just searched for what a voie verte is. Looks like you have the same type of problem in France with that as we have in the western United States with trails open to mountain biking. Probably several thousand km as well though I haven’t searched that to establish a number.

In both cases available tagging was pressed into duty where it was not an exact fit. The results being that quite different features now share the same tagging.

I’d suggest that new tagging be developed for both the voie verte and our local mountain bike trails. But the only way I know to do that it on the tagging email lists which, in my opinion, are nothing but a bike shedding echo sphere.

In the meantime, I maybe I could take a guess at the appropriate mtb:scale for the trails local to me. At least that would give a renderer a hint that the trail wasn’t a voie verte.

Really old diary entry but I feel like responding anyway. For background, my focus is on hiking and rendering maps suitable for use by hikers.

To me the distinction between footway and path is about the same as between, say, highway=residential and highway=track. With a footway I make the assumption that it is smooth surfaced and requires no special equipment, I can walk it using my dress shoes if I feel like it. It is probably suitable for pushing a child stroller and maybe even with a wheel chair (though curbs might be an issue). With highway=path I make the assumption that it is unpaved, has a rough surface and probably narrow: I probably need shoes with soles that provide good traction and maybe ankle support.

With regard to your 2013 question of is a way tagged with highway=path, bike=yes suitable for bicycling, in my area the answer it that it is only suitable for use with a mountain bike and if the mapper has the ability to judge it, it should also be tagged with mtb:scale. I would exclude it from consideration for use with a road bike.

I am not a mountain biker so I am not able to judge what the mtb:scale should be on a trail but I can see the signs posted at the trail junctions and see whether bikes are allowed or not. So I will be one of your villains, tagging some trails with highway=path, bike=yes.

Specifying a format string for how to display names in an area is an interesting concept. I will have to mull it over for a while to consider the implications. On first glance I like it. . . It seems to address the issues I’ve come across while trying to render names. But I’ve found my first impressions on how to do things often run into edge cases, thus my need to mull it over.

I can see where a proposal like that would be met with, to say it politely, “insufficient support” on the tagging email lists. I’ve pretty much given up on those lists, way to much opinionated noise and very little actual thoughtful discussion on defining changes to tagging to meet actual needs.

Sure. I am unaware of the mechanism for adding https://retiredtechie.fitchfamily.org/category/openstreetmap/ to http://blogs.openstreetmap.org so someone else would have to do it.

But I have no objections. I’ll just have to remember that if I categorize something as OpenStreetMap it will automatically show up elsewhere.

I guess the trade off is time spent loading the database if you decide to change the LUA script versus time rendering a map if you do the logic in a Postgresql stored function.

I used to have a pretty custom osm2pgsql.style and found it a pain if I wanted to use a “new to me” tag. So I have recently gone to using the tags hstore for accessing things not in the default osm2pgsql.style. That allows a bit faster turn around time if I want to test some new rendering.

But maybe once I’ve settled in on a way to handle tags it might be worth moving the logic from the mapnik XML style and/or Postgresql stored function to a LUA script to speed up production of final PDF print maps.

What toolchain are you using for this? It’s quite possible that whatever it is it it’ll support some sort of tag transformation (like OSM Carto does, for example).

My own. Several years back I was responsible for creating a properly scaled printable ski trail maps for a back country winter recreation area. The map it was replacing was one I created on a drafting table back in the early 1990s. Looking around, it seemed the tool chain associated with OSM was the way to go. So I collected trail GPX data, etc. and added the data that was deemed public to OSM. The non-public data went into a separate local data store. I created some scripts that then took our private data, the OSM data for the area and DEM data to create a series of printable maps. Maps varied based on print size, scale and whether or not they showed our non-public data.

When the government agency I volunteer at asked if the maps were compatible with the app they use for other purposes and that app happened to be Avenza which can use geo-referenced PDF files. So I figured out how to extend the PDF generation in my scripts to support geo-referenced PDF creation.

The tool chain consists of bash scripts to pull OSM and SRTM data from the correct sources based on where I want to have a map. The OSM data is loaded into a postgresql database that has the postgis extensions. Then a python script that generates some location specific OSM formatted data, calls various gdal libraries to generate hill/slope shading and topographic contour lines and uses mapnik to generate an image file, etc.

With that tool chain as a foundation, it was pretty easy for me to create one of my own to create topographic maps styled similar to the older USGS “quads” that I learned to use as a child. One reason for creating my own is the current USGS “quads” are computer generated but use a commercial data source for roads and trails that has pretty poor quality in rural areas. By using OSM data I can get a better quality map and can have an updated map within a day or so depending on if my edits make the daily cut off for the OSM extraction generation done by geofabrik.

With respect to “tag transformation”, I’ve got some postgresql stored functions that do the heavy lifting to take the name, name:en, alt_name, alt_name:en and ele tags to generate the name value used by the mapnik XML.

You certainly can do tag transformations in OsmAnd, and if you create the maps yourself you’ve essentially got full control over what the offline map looks like. The user interface is still OsmAnd though which is not to everyone’s taste.

I actually do use OsmAnd. And I’ve created customized render files for it too. But I don’t know how to do is create foot based contour lines in OsmAnd. I’ve trained myself to be pretty good at working in kilometers for horizontal distances as the search teams I’ve worked with all use UTM for coordinates. But my old American brain has trouble dealing with meters for elevation. Yeah, 3 meters is pretty close to 10 feet but doing a mental conversion in bad weather when you are tired is something you want to avoid.

Since I already had a tool chain for creating printable PDF maps and those maps, once geo-referenced, work well in the app that I am used to using when doing my volunteer work, I prefer to go that way most of the time.

Back to the tag transformation: The issue I was trying to point out is that to create the value for the name string you display, if you can’t rely on the OSM name tag’s value being in the local language you need to know the code for the local language. OSM doesn’t support putting that language code on administrative boundaries and even if it did there are areas with multiple official languages and the on the ground signs could be in one, another, or all of the languages. There is no way for a script to figure that out. In addition, you need to get the desired local language into your postgresql database so you need to adjust the style file used by osm2pgsql for each area you want to support.

FWIW, the microG provides an open source replacement for part of the Google services found on Android phones. The network location provider portion of that uses a plug-in architecture and there are a number of “backends” that you can use including some that use on-phone databases with no communication to any provider.

The one I noticed first was osm.org/way/219699471/history#map=19/43.25774/-2.92482&layers=D Note that name=* was Spanish and changed to Basque with out adding a name:es tag. Could be ignorance on the editor’s part.

Here is the street my hotel is on osm.org/way/157167535/history#map=18/43.26549/-2.93397&layers=D Notice that it once had a name:es=* tag but that was removed in change osm.org/changeset/34758347#map=16/43.2644/-2.9328&layers=D This seems like it could be vandalism as an existing correct name:es was deleted.

Firefox for Android is fighting me: It will only show history on one object. I have to close and clear all storage to get history on another object. An then I have to open KeePass again to login here again as clearing Firefox loses the login. Sorry about that, otherwise I would dig up more examples. Almost wish I had brought my laptop on the trip. . .

Spouse’s Marshmallow phone with stock ROM from vendor only allows one language to be specified. I wonder if the multi-language system setting ability is a generic Nougat feature or specific to crDroid and/or other Lineage based ROMs.

Playing around with my Android crDroid 7.1.2 settings, it seems I can specify more than one language and can sort their preference order. If Maps.me will honor that I think it would solve the display issue.

Unfortunately, it seems name:es=* are missing for this area so l see no effect on map display when trying various system settings.

I don’t recall the ability to specify multiple languages in the system settings before. Maybe it is new for Nougat. I will have to check my spouse’s Marshmallow phone to see if it can do that too.

Good to know that if I change my phone language in the system settings Maps.me will honor it. But that would make everything else on my phone miserable to use as I don’t know very much Spanish. So I’ll have to set and reset that every time I go into Maps.me which is not very her friendly.

I am hampered by only having a mobile phone, not JOSM. I haven’t looked at all streets and am extrapolating. . .

The street that I looked at most closely is/was Calle El Perro (Spanish). It was changed by 36092421 to Txakur kalea.

Another example, unfortunately I am having difficulty with my phone’s browser, might be Alameda Recalde (as shown on a cash receipt) but shows as Rekalde zumarkalea on OSM. That might have a name:es=* tag but my phone is refusing to show me the data.

“I would be a little more cautious of leading abbreviations like Saint.” Definitely! My impression from this exercise is that you should be cautious expanding any abbreviation. In this case I decided to check each expansion against the full names of nearby streets to see if any matched. If I had a match then I assumed the expansion was okay. Those that did not match near by streets were logged for separate examination.

Just noticed this from an email on the talk-us list. A couple of items:

Comment from rayKiddy on 25 August 2015 at 20:13 “I find Sunnyvale to be fairly completely mapped. But I may be missing problems with the data.”

Thank you! Most of the area from Central Expressway to the southern border of Sunnyvale and from Bernardo to a bit east of Sunnyvale-Saratoga I did by walking about. Many missing businesses as my focus was on getting house numbers, verifying speed limits, etc. matthieun has been covering much of the northern part of Sunnyvale and on over into some of Mountain View. I haven’t met him in person but we have exchanged messages and he seems to be doing a great job. Between the two of us, I think Sunnyvale is in much better shape than many other areas in Silicon Valley.

Back to the topic at hand: I think this area is/was a “Tiger Desert” but the fact was hidden by the imports like that of land use (I think mostly by SteveA). It seems like every street I looked at has needed at least a little tweaking. And when I visit some area I typically check OSM to see what the data looks like and find that updates are needed. Just yesterday I was in the west side of Santa Clara and all the roads in that area were listed as unreviewed, had some alignment issues and were devoid of such niceties as maxspeed tags.

Regarding highway tagging, my rule of thumb is to look for painted center lines. If it has one then it is at least a tertiary but if it is lacking then it is most likely a residential. I have no clue if that matches the federal highway feeder classifications or not, just what it looks like on the ground to me compared to what I read in the OSM Wiki.

Within a few months I will be moving out of the area and the city I will be moving to is also basically a Tiger desert. More fun and starting from scratch with plenty of more streets to walk gathering information!

Don’t follow diaries very much but saw a link to this on the talk-us mailing list.

I agree with your road classifications with one exception: If there are “a reasonable number of what look like houses” along the road (judgement call) and there is a name on the way then I leave the tag as “residential”.

My way of finding them in places like the desert of Southern Arizona is to simply look at the map displayed at osm.org/ and see if it shows roads. If it does, chances is that it is in error. They are probably ranch or mining tracks or the disturbed earth over a pipeline (which also might be a track). Zoom in and with satellite imagery go to town. A fair chunk of southern Pinal County has been cleaned up that way.

The other way to find things more locally to where I currently live is to make a topo map (my own scripts) of an rural area to hike at: Most of the “residential” roads show up like a sore thumb and I can survey the area on the drive to or from or while hiking.

Do look at http://184.73.220.107/battlegrid/ for another way to find suspect areas, though seems that is more focused on finding new roads and developments.