Hi woodpeck-

I've just happened across and deleted ~1000 leftover nodes from this import/revert (in 45060146, 45060470). I can't imagine the revert would still be running.

I guess you are probably aware that some nodes get left behind, but it seems like a big enough number to at least let you know about them.

Max

Fixed it. 'namep' was a typo from switching name_1 and name. The address I added used the value in name so I assumed it was the main value but didn't want to delete the other value (counties do often have a secondary system of labeling roads but it would need a survey to know for sure if anything is posted here).

Somebody mentioned https://www.mediawiki.org/wiki/User:Yurik/OSM_NoWD in a discussion and the townships here popped up on the page. It seems that "Susquehanna Township" snuck into the wikipedia links in place of "Susquehanna County".

Just letting you know how I happened to edit the boundaries.

Max

Hi-

I've removed the lake here that clearly doesn't exist. As you are editing please keep in mind that your changes immediately get added to a global dataset with many users.

I've also adjusted an area that you had marked as industrial to be marked as a hospital. It's pretty long, but the map features wiki page is a good introduction to the sorts of things that are commonly mapped in OSM:

osm.wiki/Map_Features

Feel free to reply here or send me an OSM message (click "Send Message" on osm.org/user/maxerickson ) if you have any questions.

Thanks,

Max

\u007f popping up in this changeset.

Hi-

I've changed the first aid stations here from amenity=hospital to amenity=first_aid.

This has the immediate disadvantage that they aren't shown on openstreetmap.org anymore.

The advantages include not having incorrect hospitals in the data and making the need to support first_aid clearer to users of the data (by having more things tagged first_aid).

Anyway, I'm mostly writing to let you know in case you want to change them back to amenity=hospital. I won't change them again.

Thanks,

max

The \u007f character thing has also happened in some of this changeset (I found it at the end of a longer highway and didn't look for more).

Hi-

While working on something else in Garden City and came across some of your edits and just wanted to point you at a couple of resources.

First, consider taking a look at osm.wiki/Unconnected_ways

It has some explanations about editing practices that make OpenStreetMap data more useful. A real short summary is that lots of software won't use things like sidewalks if they aren't connected (by sharing a point) to other sidewalks and streets.

Also consider taking a look at osm.wiki/Sidewalks which discusses an alternative way of marking sidewalks. Either way is fine (there are lots of people doing both) but it can save time to mark streets with sidewalks rather than adding the sidewalks directly.

Thanks,

Max

Hi-

Thanks for the addition.

Did you follow a guide or tutorial that suggested the 'category' tag?

It isn't a big problem, it just isn't widely used in OpenStreetMap so people using the data likely won't use the information.

I've added some information, the more used 'amenity=nursing_home', but if there is a guide suggesting using 'category', I'd like to try to get it improved.

Thanks,

Max

I haven't done anything to figure out what would cause it, but 15-20 objects in this area have tags with U+007F added to them, for example osm.org/way/12786669 . I haven't checked that they were all part of this changeset, but they are from changesets you had made.

I have cleaned up the ones that I happened to download, except for osm.org/way/416332289

The character doesn't show up in the left panel, but it does show up in the page title (just before the name). It also shows up in josm and can be searched for there.

I don't think they cause any big problems (I guess stuff ignores them), but it would be good to avoid creating them if you can figure out where they were coming from.

Hi and welcome.

As you are editing, it is helpful to try to save the work you have done in local areas. For instance, in this edit, your save includes a building in Chicago along with the buildings in WA. Those edits are better split into separate saves.

The main benefit of keeping the changes to a smaller area is for people looking at the changes later, trying to understand them.

Simple views like osm.org/history just show the whole area of a save, so big saves make it hard to use.

Thanks and have fun,

Max

In the above example, the "building:levels" tag was not copied over to the new building.

Procedurally, it looks like there were 2166 existing buildings deleted in one changeset and new buildings uploaded in another. Where could one look to find documentation of how information from the deleted buildings was transferred to the new objects?

I agree that the tiger tags are largely useless, it's just wasn't clear to me how much individual attention each of the 999 ways received. If the comparison was quick, there's room to argue about whether an edit just scrubbing them off is worthwhile. If they've been carefully compared to the county data, it's probably good to also go ahead and remove the tiger:reviewed tag (some people only do that on ways they've surveyed, but there's other people removing it without even reviewing the geometry against any imagery...).

@Toebee: there's 15 nodes in the changeset, so the edit is mostly to the tags on the ways, removing more tiger tags than the automatic operation. I have a preset in JOSM that removes all of the tiger tags and use it where I have set the surface tag and I feel I've looked close enough at the way/imagery/Tiger 2015, but like I say above, it wasn't clear how much review each way got here.

Do I understand correctly that this edit largely consists of selecting all the ways and deleting most of the tiger import tags from them?

I usually remove tiger tags after I have reviewed the geometry and added a surface tag, but it seems unlikely that the ways were individually reviewed here. What's the benefit of knocking the tags off?

Yeah, I came across the site reviewing hospitals with no emergency tag and removed the amenity tag from the node after checking a bit: osm.org/node/358244014

I think brownfield makes a lot more sense than military.

The VA (The Department of Veterans Affairs since 1989, no longer the Veterans Administration) is separate from the DoD and cabinet level. Based on that, is the military landuse appropriate?

@joost schoupe, MAPS.ME doesn't allow editing of the name tag. See https://github.com/mapsme/omim/issues/4149

(I'm not entirely sure of what behavior to expect from each version of the app, but the user doesn't have a lot of control over which tag(s) it stores the name in.

Are the many circular buildings in this area meaningful?

Some examples:

osm.org/#map=19/39.61113/-75.82709

osm.org/#map=19/39.60773/-75.83350

They look like artifacts/mistakes, but I figured I would check instead of just deleting them.

Hi-

I just wanted to suggest a couple tags that will help users of OSM data make better use of your edits. For road/path and parking surfaces, there is the surface tag. So something like name=(gravel) can be captured more clearly as surface=gravel.

The other suggestion is for trail markings. There is the tag 'symbol' which is used for descriptions of the trail markings. I think "symbol=Blue blazes" would be sufficient description for the blue blazed trails in Connecticut. A nice benefit of using the specific tag is that it can be used alongside a name tag.

There's also a more elaborate key that can be used to describe the geometry of the markings:

osm.wiki/Key:osmc:symbol

Max

Hi-

The convention for US highways in OSM is to only put the highway number in the ref, not the direction of travel.

If you think that is a bad convention, the first step would be to start a conversation about it on the talk-us mailing list.

It's also important to keep in mind that the data has many uses. By not changing all the segments, some users will end up getting some pretty frustrating directions:

osm.org/directions?engine=osrm_car&route=45.606%2C-84.628%3B43.739%2C-84.012#map=8/44.682/-84.364