I ran into similar issues with descriptions instead of names in the name field of relations in California about 4 years ago. I am not sure what the long term solution is to nudge mappers to make names on hiking routes match the signage on the ground.

Maybe if more renderers actually processed the information on hiking route relations and just displayed what was there the visual noise would get mappers to clean up their areas.

But I’d rather my maps be clean now, so I punted and preprocess away most of the stuff that annoys me before actually rendering my maps.

There are ways to keep things local if you do your own rendering. And there might be sites that allow fictional data. But if you want an informed answer to this question then I believe you should ask on the OSM forums at https://community.openstreetmap.org as you will get a lot more eyes on the question than here in the diary area.

The Americana map project at https://americanamap.org attempts to display the map in the language of both your browser and of the language of the place. Not all locations have foreign names in addition to local language names but many do.

To verify that the browser language is used, I configured a browser to have German as my first choice language and pulled up the Americana Map and the place names for countries and major cities showed up in German.

I think this capability may come to the main map at osm.org/ when it transitions from raster tiles to vector tiles. You pretty much need vector tiles with the map data being rendered by the browser for this to work well.

Thank you for the time and effort this took. Looks like a good job of mapping to me!

I don’t know how may projects render camping data or how often they update their copy of OSM data, but one of them is Open Camping Map

GDB is a new one for me. It is apparently a ERSI database format.

Apparently the fine people on the GDAL Project have a driver that will read GDB files and it looks like the ogr2ogr command line tool should have that driver so it might work.

My first attempt with ogr2ogr -overwrite -f "ESRI Shapefile" -t_srs EPSG:3857 Export.shp Export.gdb.zip had an error hitting a 2 GB file limit for SHP files. The lines (streets) portion was okay but the error was on the points (address locations).

Several trials failed where I tried clipping the destination by lat/lon or by a “where” clause to select Lancaster. There is probably a way to do it but I have not figured that out yet. The bounding box in the destination is not in lat/lon but some other internal scheme apparently so I don’t know the numbers to use. And the examples show that you can use a SQL like “where” clause to filter data. But the fields shown by ogrinfo for the database come up with “unknown field” when I try to use that in ogr2ogr. Undoubtedly something I am doing wrong in my ignorance.

Final trial was to output to a CSV file. But that only got me the lines (streets) and not the points (addresses).

Anyway, I think it should be possible to get that ERSI database format into something usable in JOSM and OSM but I have not yet found it. I am out of town on travel at the moment, when I get home I will probably poke at it a bit more.

Even if I can get the GDB file into something that can be loaded into JOSM it will need to be cleaned up to use the OSM tagging. I have some scripts that do the lions share of the work which I can give you if we get that far.

What format is the file in?

The open data plug-in for JOSM can directly load a large number of different formats without having the data being converted by some external script.

What I did for the SHP file for Orange County was to use the open data plug-in to load it into a layer in JOSM. Then I exported/saved that layer in OSM format which I am more familiar with. Once in OSM format I converted the tags the county used to those used in OSM (a pretty simple script). The more complicated part was conflating/merging the county data into OSM.

If you can give me a link to where you got the file maybe I can see how to process it for you.

Your link does not appear to have a download associated with it. I browsed to the next level up in the Lancaster GIS web pages and did not see a data set that looked useful for addresses. An email query to the GIS department might be a good next step.

I am in Orange County and the way it works here is the city assigns an address but they then push it up to the county level. I found that out when I had to correct our home address with the US Post Office (the PO gets their addresses from the county). I suspect that is pretty standard so it is possible that the LA County GIS department might be a better source.

I see a number of possible datasets on the LA County GIS website so you might be able to find a dataset there. I found a number in shape file format that showed commercially zoned land complete with addresses. There is a plug-in for JOSM that allows you to load shape files so that is possible. But I think you are looking for a data set that has residential addresses.

I did a partial import of addresses for Orange County using a properly licensed data set from the county’s GIS web page. My import description is at osm.wiki/Orange_County_Building_and_Address_Import

I never finished that import because I ran out of steam though I did get all the southern part of the county done which is where I usually need to travel. There is a lot of time and work involved if you want to resolve ambiguous or duplicated data.

Thank you for your efforts, I agree that house addresses are very important to get into OSM.

What format is the data from the Lancaster GIS department?

There are some tools that make conflating/merging address data into OpenStreetMap easier. Never totally easy, at least in my experience, but enough easier that a month should get you more than 5% done.

Nice work!

I think this will give some mappers the goal of focusing on those areas.

I agree with Ivanbranco that the forum is a better place to ask this question.

That said, I map the traffic signals on the road at the actual stop position. See: osm.wiki/Tag:highway%3Dtraffic_signals#Tag_all_incoming_ways

Turns out that JOSM has that layer too. I just never noticed it in the list of available imagery. Thank you for the tip on using it!

Do you know of a way to use this USGS 3D Elevation Program as a background layer in JOSM?

Impressive research and list. I hope it can be moved from your user specific area and made a general wiki page.

From a world wide point of view there may be legal issues.

But mvexel and I are both in the United States. If I understand the situation correctly, every state in the United States has decided that still and video photography in public spaces (public roads are public spaces) is okay. And no state has restricted dash cams or dash cam videos.

A number of states have laws about recording conversations. If the dash cam is set to record audio, even if only inside your own car, then you better check out your state laws.

A postscript on my previous comment: It is possible to script the catenation of your video files with ffmpeg and you can create a single GPX file from multiple files using gpsbabel. That might be a way for you to make your Mapillary uploads easier.

I did a little video experiment using this type of scripting a while back and documented it on my non-OSM blog.

Good to see there is another way to do this than what I found. I will give your method a try some time.

I extract the GPX data from my Viofo A119 dash cams using a script called nvtk_mp42gpx.py

It might also work on the A129 series if they use a similar Novatek processor.

In my case I sometimes use the GPX to make movie animations using GPX Animator but mostly use it along with a home brew set of scripts to create sequences of geo-referenced photos for use in JOSM.

Sounds like you have a found some good things to clean up.

I see you have “genus” as a translation of “type” but you should be aware that “genus” is a valid tag for tagging plants so you may want to refine that one a bit more. Maybe if you find a genus=* tag without natural=* and/or other associated tags like species=* they could be candidates.

I think you are referring to GNIS feature ID of 1412420.

The way I would approach this is to put the official GNIS (Dena’ina Athabascan) name into the name tag. I don’t believe straight translations of names should be used unless they are actually used by locals to describe the feature. I suspect in this case the locals will either use the officially approved Athabascan name or the old Anglo name (much like Denali vs McKinley). But if someone insists on a translation it would probably go into the name:en tag.

I would probably also put the previous name into either the alt_name or old_name tags. It probably wouldn’t hurt to put the official Dena’ina Athabascan name into the official_name tag.

For what it is worth, you can download the GNIS database in a text format easily converted to spreadsheet at https://www.usgs.gov/u.s.-board-on-geographic-names/download-gnis-data but when I looked at the Alaska extract the most recent update was made over a year ago and it does not contain this change.

If we were talking about a simple set of points with addresses you might get away with the data can’t be copyrighted in the US.

But addresses are typically bound to plots of land which have a shape. And in this case there is a desire to import building outlines which are, again, shapes. I think it gets less clear cut here.

Near as I can tell, OSM takes the route that it has to be absolutely clear that the ownership permissions are clear and compatible.

p.s. I see from your intro/bio that you have been doing surveying and mapping in the Patagonia area. It sounds like you are a local. That gives you a big advantage when identifying errors, etc. on an import.

For what it is worth, I mapped most of the “town” (actually only a postal town, not incorporated) of Oracle, AZ during visits with family members there. In a sparsely developed locality like Oracle I found I could walk 5 or so miles of roads in the morning capturing addresses and making notes then spend the afternoon entering the data into OSM. It only took me a few weeks, spread over several visits to the area, to cover most of the town.

When I mapped Oracle I was using an Android phone and an app that could collect addresses very rapidly (not sure the app is still around). I could collect addresses as fast as I can walk, for me a little under 4 MPH. Then, back at my computer I could upload the data then go back and trace in the building outlines. I am currently on iPhone and there is no app quite like that so my current work flow for this is to trace the buildings first then go walking the area with Go Map and use that app to update the buildings with the addresses, name (if appropriate), etc.

I have only done slight revisions in the Oracle area since I did my initial mapping years ago so there are likely changes that need to be captured. But that is a different problem than the initial mapping or import.