Hi, Please don't create overlaps between Fairways and Greens polygons. See here: leisure=golf_course#Common_mapping_pitfalls

PS Let me know if you need more help!

The way how you can do it in iD editor is to select a node that belongs to Richmond Drive (either exiting or creating a new one with double click), right click and choose 'Split'. Then select the newly created fragment and change its type to 'Driveway' and remove the name.

Also it's better to remove the 'yard' polygon as that one is incorrectly mapped.

Cheers

Hi, and welcome to OSM. I am guessing you wanted to change the end of Richmond Drive to driveway?
Residential areas are to mark whole areas where houses and residential buildings are; and as a rule we don't give them descriptive names.

I think this all looks great. Thanks!

Thanks, I just guess what it is from the imagery.

Hi,
There are few things in your edits that I need to point out:
1) Don't delete objects just to replace them with a new one. Always update the old shape by dragging its nodes.
2) Don't create overlaps between green and fairways. Use multipolygon instead.
3) Don't map paths by tracing their outline (e.g. way/1174315924). Draw a single line that follows the median of the path.

Please read OSM wiki for detailed information how to do correct edits:
leisure=golf_course#Common_mapping_pitfalls

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).