Wouldn’t the homes here be more duplexes them townhomes (semidetached), and even if we stick with terraced houses I think the correct tag would more likely be house=terrace not house=terraced because terrace is for the outline and terraced is for when mapping the individual units.

Happy mapping,
Udar.

Honestly it would be better to keep both in this situation, the tagging on the road and the area representing the area the street side parking actually takes up.

Ok, I had a hunch it would be that way myself but all available sources to me didn’t have any such indication so I left it there from when I had mapped it previously and the latest imagery didn’t show anything under the bridge and according to that imagery it looked like that the connection to the ramp was going at that location. I still think that there will be a connection from the HEFT southbound to Dolphin easthbound ramp to this new ramp so that traffic can go from HEFT northbound to southbound directly.

Happy mapping,
Udar

What does “Bellweather” mean, it doesn’t tell others very much about what was done in the commit. Next time please provide a better change set comment, for more information see osm.wiki/Good_changeset_comments.

Well we can’t use any google data as a source for commits on OSM so it doesn’t really matter what google earth shows. We can only use survey, local knowledge (essentially mapping what you have seen with your own two eyes) and what is available in iD and other editors and any databases that are licensed with a license that is compliant with with OSM’s license or the owner of the data source has given us (the OSM community) the explicit right to use that data for commits to OSM. Google doesn't fit any of those criteria.

Is the barrier fully built along it because there are some holes in the barrier on the bing aerial imagery.

Those are the id’s of the ways in the database. If you look at the bing there seems like there’s a path from the existing ramp to the new ramp from dolphin that connects after the bridge on the new ramp.

Based on the latest imagery it is unclear whether or not there will be a connection at the previously mapped point. Also what is the source for this commit, how do you know any of that.

Based on the imagery it seems that way/87553270 will connect to way/1300208858. Also what is the source for this commit, how do you know any of that.

Why did you add lane and turn lane tagging on a underground cable tube. The ways added/eddited in this commit don’t have highway=* on them they have power=cable.

Generally when mapping running tracks both the way in the center of the running track and the area (usually multipolygon) describing the area it retakes up are both left there so way/1306069618 probably shouldn’t have been deleted. Just a note for the future.

Happy mapping,
Udar.

No, it’s ok, just don’t do that in the future in Miami dade. crossing=marked is the old tag and still exists in parts of Miami dade from previous contributions but I have been trying to replace them with crossing=uncontrolled when I see them, you don’t have to unless you want to. When your adding new crossings (ways or vertex’s) what ever tags Rapid adds by default is ok, I’m just asking about the ones that were already added (already existed). If you think the type is wrong of an existent crossing then obviously change it and again you don’t have to remove those tags from the new features you add. This is an issue with Rapid its self and would have to be fixed there so I am planning to put up an issue on there soon to figure it out there. Assuming Rapid works the same as iD in this situation when you select “marked crossing” it should add crossing=uncontrolled as the tag.

Happy mapping,
Udar.

Sorry forgot to put in the above that the above would be for Miami dade county since I don’t know the wishes of others in other localities.

If it sais marked (at least if Rapid does things the same as iD) then that means that the tag being used is crossing=uncontrolled. What I am asking is that on the already mapped crossings that the “ambiguous_crossing” related “issues” not be “fixed” because they aren’t fixes because those tags are implied. This is because the difference between crossing=uncontrolled/unmarked and crossings=traffic_signals is whether or not crossing:signals are present; so is thus implied. It’s ok if it’s added by default, just look at the tags in thee tag edit in the bottom and if the tags have crossing=uncontrolled crossing=unmarked or crossing=traffic_signals you not “fix” the “ambiguous_crossing” related “issues”.

crossing:signals=yes is implied on crossing= traffic_signals so please stop adding it on existing ways, Rapid is incorrect for calling it an issue, so don’t “fix” these in Miami dade county please. I have made this request multiple times.

Happy mapping,
Udar

crossing:signals=no is implied on crossing=uncontrolled so please stop adding it on existing ways, Rapid is incorrect for calling it an issue, so don’t “fix” these in Miami dade county please. I have made this request multiple times.

Happy mapping,
Udar

crossing:signals=no is implied on crossing=uncontrolled so please stop adding it on existing ways, Rapid is incorrect for calling it an issue, so don’t “fix” these in Miami dade county please. I have made this request multiple times.

Happy mapping,
Udar

All of the commits from this user seem to SEO spam and the features added don’t seem to have much information in them and themselves seem to be SEO stuff also.

How do you convert a road to a sidewalk.

Next time you delete a building with address tags (addr:*)=* please first extract those tags into a separate freestanding node so that that information isn’t lost since the address still exists the building just doesn’t.