looking at this ALPR on various aerial imagery in iD it seems to be within the road area, being positioned like this is highly unlikely so please double check the position of this ALPR and fix it.

Happy mapping,
Udar.

looking at this ALPR on various aerial imagery in iD it seems to be within the road area, being positioned like this is highly unlikely so please double check the position of this ALPR and fix it.

Happy mapping,
Udar.

looking at this ALPR on various aerial imagery in iD it seems to be within the road area, being positioned like this is highly unlikely so please double check the position of this ALPR and fix it.

Happy mapping,
Udar.

looking at this ALPR on various aerial imagery in iD it seems to be within the road area, being positioned like this is highly unlikely so please double check the position of this ALPR and fix it.

Happy mapping,
Udar.

looking at this ALPR on the latest aerial imagery in iD it seems to be within with the area of a parking space, being positioned like this is highly unlikely so please double check the position of this ALPR and fix it.

Happy mapping,
Udar.

looking at this ALPR on various aerial imagery in iD it seems to be within the road area, being positioned like this is highly unlikely so please double check the position of this ALPR and fix it.

Happy mapping,
Udar.

I have asked the Facebook team to not do tasks overlapping with https://tasks.openstreetmap.us/projects/876 , I have also been fixing the MapRoulette tasks in the area once a section is complete in the tasking manager. overlapping changesets like this have a high chance of conflicts due to the ongoing pedestrian project. I would not be opposed if y'all contributed to the OSMUS tasking manager project as long as you map follow the guidelines provided in there.

Happy mapping,
Udar

looking at this ALPR on various aerial imagery in iD it seems to be within the road area, being positioned like this is highly unlikely so please double check the position of this ALPR and fix it.

Happy mapping,
Udar.

looking at this ALPR on various aerial imagery in iD it seems to be within the road area, being positioned like this is highly unlikely so please double check the position of this ALPR and fix it.

Happy mapping,
Udar.

looking at this ALPR on various aerial imagery in iD it seems to be within the road area, being positioned like this is highly unlikely so please double check the position of this ALPR and fix it.

Happy mapping,
Udar.

looking at the latest aerial imagery in the area I do not see any evidence of a drive through.

Happy mapping,
Udar

please double check your self, from what I can tell, and I have double and triple checked my self on this, there are no sidewalks along this segment of Northwest 36th Street so removing sidewalk:*=no is incorrect.

happy mapping,
Udar.

ok, I fixed this roundabout once already, see the conversation at https://osmus.slack.com/archives/C029HV951/p1781704568456079 . Due to the slip lane from Sylvania Boulevard to Southwest 12th Street (way/703986728) traffic will not be going from way/703986713 to way/1524885406 so it is ok that they share a vertex. There is also a no right turn restriction relation disallowing that movement relation/20995910. See the above attached OSMUS Slack link for the conversation about this exact roundabout.

Happy mapping,
Udar.

my bad, meant to put the a changeset comment of "updated ref (and related tags) values of SR 589 in Pasco County as consensus has been formed to use SR in ref's in Florida #Flo_FL->SR_convert"

Can you please double check if this is actually an ALPR as I doubt that there would be one on the fence or in a backyard like this. I am not saying that there is not anything here I just doubt that it is an ALPR, it could be a gun shot detector or just a normal security camera but if that is true the node added in this changeset is incorrectly tagged. So please either fix the position or change the tagging to more accurately tag what is actually there.

Happy mapping,
Udar.

I meant sidewalk tagging

which ever you'd prefer, I don't care much either way.

I am pretty sure that the relation added in this changeset is a duplicate of relation/1236474.

Happy mapping,
Udar.

looking at pewu https://pewu.github.io/osm-history/#/way/1054468685 these errors seem to have been added in changeset/184906490. All this changeset did on that way is change ref from "FL 570 Toll" to "SR 570 Toll". This can also be seen on https://overpass-api.de/achavi/?changeset=184950999.

Happy mapping,
Udar.

when a path goes under a building, if it is just a roof then it should be tagged with covered=* but if the path passes through the building (and doesn't go indoors since there is different tagging for that) then use tunnel=building_passage. I haven't been in the area my self and there isn't any streetside imagery in the area available in iD so I am not 100% sure but from what I can tell this pass under the span of the bridge not through the abutment. For more info see https://osmus.slack.com/archives/C2VJAJCS0/p1783271515914219 where I asked about this, use https://slack.openstreetmap.us/ if you haven't joined yet.

Happy mapping,
Udar.