Hello,

It looks like you moved US 36 from ref to name here. Please don't do that

Hello,

I recognize that this change happened a long time ago, but please do not set refs like "IL 48" in the name tag.

Hello,

Here, it looks like you duplicated I-290 while trying to map the lane merging in. Since there is only paint dividing this lane from the main part of the road, a separate way shouldn't be used anyway. But if you did, it should be a highway=motorway_link and lanes=1, while you had highway=motorway and lanes=5.

Hello,

Currently, it is standard to have the ref on both the way and the relation. Not all data consumers honor the relation (notably openstreetmap-carto), so please don't remove refs from roads for this reason. There is a section that talks about this on the wiki page: ref=*#Examples_on_ways

Under the 2021 classification guidelines, motorway does indicate that a road is in the topmost level of importance. And motorway=yes, as it is currently defined on the wiki, is talking about access restrictions, so it is not the right tag here. The closest thing is expressway=yes+access_control=full, but a better tag should probably be developed at some point.

Under the 2021 classification guidelines, motorway does indicate that a road is in the topmost level of importance. Trunks are also at this same level of importance, and when you look at these two classes together, they should form an interconnected network connecting large cities.

If we want to show that it is controlled access, we can use access_control=full

Hmm, I don't know, I think I would support highway=primary+expressway=yes here. The segment is fairly short, and it doesn't seem like the freeway section is more important than the non-freeway section. So, I think they should be at the same classification level.

Hi,

I would not start changing tags until the proposal has been voted on. Especially since as it stands, I think that the proposal would not pass.

Instead, for a case like this, I would suggest these tags:

- highway=primary
- expressway=yes
- access_control=full

expressway=yes alone wouldn't indicate that it is a full freeway, but I think adding access_control=full would do this well. highway=motorway shouldn't be applied here because this route doesn't hold national importance.

See discussion on changeset/150066960

Currently, it is standard to have the ref on both the way and the relation. Not all data consumers honor the relation (notably openstreetmap-carto), so please don't remove refs from roads for this reason. There is a section that talks about this on the wiki page: ref=*#Examples_on_ways

Hi,

Why did you remove ref="IL 137" from the ways here?

I don't believe I made a mistake; that section is properly tagged as leisure=nature_reserve. The data just isn't complete, so a multipolygon can be created as you mentioned and then the leisure=nature_reserve and boundary=protected_area can be moved to that.

Hilltop Hanover Farm is already mapped as a landuse=farmyard subarea. I'm not familiar with farm tagging so I don't know if that's the usual way to do it.

The general consensus in the previous changeset is that an area like the east part of Hilltop Hanover can not be leisure=park. That is why I changed it to leisure=nature_reserve. Following the "front of park"/"back of park" scheme, the outer border here would be boundary=protected_area perhaps with leisure=nature_reserve, while the farm section would be tagged separately.

Again, I would like to see a tagging scheme that works better for these borderline cases, rather than calling the whole thing either a leisure=park or a leisure=nature_reserve. But currently, it seems like this is what the consensus is.

As for Hilltop Hanover: the current boundary seems like it would definitely fall under leisure=nature_reserve, since it is natural. If the boundary were to be changed to extend across the street and include the farm section, it would admittedly feel strange to call the whole thing a nature reserve. I would be interested in having the community improve the tagging scheme here.

As for Onatru Park and Preserve: this seems to fit the "front of park"/"back of park" scheme that was discussed in the Cranberry Lake changeset. If we were to follow that, then the area with the sports fields would get leisure=park, but the outer boundary would still be boundary=protected_area perhaps with leisure=nature_reserve. Again, using leisure=nature_reserve on the outside here does feel a little weird to me, but that seems to be the usual tagging at the moment.

I've changed the leisure value on the outer boundaries, though we could use some natural=wood polygons. I haven't touched the places where a leisure=park subarea is necessary, yet.

Sure, I suppose I could have said spaces left in a natural state. In the region here though, that is usually wooded.

Well, it seems like the general consensus is that wooded preserves should get leisure=nature_reserve instead of leisure=park, so I will go ahead and make the change. I won't touch borderline cases for now though.

Hi,

Could you confirm where you got the shape for the park from? It looks like it came from the county tax parcels, which is an acceptable source, but I just want to confirm before adding it to the source tag.

I support the hybrid tagging approach, at least in cases where there really is a "front of park" section. Here is an example of a nearby park where I used this scheme: way/1302389330

In that case there is definitely a leisure=park there, though the location in this changeset is more borderline. Some of the other locations in questions have no amenities at all except for perhaps a small dirt parking lot, so in those cases I would say there shouldn't be a leisure=park subarea.