next time please add a better changeset comment, for this changeset a comment of "added an electronics repair shop" would be sufficient, for more info see osm.wiki/Good_changeset_comments

Happy Mapping,
Udar.

quick question, can you please look again and see if as part of this construction sidewalks have been added along Northwest 107th Avenue on the side of the street of this construction site based on the imagery you used for this changeset?

Happy Mapping,
Udar.

due to this changeset the geometry of the buildings is now broken, why have you done this?

Happy mapping,
Udar.

please respond to the above

This is incorrect, this section is under heavy construction for the go-ggi project (https://go-ggi.com/) from the FDOT, this project is doing massive amounts of construction around this highway interchange. The Bing aerial imagery is from January of 2024, the project had barely started at that point, there is newer imagery from 2025 that shows these roads as not existing any longer, they where mapped in the way they were for a reason. The new 2025 imagery can be used in iD as "Custom" imagery using the following URL template:

https://imageserverintra.miamidade.gov/arcgis/rest/services/Woolpert2025/ImageServer/exportImage?f=image&bbox={bbox}&bboxSR={wkid}&imageSR={wkid}&size={width},{height}+

please double check before doing something like this next time, things like this missing usually have a reason for being that way that is documented in the history of the object and the changeset comments of the changesets that made the changes, for example the changeset where I deleted the sections that now do not exist due to the construction and updated these ways as being under consturction since they do not form a valid network is 172670355 where I clearly put in the changeset comment that the changeset is done based on newer imagery to update what I could of the area due to construction in the area. The relevent part of the changeset comment is "various alignment and tagging fixes based on newer imagery at the GGI".

Happy Mapping,
Udar.

added tagging for rrfb and split median of road

this is incorrect, first of all bike lanes should always be tagged and not mapped as separate geometry. second the cycleway was aligned correctly before, there is a cycleway that is separate and one that is a lane, this happens in a few spots in Miami Dade County.

Happy mapping,
Udar

y'all should be extra careful with this stretch of Okeechobee Road (US 27) and its frontage road as there is allot of construction happening and according to FDOT by the end most of the frontage road from HEFT to Fl 826 will have a sidewalk on one side, so while I'm pretty sure that the edits in this changeset are in segment four which will not start construction any time soon and thus are correct its kind of hard to tell as all of the aerial imagery in the area are out of date (including the Miami Dade County one) along this road where construction has been happening. to double check you can use the following custom imagery in the web based editors like Rapid:

https://imageserverintra.miamidade.gov/arcgis/rest/services/Woolpert2025/ImageServer/exportImage?f=image&bbox={bbox}&bboxSR={wkid}&imageSR={wkid}&size={width},{height}+

you can get this working in JOSM, I have but that was a little more complicated, for more info see:

https://imageserverintra.miamidade.gov/arcgis/rest/services/Woolpert2025/ImageServer

the link for the main FDOT website for the Okeechobee construction project is https://www.fdotmiamidade.com/okeechobee . If you have any questions about this please feel free to message me here or through OSM.

Happy Mapping,
Udar.

I brought this up on the OSMUS slack and did this partially based on conversations that happened there, the link to the archive is https://osmus.slack.com/archives/CCJ2P6KCH/p1767737543248779

As mentioned above unless there is a good explanation as to why only these addresses are in Hialeah while all of the surrounding addresses are Miami Lakes and the Miami Dade Open data hub has these as being in Miami Lakes this is incorrect and thus needs to be reverted

changeset/176961139

I made that change, if you want to see what it looks like you can look at it at https://overpass-api.de/achavi/?changeset=176927813

if you have any feedback feel free to respond ask here.

Happy mapping,
Udar.

sorry I linked the wrong node, my bad, 13433783517

I could be wrong here and if I am please ignore, but node node/13433783518 is visually inside of the area of a road and seemingly not under a bridge, so I was wondering of the position is correct?

Happy mapping,
Udar.

please respond

The geojson file with the area that the existing project is within is https://github.com/Udarthegreat/public-sources/blob/main/tasking%20manager/pedestrian%20feature%20addition%201/area%20for%20sidewalks.geojson

Please tell me if you need anything else.

Happy mapping,
Udar.

Please do not do any other tasks within this area for this OSMUS tasking manager project as it conflicts with the area of an existing project on OSMUS that is public, https://tasks.openstreetmap.us/projects/876

Happy Mapping,
Udar.

This edit seems to be incoorect, first of all, you changed the addr:city of several buildings from Miami Lakes to Hialeah, looking at the surrounding addresses they all seem to be Miami Lake and there is also the fact that these addresses are not inside of Hialeah but are instead inside of Miami Lakes so I doubt that these changes are correct. for more info see relation/118853 and relation/1217204 .
There is another issue though, even if the change to Hialeah was correct you still put it in in all caps which is discouraged in OSM.

Happy Mapping,
Udar.

then the stops should be tagged as was:highway=bus_stop , If you want I can do that

Happy Mapping,
Udar.

Road way areas can be seen from aerial imagery. For vehicle transportation ways it doesn't matter as vehicles are large enough for it not to matter, for pedestrians on the other hand having to walk onto the road and exactly where that happens is extremely important and as such footways should never touch road way centerlines unless they are a crossing or a link. The whole point of a link is to connect a footway from where it ends to the road centerline so this is a correct usage. Once the road area starts the footway ends and thus the plain footway must also end, but since this needs to be navigable a footway=link must be added to ensure the nav graph is complete. Two different types of road are still road (the same type of transit), so the ways can intersect in ways that different modes of transit cannot, footways and vehicle ways are different modes of transit, they thus should be treated as different modes of transit.
While certain ways are zero width footways and vehicle transport ways definitionally are not as if they where zero width they wouldn't be able to be used for transportation, even if a width is not specified. Transportation ways are an approximation of the 2D area they represent which is an approximation of the 3D volume that OSM cannot directly represent, so considering the area of various transport ways matters as the ways are an approximations of those areas. by splitting a router can tell you roughly when you are entering the road, this is useful to know.
I have also read the wiki multiple times over, I do allot of pedestrian mapping in Miami Dade county so I am very aware of the relevant wiki pages, the links exist and thus they would get tagged as either a footway=link or an unmarked crossing, which do you prefer.

Happy Mapping,
Udar

Road way areas can be seen from aerial imagery. For vehicle transportation ways it doesn't matter as vehicles are large enough for it not to matter, for pedestrians on the other hand having to walk onto the road and exactly where that happens is extremely important and as such footways should never touch road way centerlines unless they are a crossing or a link. The whole point of a link is to connect a footway from where it ends to the road centerline so this is a correct usage. Once the road area starts the footway ends and thus the plain footway must also end, but since this needs to be navigable a footway=link must be added to ensure the nav graph is complete. Two different types of road are still road (the same type of transit), so the ways can intersect in ways that different modes of transit cannot, footways and vehicle ways are different modes of transit, they thus should be treated as different modes of transit.
While certain ways are zero width footways and vehicle transport ways definitionally are not as if they where zero width they wouldn't be able to be used for transportation, even if a width is not specified. Transportation ways are an approximation of the 2D area they represent which is an approximation of the 3D volume that OSM cannot directly represent, so considering the area of various transport ways matters as the ways are an approximations of those areas. by splitting a router can tell you roughly when you are entering the road, this is useful to know.
I have also read the wiki multiple times over, I do allot of pedestrian mapping in Miami Dade county so I am very aware of the relevant wiki pages, the links exist and thus they would get tagged as either a footway=link or an unmarked crossing, which do you prefer.

Happy Mapping,
Udar