good work

I rode this bus today (08/28/2024) from MDC building M to Southwest 88th Street & Southwest 77th Avenue bus stops so I can confirm that for this section this rout (104 eastbound) has this alignment. There may be other differences elsewhere on this route but I cannot be certain of that. I know that the routes changed last November but I don't know if the official gtfs files from Miami Dade county public transport can be used as a source for OSM edits.

Please respond

A few questions:

Why do some of the route names have “.gpx” in them? Does the actual name of the route contain “.gpx” in it or is that from were ever your getting these alignments from because if so you should probably check the names and remove such errors before uploading.

Second of all the naming in general seems of since these names are nothing like every other public transport version 2 route I’ve ever seen so the naming might need another pass and a few fixes.

Third all or of these are missing important fields like “from”, “to” and others and times when they are provided they are only partially there, for example from a cursory loo through I found a few that have “colour=#” with nothing else provided which seems odd since the actual color in use comes after hash symbol usually.

Some of the routes also have obvious holes in them.

Happy mapping,
Udar

What’s the source for this?
I ask because this does (based on the imagery) very much seem to be a bike path that allows bikes traveling on miller road to navigate the roundabout through the pedestrian crossings by entering the sidewalk network were this way meets the road. This is a common pattern you will see in other parts of Miami dade, were at roundabouts you will see bike paths like this going to the street and thus allowing bicyclists rinding on that road to transfer to the normal sidewalks so that they can cross the roundabout through the same crossing individuals walking will use since it is safer that way.
Also as previously mentioned unless there’s a sign saying that bikes aren’t allowed on this way bikes are allowed and there isn’t any signs showing that in this area (based on the bing imagery available in iD) so bike=no shouldn’t be on this way. Also if this truly isn’t a bike path then it should be a sidewalk.

bicycle=unknown Is discouraged from being used (aka an incorrect tag) on the osm wiki so it shouldn’t be used; you not knowing if bikes are allowed on a pedestrian path does not need to be tagged, unless there’s a sign saying that bikes aren’t allowed it is implied that you can. For more information see the “ Possible tagging mistakes” section on the following wiki page bicycle=* .

Why deleted these?

As mentioned previously I think 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.

Happy mapping,
Udar

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.