I was pointed to that resource earlier and used it to correct some trail locations in East River Woodlands. I'll check out Mungar Brook and see where things misalign. Working at the limits of gps/map accuracy leads to continual small location errors as map overlays are generated. Our boundary work uses Google Earth to calibrate map data to actual location, and there year to year location deltas can be in the order of 10's of feet. Of course, relative shapes are much better than that. But eventually, we need to 'call' a boundary position and move onto other properties. Changing subjects, are you responsible for all the work done in Northwoods? It's very well done and a huge effort. Thanks for taking the time to do this work.

-- Yes, there seems to be a mix of both (the state entries seemed to use 'inc'.), but at your suggestion we're removing the 'inc.' As we add/check properties, we'll revise to this standard.
-- The approach we're taking is: if the MAGIC additions appear to be drawing GLCT owned property, their entry will be edited to better reflect the actual boundary lines, and tags will be added accordingly. But if they're flagging a larger woodland (or whatever) area (and that information is largely correct) their entry will be left untouched and the GLCT property will be added as an overlay. The best example of this is in Hoadley Creek. -- We're working alphabetically by our property name (just did Jared Eliiot) so we'll be heading up to Northwoods shortly. We consider Northwoods all the GLCT owned land north of Great Hill Road/Quonnipaug and on both sides of Rt. 77. It's a big area ... the west side boundary is over 17miles in length. Much of what you've done appears to be spot-on. (where do you get your property data from?) If you're serious about doing the work yourself, would you like me to send you gpx files to use as templates? If not, we'll certainly use what you've done as a basis of any editing.
-- Recognizing there's no control in what other apps take from OSM, we figure that 'ya gotta start somewhere'. Establishing a presence on OSM is a worthwhile start.
-- And thanks for the work you've put into accurately adding GLCT properties to OSM.

Your comments are eye-openers in many ways, and it's obvious we need to retrench a bit. Our objective is to convey to end users the extent of our properties as well as provide use and contact information. Focusing on that is important and we'll continue working on the Dudley Barrows property until it's right and conforms to OSM standards. Then we'll go back and correct all that's been done to date. A couple of questions: we've educated ourselves by looking at other entry's and assumed they were 'right'. That's why the 'Inc.' was added to the GLCT name. Is there a single page on the OSM wiki that has an overview for adding a property like we're attempting? Also ... as we look around we often find additions that appear to have been added either automatically or without much thought (for example: meadow or woods designations, which are sourced from the University of Connecticut MAGIC database). These often overlay GLCT properties and adjoining private land, and while not incorrect could easily mislead people regarding access. Should these be removed or modified once the GLCT property has been added? And finally, when areas are believed to be wrong or very misleading, what it the best course of action? Thanks so much for your help.

Hi Andrew,
Removing the individual parcel name information seems to work well ... GLCT wants to have users identify our properties by their overall relation name. But retaining information in OSM makes sense to us ... but we agree it needs to be better labeled. What do you think about using these tags for this information:

notes: Property acquired from: xxx, yyy, zzz

ref: Property assessor’s numbers: xxx, yyy, zzz

start_date: Property acquisition dates: xxx, yyy, zzz

(we already use the 'note' tag for property use information)

I've changed the Dudley Barrows woods using this convention. Do you think this passes muster? Any other changes you think it needs?

thanks for your help

We really appreciate this feedback. GLCT has realized the increasing importance in oversight to our properties in the virtual world and is attempting to add property boundary and access information to OSM, and continually review trail information added by the community. But we're new at this and ignorant of conventions and best practice. Regarding the ridiculously long area Names: GLCT manages groups of properties under one particular name (Dudley Barrows Woods or Westwoods), which we associate in OSM as a Relation. We initially labeled the component properties with a variant of the same name (Westwoods1, Westwoods2), but were advised to choose something distinct ... we chose the name(s) or the prior owners. On large assemblages of properties, this gets out of hand, but we wanted to stay consistent. What would you suggest? We could eliminate the Name entirely and just rely on the Relation. Or just use an abbreviation/number (WW1, WW2).

Thanks for your help. Adding all the parcels to the Westwoods relation is exactly what I wanted to do. I thought I 'd done that when I was editing last, but I'll need to look more closely and figure out what you did and I didn't. I'll simplify the name and add the additional information (property number and acquisition date) as tags. That shouldn't be too hard.

Thanks to you both for your reviews, repairs, and thoughtful comments. I knew I broke the State Forest polygon, but didn't find a way to repair it. Thanks for taking care of that. Regarding the repeated Westwoods names, all these properties are part of what GLCT calls Westwoods. But I can append a number or string after their identifier to make each of them unique (Westwoods-1, for example). But we would like them to have some connection to the Westwoods name. I'll investigate the use of shape files, which I can generate using ArcGIS. But I'll approach more powerful editing with caution ... I'd guess there's strong protections against ignorance (or stupidity) but there are limits when you get in deep enough. Again thanks ... your
help is appreciated.

Thank you for the review and your additions. We're using this as a 'test case' before we upload/correct all GLCT owned properties on the OSM and want to get it right before proceeding. So on future additions, I'll add the tags you've included. Is there a list of recommended tags (or a sample area) we could use as a model? Also, is there any way to upload a gpx file and declare that as an area? We couldn't find a way to save the uploaded gpx and resorted to using that as a template to then draw the property boundary. Using the actual gpx file would be far easier and more accurate.