I will try to ask around and get some kind of consensus. I will refrain from make more traffic light changes in the meantime.

Thank you for keeping all of these business up to date!

Sorry, I didn't make clear in the source tag why I did this.

In the wiki, it indicates you can put traffic lights where traffic is supposed to stop. There's an example of it here:

highway=traffic_signals#Tagging_also_cycleway_traffic_signals

Also, it has been discussed before on the mailing lists (albeit only a little):

https://lists.openstreetmap.org/pipermail/talk-us/2015-July/015111.html

There's also routing software to consider. Routers usually will penalize a route based on the number of traffic lights a user would have to cross. As a more extreme example, if logically it would make sense for you to make a left turn at that intersection, and all of the crossed nodes had traffic lights, the router might try to find a different route altogether rather than having you cross through 3 traffic lights at that intersection.

https://github.com/osmandapp/Osmand/issues/1501

Obviusly, not all routers suffer from this. But I've only seen openstreetmap.org's slippy map as the only software where you can choose between OSRM and GraphHopper for routing engines.

I've had some experience seeing OsmAnd make weird turning decisions. Some of these I help with adding no-straight-on restrictions on slipways, to keep from trying to route around a traffic light.

relation/7687555

I believe it would be helpful if there was a relation for traffic lights. If they can be grouped together as one set of lights coordinating an intersection, I would think it would help routing software to count one intersection with one set of lights regardless of how many lights manage that intersection.

These nodes have been updated. Sorry for the hassle. Refer to changeset # 68183088

changeset/68183088

HTH

Yea, that's the peril of me trying to do field mapping. I only had limited time in this area and there's only so much I can thumb type on a cellphone. I did try to leave source tags to make it easier for other mappers to complete. There are so few mappers interested in Colorado's smaller communities. I will try to complete these nodes

I have removed the incomplete addresses. Hopefully this should clean up the errors a little. See changeset # 65996923.

I was already warned by JOSM that some of these were going to be a problem. I surveyed this neighborhood one day and only captured housenumbers. The cul-de-sacs are named differently than the adjoining streets, and I didn't expect the numbering to be as contiguous between the street and the cul-de-sac, so I was paranoid about tagging an incorrect streetname. I'm not familiar enough with the area to make an educated choice.

Without Mapillary, OpenStreetCam, any kind of open address datasource, or just driving back to the neighborhood, I don't know how to finish it.

If it's too much of a problem, the data can be deleted and someone with more resources or more local to the area can re-add it.

I forgot to mention. There are other people using source:url.

https://taginfo.openstreetmap.org/keys/source:url

I misunderstood what you found ridiculous. I crudely assumed it was the *generic* nature of the name.

As far as documentation, there doesn't seem to be anything *official*, but that hasn't stopped me from making up tags in the past. (I'm very guilty of applying addr:suite or addr:unit to various businesses.). The tag I propose should still be legitimate on a couple of reasons. 1) the key 'source' has what seems to be an active namespace (i.e. source:*) and 2) an item of '*:url' in namespaces is used in other keys. My one example: inscription=*

I'm not an iD user so I'm very ignorant if you can create freeform tags or not.

HTH

Doesn't sound too ridiculous. Unimaginative? Sure.

You could cite the website using a source tag or even a source:url tag.

Thanks for helping.

Sorry for the late reply. There are ways of undoing deletions, as SK53 has demonstrated. No worries about the mistakes. Thank you for letting us know that data can be brought back.

Thank you, SK53, for helping out on the undeletions!

Can you explain why you deleted these points? How are the unknown? They contained addresses.

Hello, can you explain to me the deletions that you made? I saw and read the link you provided in the changset description. It seems to detail the process it took for the commerative name to take place, but that doesn't explain to me why you chose to delete the additions I made and how they affected the naming of the highway. Thanks in advance.

Thank you for helping out. :)

Thanks for helping out. :)

Wow, did we really lose the City of Fort Collins with this edit?

This should be enough to close Note # 693017

This restaurant is in a residential neighborhood

This looks to be the same as way #431593899 that's underneath this one.

I would argue that these could have been left in place. Transfort may not have routes that are using these stops, but the concrete pads are still in place. I assume that could give Transfort the flexibility to reinstate them in the future should they want to. All of the nodes, if not most of them, should already have been tagged with the disused namespace, so they should not have been visible in Mapnik. Keeping the nodes would have also provided history, knowing that at one time, they served on Transfort's now defunct Route 17.