<div dir="ltr"><div dir="ltr">On Thu, Jan 19, 2023 at 11:06 PM stevea <<a href="mailto:steveaOSM@softworkers.com">steveaOSM@softworkers.com</a>> wrote:</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I will also say that it sounds like you are "right on track" with your small-t town as a place node AND a boundary=census.  <br></blockquote><div><br></div><div>To be clear, I am not advocating for this.  I am in fact questioning the benefit of boundary=census as a thing that exists in OSM.  I'm not aware of a data consumer that uses this tag.  If anyone is, please let us know.  The boundary=census objects I've come across have all been dual tagged as place=town|village|hamlet and there has also been a node with all the same tags.  I can see the benefit of mapping a place as an area and a node, but there needs to be a clear story for how data consumers are expected to deduplicate.  If I were to map a town, village, or hamlet as an area, I would probably look at the latest CDP polygon from the census.  If it looked good I might leave it alone, if it didn't actually seem like a good representation of the built up (urbanized) area, I would modify it.  I've seen some CDPs that seem to very closely match the built up area, and others that seem far too small or far too large. <br><br> In summary: Defining the area of a populated place in OSM may provide value, but the relationship between nodes and areas representing the same thing needs to be well established and supported by data consumers.  CDPs can provide a good starting point for defining the area of a populated place, but I don't see the value  in strictly adhering to census defined areas or tagging them as such in OSM*.<br><br></div><div>Zeke<br></div><div><br></div><div>* At least so far anyway!  I'm happy to be convinced otherwise.<br></div></div></div>