It is designated because from what I can tell it is a pedestrian and foot path and thus the tags used are highway=cycleway + foot=designated + bicycle=designated, those are just the community decided on tags for pedestrian and foot paths, that is why there is the general access=private because unless something specifically overrides the general access=* tag it applies to all uses, and the designated value doesn’t override the access=private because designated tells you whether a specific mode of transportation is allowed on a way and if so how, it does not tell you what the access requirements are (what private tells you). In essence the access private tells you that bicycle access is private and foot=designated + bicycle=designated tells you that only bikes and pedestrians are allowed to use the path which because of access=private means that only private pedestrians and bikes are allowed to use the path. I have already explained this in comments left on your commits previously.

please respond

thank you so much for the clarification, looking at the imagery it does seem a bit unclear as to weather or not there is a road connection between the two ends of Dickson Drive divided by the pedestrian features and I think its safest to leave it as pedestrian until better aerial or street side imagery makes that clear.

while I have y'all's attention, I hope it wouldn't be to much of a bother if y'all can check weather or not the roundabout at node/384024486 is complete and if so fix the geometry as there is nothing there on the latest imagery and I am basically certain that they are placing a roundabout at that location. if its to much of a hassle please ignore, y'all just have significantly better imagery then I have so can check the state of that construction.

since there isn't any good up to date imagery in the area I was wondering if you could provide screen shots of the "Lyft-owned aerial imagery " so that those of without access can check. I ask as a contributor, who from what I can tell goes to UM seemed pretty sure that it was only pedestrian in the area, from what I could tell; I am just trying to clarify things on my end here, since this commit leaves me unsure on what exactly is what since we are unlikely to get new OSM compliant aerial imagery sources in this area until at least July, likely August.
If you cant I understand.

the positioning of this seems off in the aerial and street side imagery available in OSM, so I was wondering what your source for this commit is.

changeset/162800792 seemingly didn't fully upload to OSM so trying again.

changeset/162837745

changeset/162800792 seemingly didn't fully upload to OSM so trying again

changeset/162807379

accidentally reverted the wrong commit, got the tabs mixed up, the accidentally reverted one was my own so not effecting anyone here, will be more careful next time.

changeset/162800792

my bad accidentally reverted my own commit, got the tabs open mistaken

these are bike and foot paths and thus necessarily have tags of "bicycle=designated" + "foot=designated" + "highway=cycleway", they already have a tag of access=private, that is enough to mark these as private.

changeset/162800365

these are bike and foot paths and thus necessarily have tags of "bicycle=designated" + "foot=designated" + "highway=cycleway", they already have a tag of access=private, that is enough to mark these as private.

changeset/162800351

as I have previously mentioned, these are bike and foot paths, that means that they have tags of "bicycle=designated" + "foot=designated" + "highway=cycleway", so stop changing the bicycle=* value. there is ageneral access=private, that already tells you that it is private, disgnated tells you that this path si specifically for use by bike and foot with the general access=private telling you its private bikes and pedestrians, please stop changing this.

Happy mapping,
Udar.

why did you move the Hialeah node so much it seems to have been placed correctly previously.
also next time please leave a better change set comment, for more info see:
osm.wiki/Good_changeset_comments

If you click on “edit” on the main openstreetmap.org website, go to the "Background Settings" (Shortcut:B) on the right side of the editor and scroll down you will see a checkbox for “TIGER Roads 2023”, click on that, you will see the respective road names on there, while the alignments from there tend to not be the best the names are. Also if you go to the following site (https://gis-mdc.opendata.arcgis.com/datasets/b0107c2e893a4ff78367837cf80bdfaa_0/explore?location=25.725668%2C-80.252825%2C16.55) you will also see similar road names in the area. TIGER is from the census bureau, they are as official as it comes. There are other databases on in the Miami dade open data hub that also show the names similarly. Those are the official names, I have gotten them from sources that have all the resources they need to be accureate.

The roads here are way to wide to be service roads and play way to an important role in role in the road network (especially Brooker street) to be service so that’s just plain wrong. Brooker and Charles Avenue in fact do pop up on the mimi dade oped data hub.

They are not private as these aren’t driveways or part of a gated community. There isn’t nothing physically stopping someone from driving through. Brooker street especially as it has non private segments further north whose traffic flows directly into the segment you keep marking as private without the road getting thinner or a gate being put in the way (this simple logic also applies to the fact that it is residential). I can half accept Charles Allen Avenue and Charles Avenue being private as they do seem to have some signage indicating something of the sort on bing streetside but Brooker Street and William Avenue have no such signage on the bing street side with the Brooker Street also having the role it does in the network as described above.

as for the "City of Miami municipal road atlas", I counld find a single link to buy it so I assume its either out of print or hard to get and as such is a source that couldnt be checked for validity and licence complience with OSM and thus I doubt its usefulness as a source for OSM contrinution. The data from the property apraisers office of miami dade sais nothing of the road network in the area, data from the apraisers office would certainly be useful for mapping addresses, buildings and landuse in the area if its licence complient with OSM but it shows and sais nothing of the road network in the area and thus doesn't really help in this senerio.

As an example of the gate on either side principle you only have to look slightly north as vertexes node/7509485821 and node/7509485798 enclose a set of roads that are all private, if those werent there how private would it be. As for the "St. Alban's Day Nursery" it is clear that the parking on the side of the road is private from the bing streetside and the property apaisers office but that doesn not aplly to the road in general, drivers backing out of the parking may have priority but that doesn't make it private. Just because there are private land uses next to a road deosnt mean it is access=private, it can be used by cars passsing through an thus isn't private.

As I have already told you these aren’t service roads as their role in the network is that of a residential road, they are certainly to side to be a service road. Second of all, on TIGRER and other official Miami dade county sources these roads have the names you removed to please stop removing the name and tagging them as service. Second theses aren’t private as there aren’t sufficient gates to be considered as such (a road is only access=private between two gates, only one of these roads has A gate, not two), Brooker Street is certainly not private as it is seemingly for through traffic within the network.
Again I ask you to please stop making these incorrect edits as I previously explained.

why did you remove the check_date=* tag, I'm pretty sure it is correct, unless you want to update it to an earlier date when you saw it.

from what I can tell these road seem to have been correctly name previously and some of the addresses removed seemed to be correct previously.

how have you, within basically 24 hours surveyed items in Miami FL, Lynn, MA, and Edmonton, Canada. either you have been flying allot or there is some kind of mistake here. The data you attach to the check_date=* tag is supposed to be the data you verified the item inside of OSM.
Because of this I was wondering if there were any other sources then survey and local knowledge that you used for this and other recent commits.

For some of the points, like node/12551975881 , the library it points to already had a phone number so some of that isn't automatically new. I say these are duplicates because quite a few of these libraries were already mapped and this added a new instance of the library, just without the correct tagging.
What ever your process was used for checking these, I would reevaluate it, if I were you, because the vast majority of the nodes I checked yesterday between MIA and th3e bottom of Miami dade county were duplicates. There is a good reason we have guidelines for imports and automated edits:
osm.wiki/Import/Guidelines
Before you upload you should always check for duplicates, some of these were really close to the already mapped way.
Just because you were intending to fix the data doesn’t mean that you have free reign to add, or not add, what ever tags you please. Next time you attempt something like this please do not add features that do not have tags like amenity=*, there is a good reason the wiki page for name=* warns against leaving features as just a name; and yes adding a feature without a tag further defining what type of object it is is just as much an issues weather or not you add tags like the phone number.
If you wanted to add the phone=* and nat_ref=* it would have been better if you’d checked for duplicates and just added the necessary tags to the features instead of adding a new, duplicate, node.
Without the amenity=* tag these amount to nothing because data consumers show you the amenities not random names (even if their attached to an address), to tell you what type of object something is data consumers need the amenity=* (or similar tag) tag to do so.

two points here, first it is generally good practice to add what type of object something is (like amenity=*) rather then just adding a name to an address.
second, most of the added features in Miami dade county are duplicates of already mapped features. Next time you do a sudo import like this please do better checking for duplicates and correct positioning.