To be clear, I'm open to possibility that I don't have it quite right either. But if I was working on this the fact that I was having to go change so many complete waterways that a conversation might be warranted and to verify the wiki still represents the consensus.

I believe you are misunderstanding that guidance. It is not saying that a waterbody larger than 3 meters should be a river. It is saying anything less should be tagged a stream. It isn't an upper limit on stream but a lower limit on river. Most waterways or roughly half in OSM tagged river are at least 10 meters wide.

Was this series of changes discussed anywhere? What width rule are you referring to? I wonder if you're misinterpreting that guidance to classify a waterway less than 3 meters in width as a stream as always classify waterways with widths larger as a river.

It's okay to connect the streams, just never cross them </end ghostbuster joke> lol

Please consider being specific and explicit in your changeset descriptions.

Providing detailed descriptions ensures that other mappers can understand the rationale behind alterations and contribute effectively. As an example, the changeset you reverted had a notably more informative description: "Added road name 'North Highway 183'. Source - North American Roads and user feedback. #mapbox_contribute."

Please consider offering similarly informative descriptions in your changesets, as it greatly aids in maintaining clarity and collaboration among mappers.

This changeset appears to update the name of the administrative boundary for the city of Jarrell from "Jarrell" to "Jarrell City Limits". Typically the name key is the official or primary name of a feature. For administrative boundaries such as this, the city name is almost always the correct value. Could you kindly revert it back or share your thinking on why "Jarrell City Limits" is the more appropriate value in this case? Thanks!

This changeset has prompted discussion in #place-classification on the OSM US slack. If you'd like to participate, you can find the thread at https://osmus.slack.com/archives/C066VNZEGQ7/p1702742128088529

Yes, Pioneer Crossing Neighborhood Park is an actual park though it doesn't much look like one does it from available imagery? Now, CAD often provides great clues but CAD is interested in ownership and taxation. Be careful not to rely on non authoritative sources. Travis CAD shows both the plot and the area you reduced from as owned by City of Austin and exempt. A city is of course permitted to set the boundaries of a park and have it extend across multiple plots they own in whole or in part. City of Austin maintains boundaries for parks in their BOUNDARIES_city_of_austin_parks GIS asset. Here is link with a Harris Branch and Pioneer Crossing Neighborhood Park filter selection: https://arcg.is/0XWKan

source: https://www.averyranchaustin.com/community-map/

Also, Welcome to OpenStreetMap :)

Thanks for the quick reply.

From the ASH Master Plan Report, "The new ASH
campus will focus on engaging the community that surrounds it by
creating accessible public spaces and street design that includes
generous tree-lined sidewalks in order to encourage engagement
with residential neighborhood."

See https://www.ashredesign.org/downloads-2023

Do you want to reach out to their community engagement team and find out for sure current status? They can be reached at 512-419-2330.

Can you kindly provide a source for this change? I'm not sure if this is true any longer, at least not for entire area.

This was definitely at wrong location beforehand so kudos for the update.

Thanks for updating this. This has been on my radar due to the previous construction tag orphaning off this neighborhood. I do believe there is still construction happening here though but I don't have the benefit of lyft proprietary imagery and I haven't been by here personally. See https://www.austintexas.gov/news/road-closures-mearns-meadow-blvd-construction-reduce-flooding-along-little-walnut-creek which suggests that phase 1 (Mearns meadow boulevard from Rutland to Parkfield) just begun August 26 2023 and will run until spring 2024. I suspect there is some form of access still but maybe only one way and for local traffic? Just leaving as is may be best bet either way but wanted to make sure you were aware of news release from the city. Cheers.

Do not mark a ford when a waterway travels under the roadway via culvert. Let me know if you need assistance on how to do that. Please kindly delete all these fords (some of them are in other changesets). Thanks.

Just stumbled upon 6582 myself and came to share but you've already beat me to the punch. Kudos.

Now, based on a review of street side imagery, aerial imagery, and USGS 3DEPElevation multidirectional hill shade visualization, I don't believe there is a rolled curb here. I believe it is a a painted red line. :-) Or am I misunderstanding what you're intending to tag here?

Hello Minh Nguyen. I noticed you tagged barrier=kerb + kerb=rolled. This has caused OSRM to no longer route on these roads. It seems to be a bug. Would you be willing to follow up with OSRM team?

Hi Technogeek, Thank you for your contributions.

Please do not map a parking lot (amenity=parking) for street side parking. Instead, use street side parking (amenity=parking + parking=street_side), parking lane (amenity=parking + parking=lane), or tag the existence of parking on the section of the way where it exists (parking:{left,right,both})=*.

Please do not map multiple parking lots (amenity=parking) for what is actually a single parking lot. For example, for the single parking lot for the church on Lexington Road you created six separate polygons for each continuous block of parking spaces. I appreciate you wanting to provide additional level of detail. In order to do that properly, you'll want to map a single parking lot and *then* map parking spaces within it (amenity=parking_space). Splitting the parking into multiple polygons can lead to data redundancy. If someone were trying to query data related to parking facilities, they might end up with inflated counts or misleading statistics; representation should align with real-world semantics. From a rendering perspective, the cluster of 'P' symbols this causes in close proximity is visually cluttering and might mislead users into thinking there are multiple distinct parking areas, rather than one cohesive parking lot.

You can find additional resources on mapping parking at osm.wiki/Parking and for street side parking specifically see osm.wiki/Street_parking

Please let me know if you have any questions or if you disagree. Feel free to catch me on OSM US Slack as well.

Thanks again for all your hard work.

I've noticed you adding service=driveway to a number of service roads but from what I've seen it appears most uses are inconsistent with the typical established norm so I'd like to discuss with you.

From my perspective, the service=driveway tag should be used for private or restricted-access roads that lead to a single facility, residence, or small group of buildings. It should almost always be a terminal destination with only one end connected to road network.

Paths in or around a parking lot (amenity=parking) are tagged with highway=service without service=*, connecting multiple parking aisles (service=parking_aisle) when applicable.

Can you help me understand this change? The separation of the roadway begins at the intersection.

Also, I think there is some additional changes perhaps needed to lane configuration at the RR 2222 and RR 620 intersection north of the bypass intersection. I'll take a closer look.

Also, tangent but noticed that it seems like parts of RR 620 keep getting recreated. It looks like a bunch of additional useful tags were lost in changeset #139193387 by different editor. Should we look to restore the history perhaps or at least the tags?

Cheers!