I sure wish this redaction had been done by removing the name value and adding a fixme=chdr_USA_AZ_name_fixup_required tag.

That would have been just as easy for an editor to find and fix. Now, two months on, there are still some roads to fix. But anyone trying to us OSM for maps or navigation in the areas affected have had and will continue to have a very bad experience.

Hi!

Welcome to editing OpenStreetMap. I've been mapping in San Clemente and noticed you new contribution.

I think you are trying to show the area you live in but the node you added with the adjacent street name in all lower case is not the best way to do that.

It would probably be better to put nodes on each of the buildings (or draw the outlines of them) and then put some address tags on the. For example addr:street="Calle Cuervo".

If you like, I can either help you learn some of the usual editing conventions. Or, if you like I could meet you and we could work on getting your whole neighborhood mapped better.

I am the one who walked Avenida Salvador near there and added those houses and addresses to the map. It would be great if we could get your neighborhood done too.

Again, welcome to editing OSM!

"I do not understand how having more info in the name field can cause such chaos." -- Because it is not expected and hard for a renderer to remove. If I create a map of an area you tagged this way the elevation will be shown twice (with different formatting). In addition, lots of people do searches with exact matches and they won't be expecting to have to remember the foot based elevation to have the search complete.

Putting the elevation in the name field is flat out wrong. Elevation should be in the ele=* field and the renderer can, if the developer of the renderer desires, be shown along with the name.

Consider that this data and the maps made from it could be used by a person desiring metric elevations. You can easily convert the well defined values in the ele=* field when rendering (I convert from meters to feet for my maps). But converting a value in a field that expected to be text only like the name field is not possible without lots of artificial intelligence.

Basically you are breaking the map for many, many users.

FWIW I render the elevation along with the names of peaks on the paper topo maps I create for my own use. In fact, I render the elevation tag even if there is no name on the peak. Basically the same as the old USGS topos did it. And even though the peak elevations in the areas I've created maps for are in meters, my maps are in feet.

There are some maps that already use the elevation field like http://www.hikebikemap.org That has an international orientation so the elevations are in meters but it does show others care and need to have the elevation in the ele=* tag and not polluting the name text.

Is this railway:position tag for the stop position of trains? If so the San Clemente Pier one seems incorrect as the platform is south of the rail crossing the tag has been added to.

Sorry, not Del Rio, Del Dios.

I need to go over and hike that area sometime. Looks like there is an access path from the end of Del Rio. I took the liberty of adding that just now.

We may want to merge the name you tagged on a single node to be on the park boundary polygon. I mapped that from Bing imagery, so if you are familiar with the area you could probably improve on the outline.

Are you familiar with this area? It would be nice if we had a boundary around it but all I can tell from Bing imagery is the boundary for the scrub which may or may not be the boundary of the park.

An entrance probably ought to be either on the boundary to the park and/or on the sidewalk leading in.

Unless there is something showing an actual name on the entrance, it should not have a name=* tag.

Looking at Bing imagery, I think the new ways would be better tagged as "highway=service". Maybe even way 30819881 should be "highway=service" too.

Next time you might want to want to have your commit comment say you are correcting the spelling of the healthcare:speciality tag.

For those who watch areas we are interested in for changes, seeing a change set that covers a large part of the world with the comment "obvious tagging typos" means a bit of time figuring out what you did and if we agree.

As noted above, it was relation 3291187 osm.org/relation/3291187/history That relation and the ways in it were manually entered based on Bing imagery.

With respect to rendering, I am using my own scripts and Mapnik to generate properly scaled maps for nordic skiing, so I don't need to alter either the forest or Chumash wilderness boundaries in OSM to get green to show, only change my XML style files to indicate that is how I want it rendered.

All that said, it would be nice to have better landcover in OSM and creating it from Bing imagery has issues (hard to tell scrub from trees, slow and tedious to do, etc.). So I would not be adverse to an import if you know of a good source with appropriate licensing. What land cover data do you know about?

After all this time I need to create new paper maps of this area and I find that the outer ways of the natural=wood polygon (relation 3291187) are gone.

Was there a problem with that polygon?

For my immediate needs I guess I could render forest green based on the Los Padres boundary but I'd rather do it based on land cover.

Regarding ways osm.org/way/414505825 and osm.org/way/414505827

These look like the knock out the McGill and Chula Vista campgrounds as well as part of the Chula Vista parking area from the forest. As a volunteer on that mountain that does not seem right to me.

Yes, as near as I can tell both sets of changes were yours which is one reason I thought you'd be able to tell which one(s) were correct.

Actually I don't have more accurate locations: I noticed the issue because Osmose flagged the area. The Bing and Mapbox imagery show nothing there so I can't use that. If you have a map from the developer you have much more information than I. Could you take a look and see which of the duplicate addresses seem more accurate and remove the other?

So it would be alright to delete the duplicates?

Would I be correct in assuming the newer change set for each would have a more accurate position than the older change set? (Without current imagery, I can't tell remotely)

Thanks!

It looks like this change duplicated change set 31069549.

There are lots of seemingly duplicate addresses in this area and the satellite imagery is too old for me to see what the new construction looks like.

Are they really two each of a bunch of these new residential areas?

Most of the objects I have been changing were imported from about or before that time and the changes were to expand obvious abbreviations and assure that the address tags made some sense in relation to the nearby roads. I don't have local knowledge. If you can point me to the specific street and/or street house number affected, I will update. Or, better yet, please make the correction.