This business is clearly inside of Coral Gables so the "addr:city" should be Coral Gables, it is on Ponce de Leon Boulevard as so that is what should be in the "addr:street" tag, these are also the same on the address database on the miami dade open data hub, see https://gis-mdc.opendata.arcgis.com/datasets/eef6b33da60d47c0964387960c840eea_0/explore?location=25.764140%2C-80.259731%2C18.88

It is also generally custom in OSM to only have single number in the "addr:unit" not something like "unit 4"
Also, phone numbers are supposed to be in the format of (in the US) "+1 XXX-XXX-XXXX" were the X's are single integers.

are you sure that "HoneyBee Doughnuts" no longer exists as you seem to contributing all over the place.

If you look at the website it has hours for pharmacy and "Rx in-store pickup" which tells you that it dispenses prescriptions, aka the need for the tag.

why did you remove dispensing=yes, the website indicates that you can get prescriptions here, I also do not see any issue with the healthcare and amenity tags.

why did you remove dispensing=yes, the website indicates that you can get prescriptions here, I also do not see any issue with the healthcare and amenity tags.

I previously asked you why you have moved the node for Hialeah as much as you did and you have not gotten back to me on this in 5 months so I am assuming vandalism in this case, so I am reverting.

changeset/168857637

I previously asked you why you have moved the node for Hialeah as much as you did and you have not gotten back to me on this in 5 months so I am assuming vandalism in this case, so I am reverting.

changeset/168857637

please respond

please don't duplicate data next time, the business has already been moved into the building, please check before duplicating next time.

next time please try and keep the geographic size of you change set down, for more info see osm.wiki/Changeset#Geographical_size_of_changesets

it would be wonderful if next time you left a more informative change set comment, two hashtags doesn't tell me much, for more info see osm.wiki/Good_changeset_comments

happy mapping,
Udar

could you please give a better explanation of what you did in this change set please, so that other contributors can better understand what was done here and what you are trying to achieve.

Happy mapping,
Udar.

whats the source for this contribution

why did you remove boundary=administrative from Broward county.

as mentioned above, this commit adds an unsupported feature type to OSM mapped with existing tagging that has different meanings so it has too be reverted.

changeset/168722732

also it is important to note that names are not supposed to be used as a description of the feature, for more info see osm.wiki/Names#Names_are_not_for_descriptions

I am sorry but in OSM we do not currently support mapping service areas of a business, though If you wanted you could add the location of the business this service area applies and fill in what information you can about it. for more info see the OSM wiki amenity=social_facility .

for the spots were I was uncertain I left them without any construction tagging and will go back in the near future to determine which parts are under construction; so essentially work still needed.

As previously mentioned, the canal is one conceptual object and thus should have one area representing the area it takes up. It is also significantly easier when edits to one part of the canal do not generate a changeset comment the geographic size of the canal. When an area is attached to a relation of any sort it can be a pain to detach it and update it at a latter time so it is better to do it as a multipolygon from the get go. There is also the fact that when multiple land use areas share parts of polygons but are not mapped as multipoygons there is duplication in the data and that is something I try to avoid in Miami dade county, I also find it significantly easier to update and fix land use when it is mapped as multipolygons rather then simple polygons especially when mapping areas that cover relatively large amounts of space.

As for the grass along the highway it would anyways need to be done as a multipolygon as I am mapping the barriers and other such features along the highways in Miami Dade and as I go I add the land cover along the right of way of the highway and attach the land cover to the barriers added, and as to (as mentioned above) not duplicate geometry I do them as multipolygons; and as such since there is usually one continuous stretch of grass along both sides of a highway it only makes conceptual sense to merge the multipolygons together into one for each section of the highway.

For these reasons, and more, multipolygons are the best way to map land use and land cover in my opinion, and thus we should have /more/ of them, they should be the default in my opinions with the obvious exception of a single land use area not attached to anything else.

Happy mapping,
Udar

It is a multipolygon first and foremost because it is land cover and the best way to do land cover (and land use) is multipolygon, though second of all it is a multipolygon is because parts of it span large areas so editing one of the ways that make up its edge does not make the changeset geographic area unnecessarily large, and last but not least the multipolygon represents the whole of the area the canal takes up and since it is one canal it is one area and thus the best way to represent it, as one single object in the database.

Again adding non multipolygons attached to a multipolygon makes it significantly harder and time consuming to fix and update so I would greatly appreciate it if you would do them as multipolygon from the get go. Again this is land use and thus should be done as multipolygon.

I have asked you this before, when you add landuse attached to multipolygons, please do that landuse as multipolygons.