Hi,
and thanks for trying to improve OSM. However it would have been better if you had discussed your data import prior executing the upload.

There are official guidelines for how to proceed with adding new data in bulk: osm.wiki/Import/Guidelines
At minimum, would you mind to go to OSMUS Slack and discuss your intentions there in the #import and #local-connecticut channels? https://slack.openstreetmap.us/

Just briefly looking at the imported nodes I can see issues like:
1) name= tag values are all upper case. Which is not how we write names.
2) All nodes appear to have a FIXME note: "This bus stop could be redundant". It is not clear what does that mean; and who and how will determine if the stop is indeed redundant.
3) I am not sure what gtfs_id, gtfs_stop_code, route_ref represent or if they are anyhow important information that need to be in OSM. Also a typical syntax is e.g. ref:route=
4) Is it really true that stops in Hartford belong to network=CTTransit- New Haven ?
5) the network tag value has a space after the dash. Normally I would think that "CTTransit" would be sufficient, but if we really need to subdivide then maybe come up with some logical system of the values like "CTTransit:NH"
6) some of the tags e.g. gtfs_id have value "missing". If the value is not known then the tag should not be present.
7) You are also missing a tag that would describe what those points actually are. I assume these are places where people wait for a bus. So in that case you need something like public_transport=platform + highway=bus_stop. More documentation here: highway=bus_stop

Cheers

Hi,
just a heads up, here you deleted a line that was part of administrative boundaries. Now it's fixed.
Cheers

The most northern three buildings (e.g. way/1170460647) though seem to be in a process of being replaced by new structures. Check out Bing imagery which is the most up to date for CT.
There are already some building outlines that you could trace if you want.

It should just be a CDP

Hi. Thanks for improving OSM. Would you mind explaining more the reasoning for the name change? You message got cut off.
I tried to search for 'Leatherman Cave' and found eve n a bunch of YouTube videos about it suggesting this is a common name.

They had golf_cart=designated access tag, which indicates who can use them. I feel like the not approved golf=cartpath was just created by TGC mappers for their own purpose.

Hi Tyler, thanks for editing. However in this case that park already exists in our database. See here: way/414673998

Hi, I can see the good motivation behind this, but those maps made a choice not to show the hiking trails and using name= tag for this purpose is kind of like hacking the information in. This will then also cause problems for other maps that do not expect this. Generally there is a rule 'one feature, one OSM element' and so it's better to keep those as hiking relations.

You can add this layer to Gaia that will show the hiking trail overlay: https://www.gaiagps.com/maps/source/openhikingmapHD/

Or use other apps that were designed to show the trail information like Mapy.cz https://en.mapy.cz/turisticka?x=-72.5859911&y=41.5193115&z=15), OsmAnd (https://osmand.net/blog/routes/) or Waymarkedtrails https://hiking.waymarkedtrails.org/#?map=16.0/41.4531/-72.9287)

Hi and thanks for contributing.
Just one thing, the color of the trail does not belong to the path name but as a color= tag on a hiking relation.
e.g. relation/13131309

There seems to be also bicycle=use_sidepath value
osm.wiki/Compulsory_use_of_parallel_way

But my concern is more about general access=no restriction. If some kind of routing software does not recognize motor_vehicle= tag then it would prevent routing cars through that road. Having access=yes + osm.wiki/Tag:bicycle=... would be more failsafe.

Hi. Does this mean that there is sign forbidding access of bicycles?

if yes then I think better would be to have access=yes + bicycle=no.

More information about the correct format of address and opening hours can be find here:
addr:*=*
opening_hours=*

Hi,
the question is if the border is officially defined as the center of the river or rather as fixed coordinates (where the river was centuries ago).

Thanks for catching those. I have no idea how could that have happened.

Although according to Esri and CT ECO imagery the original shape seems to have been correct. Maybe it's the town boundary that is on wrong spot?

Ah you're right, the duplication was there before.
Though I think in this case it was supposed to be resolved the other way around: keep tags on node and remove them from area.
Since surveillance cameras are defined as point features
man_made=surveillance

Hi, thanks for editing.
Just be careful, here you moved surveillance camera tags from a node where the camera is located to the whole parking lot area:
node/2738874385
way/268535989

Hi, thanks for updating all those information. But what I noticed you accidentally added a number to the name of the store e.g. O'Reilly Auto Parts #6372

If that is some sort of a unique code for that particular branch then it should most likely go to ref= tag.

Hi and welcome to OSM!
The buildings that you drew/edited are not quite correct. You tried to trace the shape of the roof from the aerial imagery, but because the images were taken under an angle the shape looks skewed.
The buildings outline we typically draw are as if you are looking at the building directly down from above. That means both buildings should be a perfect rectangle.

Second point is that you moved Jojo's pizza restaurant to a parking lot. If the original location was really incorrect then the restaurant point should be positioned over a building where the restaurant is located.
cheers

Yup.. I am still slowly making my way through an ancient waterway import from NHD that was done 13 years ago.
Well important is that OSM keeps improving with every edit...