Hi, I see several newly created accounts adding locations for "Dickson Law Group". If the same person is adding these locations, it would be preferable that they use a single account to do it.

It's totally fine to add your locations, and it looks like you are doing a good job of it.

That said, it looks like a single person is doing the edits, if that is the case, it would be preferable if they were done using a single account.

I don't see how it is objectively simpler on the editing side.

A consumer can parse the US tons and just multiply to get tons.

An editor that wants to show US tons, in a way that sensibly matches the signs on the road, has to calculate the conversion, 14.9991 in this case, and then use some heuristic to decide whether to show that or 15 (yes, rounding will work fine here, but the point is that convert to store loses information).

It's fairly likely there is a sign that says "15 tons" somewhere there.

One argument that this is harder to use is that no existing editor is smart enough to take "maxweight=13.607" and show the user "15 tons", so it's more difficult to verify.

I've merged the outer ways in this changeset:

osm.org/changeset/34662677

I also merged the outer way with the lakeshore (where they coincide).

I don't keep a close eye on iD (the web editor), but I think for large scale edits like this, JOSM is a lot easier, mostly because it is possible to selectively load data and zoom out. I used a method something like is described here to load the relation into the editor:

http://ksmapper.blogspot.com/2014/02/workflow-for-fixing-county-borders.html

I've left the relation intact because the water bodies inside the forest should be added as inner members, especially the larger lakes.

It can take a bit for the rendering system to catch up with the changes, some of the scales are set with a higher priority so changes show up more quickly (mostly the close in zooms are prioritized).

It can also happen that a road is split into several pieces (like to model a bridge), each with its own name tag that would need changing.

Feel free to send me a message if you have any questions.

Yeah, that's what I meant.

I don't have any specific knowledge of the area, JOSM flagged the duplicate ways.

There are double tracks visible for at least some of the way and someone had started aligning the duplicates with the second track, so I wasn't sure if there was a plan or what:

osm.org/node/3426014942

Are the duplicate overlapping sections of the Jefferson City Subdivision here an accident or unfinished work? One end of it here, continues for some ways:

osm.org/way/335497374

highway=motorway is usually reserved for roads that do not have any at grade crossings. The many crossings on these roads make them a bad case for motorway.

Welcome to OpenStreetmap and thanks for the additions.

I see you've put "Official Use Only" in the name of one of the trails, and then marked it for bicycle and foot use. The bicycle and foot access is meant to document what use of a trail is allowed, so marking them "yes" looks like it contradicts the note in the name, as the "yes" indicates that the public can access the trail using that mode.

The typical way to mark the trail as not being open to the public would be to mark the general access as "private". There are a lot of details to consider with the access tagging:

osm.wiki/Key:access

In the US, where access law isn't all that complicated, setting the general access to private covers the majority of situations (because there are not a great deal of roads that are private for motor vehicles and open to for example, foot traffic. Things tend to be public or private without much middle ground).

Please consider making your changeset comment about what you are doing, especially instead of about where, which is captured by the bounding box of the changeset (I ended up here because you had commented that you were improving areas in Mexico in a changeset focused on Georgia, USA).

Something like "Improving roads." is probably still sort of vague, but it is already more informative than a comment stating the wrong location.

I don't understand the point of doing this versus just deleting it entirely or marking it as access=private.

The road is a short dead end that is presumably blocked at the beginning, so it would be difficult for a router or whatnot to create a big problem.

Yes, the streets in the US were imported from a government data set that does contain many such errors, fixes based on personal knowledge of the area are quite welcome.

I see that you also changed the value in "tiger:name_base", this isn't necessary, as the tiger: tags aren't used for anything (they are just left over from the import).

Thanks for the fix and welcome OSM.

Max

Are you using an imagery offset? Comparing against the OSM GPS Trace layer from Mapbox and the Strava Cycling Heatmap, the imagery in the Grand Rapids area appears to be quite well aligned, and in many cases you have offset the center lines of roads about 20 feet from Bing and those GPS layers.

Hi-

In this changeset:

osm.org/changeset/30826815

I have removed tag values like "building=yes" from the name key of ways that you have edited.

For example, version 1 of this way has the "building=yes" value :

osm.org/way/342340344/history

If you decide to do some more edits, if an item doesn't have a name or you don't know the name, it's fine to just leave the name field blank.

If you have any questions, feel free to reply here or send me a message using the "send message link" on my OSM user profile: osm.org/user/maxerickson/

Thanks,

Max

The current modeling of the Great Lakes is actually to use natural=coastline.

The addition of natural=water to the lake superior relation is probably what caused the bad rendering at z13.

If you check the history of the relation, you can see people repeatedly adding and removing natural=water.

There is some amount of agreement that the Great Lakes are to be modeled as natural=coastline. You can see here that natural=water was added and removed just a few months ago:

osm.org/changeset/27063265

The relations also need some work. For instance, Isle Royale is missing:

osm.org/way/146305732

Probably along with the many smaller islands in the area there.

I expect the natural=water on the Lake Superior relation is what is breaking the rendering at z13:

osm.org/#map=13/48.0690/-88.5923

I think if you want natural=water to be the standard you should probably open a discussion on the talk mailing list, or someone will just come along and flip it back.

The relation for the forest itself seems to be missing. I got here via this untagged way: osm.org/way/321248658 which looks like it is meant to be a big piece of the boundary.

Hi-

If you make sure that paths that connect share a node, software that interprets the data will generally work better.

For example, I expect that this way:

osm.org/way/306192374

Joins up with both Stickney Hill Road and the longer path to the east. Software generally won't make that assumption, it relies on a node being shared by the paths/roads.

I guess data consumers are not widely using it, but it looks like you might also want to make use of the seasonal tag:

osm.wiki/Key:seasonal

That's all,

Max