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.

As for the addresses they were imported from the MIami Dade open data hub back in 2017 and 2018, four more info see osm.wiki/Miami-Dade_County_Address_Import . Those addresses are mostly good but if changes have happened since they have not much updating since and there are still a decent amount of errors and sometimes they will need alignment fixes.

Also when I mentioned that this is part of the 2026 road area I was incorrect as I misread the map as I was responding quickly as I was out and about and didn’t have much time to respond, but I will keep to what I said and do the area between SR 969 (northwest 72nd avenue), SR 948 (northwest 36th street) and the rail yards, though I will preface that I am currently out of the US and do not have my laptop with me so I will not be able to do much of anything until August 11th as I get back late on the 10th.

Looking at the Esri and Esri clarity aerial imagery in the area there seem to be parking spaces on either side of the loading dock service road so I think it should stay, I normally don’t add these my self but when they are actually already mapped I don’t see a good reason to remove them since they technically are there. That is a general rule I follow there are things I my self don’t add in my first pass but if something is mapped I will try to fix if incorrectly placed when I see it.

As a small note about the docs for my pass system, I use ‘~’ as a todo of sorts so if you see one at the end of a list or paragraph it means that I extend to add more or change things a bit.

I plan to have this area done by the end of the year so I will add the service roads soon, once I finish the area I already started previously I will do this one, for more info see https://github.com/Udarthegreat/public-sources/blob/main/Miami%20Dade%20County%20Progress/2026%20road%20area%20todo.geojson . The goal for the 2026 road area is to get the first pass done in the area, what I mean by the first pass see https://github.com/Udarthegreat/public-sources/blob/main/my%20working%20definitions/Pass%20system/readme.md , though as a note that document is very much WIP at the moment so some of the descriptions are missing or will be changed slightly in the future.

Happy mapping,
Udar.

What for you mean by “ 47th Street was in the wrong place”?

Also just to clarify for my self what exactly did you mean by addr:street:type=residential

This was tagged correctly previously, “highway” in highway=* uses the British definition not the American meaning of a motorway, so highway=residential is the correct way to tag a road like this.

Happy mapping,
Udar

A few issues gates should not be placed on the vertex shared between two roads so node/8413815965/history#map=19/25.816624/-80.313380 should not be at the intersection of two roads and was seemingly at a more correct position previously. Secondly, the parking lot way/572728726/history goes into seemingly still exists so it should have been split, not deleted. Lastly names should only have one values, alternative names have a tag alt_name=*.

Happy mapping,
Udar

Sorry wrong comment, I meant:

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.

Sorry wrong comment I meant:

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.

ALPR's should not be attached to road centerlines, they should be placed the position they actually are at.

Happy mapping,
Udar

ALPR's should not be attached to road centerlines, they should be placed the position they actually are at.

Happy mapping,
Udar

just adding addr:housenumber=* isn't very useful, at least also add add addr:street=* because that one is harder to interpolate based on location. It also seems like the node added in this changeset may be a duplicate of node/6018564941, if so that node should have moved to the correct building instead of adding a duplicate.

Happy mapping,
Udar.

ALPR's should not be attached to road centerlines, they should be placed the position they actually are at.

Happy mapping,
Udar

the destination tagging on way way/48419938 was already correct as destination=* refers to the roads and places on the signs, this does not include the id/reference number of a road like US 1 and I 95, these get tagged in destination:ref=*, there is also the fact that on the sign on the gantry in the bing streetside it is signed as TO US 1 and I 95 meaning that destination:ref:to=* is the correct place for US 1 and I 95 to go and that is where they already where. for more info see destination:ref=*, destination=*, osm.wiki/Proposal:Destination_details and ref=*.

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.