No probs. OSM is so complicated. Cheers ;)

Thank you :)

Hello :) Thank you for your additions to OSM. The road you added here is inside an active construction zone. If you use the latest imagery (Maxar) you'll see this road and the gates you added do not exist. Thanks :)

is_in=*

Howdy :) I don't know if you've had the chance to read the wiki page for the Key:is_in, but I think this tag is mostly not added these days. It still exists, but I don't think it's used much. As the wiki says, "The is_in tag pre-dates boundary polygons. When a region has a well developed set of boundary polygons the information that could be placed in the is_in tag on an object can usually be derived from the boundaries that contain it, in which case the information in the tag seems redundant." I'm not saying it's "wrong" to use it, but I think it's redundant these days since the boundaries of Colorado are well established. Cheers :)

Hi. Thanks for your reply. Sorry for not being more clear in the first part of my comments. Anyway, in OSM there is a rule “An OSM element should represent a single on-the-ground feature once and only once”. It’s the, “One feature, one OSM element” rule. I’ll leave a link to that below.

Of course, there are many cases where we can map elements in different ways. For example, a parking lot can be a node or an area, but not both. Bike lanes can be mapped separately along a street, or simply be added as tags to the way itself, but not both. There are many examples, but suffice it to say; one feature, one OSM element, not two.

When it comes to pedestrian crossings, maybe a good comparison is a dam. A dam can be mapped with tags on a node in a river or a stream, or the dam tags can be added to a way crossing the river with an intersecting node (the node not containing dam tags) or it can be mapped as an area, but it would not be mapped with all three methods - or two methods. A single method is the rule.

So, a single element, such as a single pedestrian crossing, would be mapped with a corresponding single element, not two. It can be mapped as a way crossing a street (appropriate tags on the way) with a connecting node, or it can be mapped with the appropriate tags placed on the node, but the “crossing” tags wouldn’t be placed on both the node and the way.

I went ahead and just now mapped a four-way stop with pedestrian crossings. I mapped two of the crossings with tags on the way and two of the crossings with tags on a node. All are equally correct, but we wouldn’t use both methods on the same crossing. That is, we wouldn’t tag both the connecting node and the way with pedestrian crossing tags.

Finally, the wiki page on Tag:highway=crossing (link below) specifically mentions this issue because it is a common mistake, which I’ve been guilty of in the past myself. Many of the wiki pages were created by non-native English speakers and some additional clarity is probably necessary, but the meaning is clear.

Anyway, I hope that clears it up for you. Thanks again for your mapping. Cheers :)

Pedestrian crossing example; four-way stop
osm.org/edit#map=21/39.71293/-104.98038

One feature, one OSM element
osm.wiki/One_feature,_one_OSM_element

Tag:highway=crossing
highway=crossing

Howdy :) Thanks for your edits to the map. Looks like Bean Ranch Road crosses a couple of intermittent streams here. You may not know it, but anytime this happens, there needs to be some sort of connecting node, bridge or tunnel. Otherwise it pops up as an error. If you have any questions or need any help, please let me know. Cheers :)

Howdy. Thanks for your edits around Denver :) Just a note here on the edits you made to pedestrian crossings, I know they can be confusing. It seems there are like a gazillion ways to map them. I’ve struggled with it myself in the past. Anyway, following the OSM rule, “An OSM element should represent a single on-the-ground feature once and only once”, we should only map a pedestrian crossing in a single way, not in two ways. That’s to say, we wouldn’t map the crosswalk as a “way” and also as a “node”. Either a node or a way are correct, just not both. The way I prefer to do it (just my preference) is, for example, to mark a sidewalk along the street and continue the sidewalk into the street. I place the crossing information on the connecting node of the sidewalk and the street. (example link below)

Also, I see you’re using the, “marked crosswalk” method on the node where the street and the path meet. I used to do this as well, but I had to stop since either I was doing it wrong from the start, or more likely, the OSM wiki changed and I never noticed. If you go to the wiki page for, “crossing=marked”, (link below), you’ll see this type of marking is used only, “with crosswalk without traffic lights”. If a pedestrian crossing is controlled by traffic lights, it should be mapped as, “highway=crossing” with “crossing=traffic_signals”. If I got any of this wrong or if you have any questions, let me know. Cheers :)

example:
osm.org/edit#map=21/39.72565/-104.98501

wiki page:
highway=crossing

Thank you :)

No probs. I doubt your specific edits here are flagged yet, but they will be ;) It’s takes a day or two for the QA tool to update. The QA tool is Osmose. It's quite good. If you click the link below, you can see the errors for edits very similar to yours, but made by a different user. When you click on the link below and then click on each issue marker, the green ones are specific to "Missing access way to parking”. If you then click on the “i” button in teal color, it will give you a suggested correction. With Osmose you can discover a great number of “suspected” errors in OSM.

If you're interested in learning about various QA tools, proper mapping techniques or what we Colorado mappers are up to, you can find many of us on Slack, #local-colorado. On Slack you can find old and new discussions.

Cheers :)

http://osmose.openstreetmap.fr/en/map/#zoom=18&lat=39.798987&lon=-105.072824&item=xxxx&level=3&tags=&fixable=

Looks like I need to correct what I said here. I just re-checked the parking page and it looks like access=yes indicates a public car park. So, disregard what I said about access=yes as it pertains to a car park. Cheers :)

Howdy :) I see your comment here about the building being underground. Since you're curious, I can explain what happened here. It looks like this building slightly overlaps with the building next to it, creating an error in a QA tool. A user (apparently, "Bike 2 End") saw this error and decided the best way to fix the error was to make one building above ground and the other underground, which is incorrect. I've corrected the errors here. Cheers :)

Howdy! Thank you very much for your additions to the map :) In this changeset I see you're adding the tag, access=yes. Actually, the default for access is yes. If you add the tag access=yes, that means you want to change the default, for example, if a parking lot doesn't allow buses, then you would add, access=yes, bus=no. I know it's a bit wonky, but essentially, access=yes would not be used unless you want to restrict something from the parking lot like, access=yes, pedestrians=no. The OSM wiki page is long, but you can see it in the link below. If you have any questions, feel free to ask. Cheers :) access=*#Transport_mode_restrictionshttps://wiki.openstreetmap.org/wiki/Key:access#Transport_mode_restrictions

Howdy :) Sorry to nitpick, but just in the interest of getting this all mapped correctly…To the north of the secondary road, Market Place, it is an unclassified highway. The secondary road and the unclassified highway all look fine. Very nice.

But, it looks like there are a total of eight relations attached to the secondary road, Market Place. I’ll list the relations from top to bottom and you can tell me how you feel about my interpretation. My comments will be in parenthesis.

Relations:

No U-turn (this looks correct)

No Left Turn (this looks correct)

No U-turn (this looks like a duplication of the first relation?)

Only Right Turn (this one I don’t understand - this is saying only right turn for the entire length of the road? Is this correct? It seems a vehicle can continue along this road making left turns, right turns and going straight through?)

No U-turn (this looks correct)

No Right Turn (this one I don’t understand - it seems the service road on the south side of the intersection is not mapped correctly - I think it should go north to the intersection and be connected to the sidewalk via a connecting node? I think a right turn from the service road should be allowed? But, maybe you know this intersection better than me?)

No U-turn (I don’t really understand what this is supposed to mean)

No U-turn (I don’t really understand what this is supposed to mean)

What are your thoughts on all this? Cheers :)

Howdy. Thank you for your responses :)

The OSM wiki on amenity=parking says,
“Do also note that roads, footways, etc. into the parking area should connect to each other within the parking area, not only to the edge of the parking area (a very common mistake).”

The key phrase here being, “within the parking area”, not outside the parking area nor alongside the parking area, but “within the parking area”. Now one might argue that as the parking aisles are mapped right now, the parking aisles are not actually “within the parking area”. Except…

The OSM wiki on tag:service=parking_aisle says,
“A parking aisle is a service road that passes between one or two rows of parking spaces (amenity=parking_space) in a parking lot or parking garage (amenity=parking or possibly amenity=motorcycle_parking), providing direct access for a motorized vehicle to enter and leave a parking space.”

The key phrase here is, “in a parking lot”. A parking aisle should be “in a parking lot”, not near a parking lot or mapped alongside a parking lot or mapped between parking lots, but “in a parking lot”.

In this situation, QA tools will tag these individual parking lot areas, without access for a vehicle to enter them, as errors. True, not all QA tools are correct, however in this case I would certainly agree with a QA tool which identifies this as an error that needs to be corrected. Personally, (granting that I may intuit differently from others), it makes sense that a “parking aisle” should physically interact or overlap with a “parking lot” (although there is no need for a connecting node). This seems reasonable and it’s not a big ask for mappers to do this.

I agree that this entire parking lot should be mapped as a single entity.

Again, @jjyach, thanks again for your mapping. Cheers :)

Thank you :)

Howdy :) Thank you for your additions to the map. You may not be aware, but parking areas need to be accessible by some type of road. If they are not, vehicles cannot route to them and they pop up as an error on quality assurance tools. Can you add access to these parking areas? Cheers :) amenity=parking#How_to_Map

Howdy. I can't find evidence for the link you added. Satellite imagery and Mapillary images both show a barrier between the divided highway. Do you have a source for this change? Thanks :)

Howdy :) Welcome to Openstreetmap and thank you for your edits to the map. Everything looks good here, except for a couple of small things. The name tag for an object would only be used for an actual name of something, not a description of something. Also, creating the object, like you did here is correct, but you only need to identify it once by creating the area. Another node identifying it wouldn't be necessary. I've made a couple of changes. Keep up the good work! Cheers :) osm.wiki/Names#Names_are_not_for_descriptions

osm.wiki/Good_practice

Howdy :) Welcome to Openstreetmap and thank you for your edits to the map. Everything looks good here, except just a couple small things. The name tag would only be used for an actual name, not a description, such as, "to be completed in 2020". That would be a description tag or a note tag. Also, the foot path you created around the pond was good, but it wasn't connected to the rest of the map. I made a couple of changes. Keep up the good work! :) name=*
osm.wiki/Unconnected_ways