OpenStreetMap logo OpenStreetMap

Changeset When Comment
160041934 about 1 year ago

next time please split your commit into multiple geographically smaller changes instead of on that is this large. in the case of this commit, based on what I could see in OSMCha this should have been two, one in Puerto Rico and another in Indiantown.

160012782 about 1 year ago

way/786346226

Before you add something please check that someone hasn’t already mapped the building, you may need to change a few tags but adding a new building one top of the existing building is incorrect unless your using building:part=* , this is the kind you of thing we (the OSM community) have tools like osmose and osmi to find along with many others since we don’t want overlapping buildings.

160012546 about 1 year ago

If it is done then it is a parking garage (the imagery isn’t up to date) and it is likely called Parking Garage 6 because that is what the signs on the fences surrounding the construction said when it was under construction. I can attest to it being a parking garage as I flew out and into MIA in July and saw them building it from the other parking garages and the departures road at that point.

160012782 about 1 year ago

this seems to have added a duplicate object

160012546 about 1 year ago

does this mean that the construction there is complete in that area.

159980140 about 1 year ago

are you sure because in the official databases put out by Miami Dade County the address is listed as 17117 Southwest 82nd Court.

159977154 about 1 year ago

next time you add a building please check that your not adding a duplicate, the gas station was already mapped just not tagged as a building.

159962304 about 1 year ago

were did you get the star=* value from, I ask because for that tag we cant just add things from the website unless we know what agency its fro and that the rating that agency puts out is verifiable, for more info see stars=*.

159266749 about 1 year ago

please stop rounding of the ramps, there is nothing on the imagery that suggests that they are rounded like that

159312555 about 1 year ago

please stop rounding of the exit ramps there is nothing on the available imagery that shows them being rounded.

159334992 about 1 year ago

typo, meant to type:
"Add ref numbers to elevator rooms."

159269420 about 1 year ago

Also please stop mapping turn:lane tagging as geometry.

159269420 about 1 year ago

Please stop rounding the ramps of, that is in no way representative of the shape of the ramp.

159269331 about 1 year ago

please stop mapping turn:lane tagging as geometry.

159282486 about 1 year ago

this was already mapped correctly because we shouldn't map turn:lane tagging as geometry.

159256079 about 1 year ago

next time please don't name things with a description since names aren't descriptions, for more info see osm.wiki/Names#Names_are_not_for_descriptions .

159016131 about 1 year ago

also entrances don't go in the middle of a road, they describe places you can enter a building, so usually they are at the spot a footway meets a building.

Happy mapping,
Udar.

159016131 about 1 year ago

if you have access=private on a road or gate it is implied that the other uses are also private, as in if you have access=private you don't need motor_vehicle=private. you only need to specify a value for motor vehicles, bicycles or any other mode of transportation of it is different than the default or is only usable by certain modes like a bicycle and foot path.

also names aren't descriptions.

Happy mapping,
Udar.

158953471 about 1 year ago

so then logically we should also remove footway=* tags. that's the pattern here, you have a tag telling you what the feature is and then then a tag that starts with what it is from the previous tag telling you what type of what it is it is.
for example sidewalks, highway=footway tells you they are a footway but since sidewalks a re more specific than the nebulous "footway" you specify the type of footway with footway=sidewalk. the same logic applies for crossings. highway=footway tells you they are pedestrian navigation features, footway=crossings tells you that the feature is for crossings roads but that isn't all the information that matters about a crossings, you also have to know whether or not its signalized since that is what distinguishes crossings, not how they are marked so you need a crossings=*.
As I clearly laid out in the above post (see it for more detail) this makes crossings:signals=* the imposter here and thus it should be deprecated.

just because the tag crossings=* has in the passed been inconsistently interpreted in the passed doesn't mean it has to now. the change is rather simple in fact, all we have to do is deprecate all crossings=* values other than uncontrolled and traffic_signals (as laid out above); and although that change would make it abundantly clear what the meaning of crossings=* is we specify in the wiki that it is purely for whether or not it is signalized. that is anyways basically the state of things now. again all we have to do is deprecate all 910 other tags apparently.

again, as to keep the tagging internally consistent either we deprecate crossing:signals or both crossings=* and footway=*. pick your poison apparently.

Happy mapping,
Udar.

158953471 about 1 year ago

If we deprecate crossing we would be going against all the conventions that have already been established elsewhere in the tagging, for example we don't describe sidewalks as a set of properties added to ways with the tag highway=footway, we add footway=sidewalk to describe that something is a sidewalk. by the same logic we shouldn't describe different types of crossings with different tagging, we should just say the type of crossing through a crossing tag. in the same way as footway=* tells you the type of footway crossing=* tells you the type of crossing.
∴ if we deprecate crossing=* we should also by the same logic deprecate footway=* since they both serve the same purpose in specifying the type that they are.

I'll add a note here that there are really ony two types of crossings, uncotrolled and controlled(traffic_signals), I agree that the tagging still needs some work, I just think that we should deprecate crossing=unmarked as we did with crossing=marked since crossing=unmarked and crossings:markings=no encode the same information and since they are duplicate information one should be removed. Due to the fact that crossing=uncotroled and traffic_signals (what I'm calling controlled) do not encode the type of marking present at a crossing, crossing:markings=* is neccessary for cases were crossinga:markings is not "no" and ∴ crossings=unamrked should be deprecated. this does not apply to crossing:signals=* since if crossing=unmarked is deprecated then the two values of crossing=* would already encode the same infomation as crossings:signals=* and since crossings=* already exists we dont need a new tag and ∴ crossings:signals=* should be depredcated. essentially we either deprecate crossing:markings or crossings:signals and since it is significantly harder (it takes exponetially more tags) to encode crossings:markings fully into crossings=* it should be the one thats kept since all it takes to encode the same information as crossing:signals into crossing=* is two tags that we already have.

Happy mapping,
Udar.