There was some kind of selection error in this changeset that moved quite a few nodes that were connected to powerlines. For example, a node that I've just fixed:

osm.org/node/169943625

And a shot of the spot:

http://imgur.com/y8tx6AA

I noticed the same effect with another nearby powerline but already fixed that.

I also noticed quite a few power=tower nodes that had the tag set without aligning the node with a tower. This makes it harder to find unfixed power lines and provides little benefit.

Hi-

Thanks for the updates.

In general, the information in the "ref" tag should not be repeated in the "name" tag. "ref" is short for reference and is used in OSM for short alphanumeric identifiers.

Sometimes a road will have a name that uses the ref, but it should be more than just a combination of the various road numbers.

Max

Hi-

There's a lot of discussion about names and abbreviations, the existing US consensus is to use fully expanded names.

Hi-

Are you making use of the names of driveways like "North Hill Marathon" or "Parking lot road in Papa Joes"?

In general, the 'name' field should not be used to describe the road, and it is okay to leave it blank of there is not really a name.

It is nice to somehow associate the road with the facility and if you are using them for something there isn't any urgent need to change them, but I think most people would not expect service drives to have names.

Thanks,

max

Hi-

The "ref" tag is generally reserved for signed routes. As such, I've removed the "OLD 31" values here. If the route is indeed prominently and officially signed as "OLD 31", it would be appropriate to correct my mistake.

If you added the "OLD 31" values to the ref tag because that makes it show up as little boxes on the map on openstreetmap.org, take a look at osm.wiki/Tagging_for_the_renderer . Data should reflect reality, not be adjusted to get a particular result from one piece of software.

(Similarly, if a route has a ref of "US 31", it is an error to also fill in the name tag with something like "US-31", as that is just the ref, not a name. "US-31 South" would be a name if it were signed as such or well known by that name. The difference is somewhat arbitrary, but there is value in the entire US using similar canonicalizations of information, rather than hundreds of different personal canonicalizations)

Thanks,

Max

Here you left a fixme that said 'quite a big lake - must have a name!'

It's been a while, maybe you've found it already, anyway, in the US, the background layer 'USGS Topographic Maps' is a pretty good source for names of significant bodies of water.

Hi-

Just a couple of pointers for when you are adding sidewalks:

They should intersect with any streets where they cross in traffic (so not bridges), this helps route finding software use the data (most implementations look for an explicit connection). It's not urgent to fix them all up, but they are quite a bit more useful when they are correctly connected to everything.

It's also probably reasonable to keep the sidewalks a bit shorter. Something like splitting them at the mile roads would be a good rule of thumb. This just makes it easier to deal with in future edits, and makes it easier to analyze changes. Another good place to split them is at bridges. Marking the bridges isn't real important for using the data, but it helps error checking tools by making it clear that the sidewalk should not be connected to the road).

Thanks,

Max

Where possible, this should share boundary ways with the international border.

Sharing the ways avoids situations like this:

osm.org/changeset/36510209#map=16/42.3106/-83.0744

Hi-

OpenStreetMap isn't really the place for temporary routes like the 10k you added here.

A nice alternative for making a quick map is uMap:

http://umap.openstreetmap.fr/en/

I've deleted the race route, you can still retrieve it from the OpenStreetMap history. One way is using the query at this link:

http://overpass-turbo.eu/s/fa1

(Click "Run" to show the result)

It'd be nice if you could find a source more authoritative than someones 'own work' on Wikimedia.

There's likely a treaty between the US and Canada establishing what's a lake and what's a river.

Also, if the goal is to match the OSM wiki rules, why waterway=riverbank over the newer water=river?

The data added in this changeset appears to be high quality and has been correctly combined with existing data.

The use of a brand new account to do a single edit and the comment left for the edit appear to be SEO, as there are many new accounts doing the same thing for hotels in the US.

The addition of accurate detail is most welcome. The use of OSM for SEO, and paid editing of OSM that uses SEO tactics are not welcome.

Could you please clarify if this is a paid edit, and whether the person doing the edit is employed directly at "The River Inn" (someone actually working at the hotel would have a better case that they were not engaged in SEO when the left the enthusiastic changeset comment).

If it is a paid edit, it's preferable that such edits be carried out with a single account that is traceable to the company doing the work, and that the account profile make a note of the nature of the edits.

What is the motivation of this change?

The tag combination of highway=primary + NHS=yes communicates exactly the same information you have based the change to trunk on, and the section of trunk that I found to get to this changeset is pretty obviously not a trunk, with dozens of driveways and connections to every mile road.

Putting it another way, a data consumer interested in the NHS can check the NHS tag, there is no great need to propagate the NHS tag into the highway tag.

You've probably found it by now, but the towers for high voltage power lines can be tagged power=tower.

(Here you tagged some with name=High-Voltage Tower, I used http://overpass-turbo.eu/ to check Missouri, the 22 I retagged were the only ones in the area)

Is the way here meant to be a member of osm.org/relation/1411351 ?

I see there are some portions of the counties there that are inclusions in another county, but those should be an inner member of the county they are inside and an outer member of the county they belong to administratively.

Hello-

Please be careful when deleting things. There is some redundancy in place nodes, but people using the data expect them to be present.

(I've just undeleted osm.org/node/316970501 which is the label node for Jackson County).

Thanks,

Max

Hi-

I saw this tweet:

https://twitter.com/tkyjm/status/687319379445444609

and check a bit. Seems Honolulu is the official name?

http://quickfacts.census.gov/qfd/states/15/15003.html

Since it looks like you set several language names, flagging it for your attention rather than making any changes.

I'm sure that gcmap and Wikipedia both got their information from the FAA database I linked, it's just that at some point someone involved with putting the data into Wikipedia thought that the 1010 meters needed conversion to meters.

I think for US airports there is no reason to use any source other than the FAA, unless that source has clearly added or corrected information (here gcmap just replicates the FAA data, and Wikipedia had mangled it).

The ways I have been deleting are (some of) the 'v1' ways listed below. I got here by looking up what changeset they were created in prior to deleting them. There's no question who created them.

Anyway, I contacted you based on the presumption that you cared about the relation being sane (I see your occasional mailing list posts about the progress mapping rails...). I'll continue to fix the blatant errors as I happen across them but have no overarching interest in making sure the relation is well kept. I figured you would want it flagged up is all, I realize that time can be limited and don't mean to demand you do anything.

I mentioned g246020 earlier because they have reused some of the duplication, making it obnoxious to do a mass delete (which would be relatively easy, but spoil their work).

Sorry for the double message, after searching on County/State, the interesting information is at the "Airport Contact Information" link under Reports.

~1000 meters appears to have been more correct than ~300. A good source for US airport information is the FAA:

https://nfdc.faa.gov/nfdcApps/services/airportLookup/airportDisplay.jsp?airportId=nv65

There is a geographic search available here:

https://www.faa.gov/airports/airport_safety/airportdata_5010/

(Under "Location(s) Selection Form", I usually search by State and County, which returns a manageable number of airports).

It also seems that the FAA identifier has been changed to NV65.