That is usually the sort of difference I note for ponds and lakes as well. For OSM, any natural body of water is a lake and any man-made body is a pond. That’s for that resource - it’ll certainly help!

Here in Canada, land use areas are vital. With so much space available to us, we tend to waste large quantities of it out of hand. This makes tagging the use of the land, especially within a Town’s limits important. Not all the land in a residential area is actually for residential purposes - some of it is retained by the municipality for a variety of reasons. The popular tags in OSM tend to be very Euro-centric, at least when compared to Newfoundland. For example, I have never seen an area designated for locals to grow their own plants being provided by the town. You do that on your own land - not public land. Here, you will get a large area of open grass and trees that is un-managed by the town. You are allowed to enter and use these areas, but not to remove the trees or erect permanent structures. These are called all sorts of things - each municipality has different phrases for these areas. Some seek to develop them for more structured use while others allow them to grow wild.

I am tagging for the map. I intend to, as much as possible, use the tags that are common rather than amking up a pile of my own that won’t ever get rendered by any of the map engines out there.

For the municipality lands … I am not sure how it is done in the UK, but here the Government lays out the parcel of land that a municipality owns via an act of Legislation. For the town I am working on, the official Canvec data was imported for the area before I got to it. I use that as the base and refer to the Legislation to ensure that the lines are accurate.

I didn’t know about the grass designation - I will switch off to using that instead of village_green. Seems to be more applicable.

Followup question - for areas of both grass and wood, would it make more sense to try to split the area into the grass and trees sections or to flag the whole area as grass and add the natural=wood tag to it. The trees are not for harvesting nor are they groomed or maintained.

Yeah, my auto-correct must have grabbed it. Thanks for the heads up - that is what I meant.

I can understand that it is a stretch, but it would be nice to have something that shows on the map to use on these places. It might not be vital, but it will look a whole lot more integrated.

Thanks for the pointers, @Vincent de Phily.

I have a related question - what do you do in circumstances where the coastline and the administrative boundary have been merged?

@SK53

That is very interesting - I can see why some might think having a lot of detail on a map might not be efficient. Can it be a sort of minimalist mentality? In any case, I don’t have the same outlook. As an Auditor, I have found in my job that detail being made available is never a bad thing. If the information is present in the database, it is then up to the individual or group drawing on that data to determine if they want to see it. As long as it is accurate, then the users should benefit from the attention to detail.

@russdeffner

That is a good idea - I will likely integrate something similar in my area. The land use tags seem good for blocking in the major sub-areas (residential) instead of mass-setting an entire municipality as one and trying to back off sub-polys within it later.

@SK53 @Circeus @cartinus @CloCkWeRX

Thanks for the comments so far - my take is that the more data that is available to the users, the better. I notice on the public map, the polygons that make up the individual plots are merged for display. Given that, I am going to make the assumption that the actual polygon weight for the purposes of rendering the images is rather low. Poly limits for the actual display will be fairly low anyway, as long as one doesn’t get so ridiculous as to note a pile of sub-shapes in the properties (such as for the compost bin and such).

Structured correctly, I imagine the database weight for the same information should be fairly low as well. I am not aware of much of the structure of the backend of the database for the project, but I can understand that too many shapes in the same place can be a bit of a problem. My intent is not to have too many overlapping polys. I have done some 3D work over time so I am aware of the troubles that this can cause. Still, my intent is not to get completely ridiculous with the concept of nesting polygon within themselves. Residential buildings are situated on an entire property area, so that polygon will nest within the larger property polygon. Things like driveways need not be poly-shaped - that can be saved for ways instead, which reduces the overall weight of the information.

I have done some looking and seen several posts with individuals experimenting with structures for neighborhoods including adding fencing ways and similar. So there are some wide opinions on the matter.

The Land Use tag is an interesting issue in of itself. If I denote an area as “Residential” and then mark the properties within as individual private parcels and the buildings (both the homes and the auxiliary buildings), then I have effectively nested a poly in a poly in a poly. Not sure if that is the cleanest idea, but it does aid the idea of a wide range of potential queries to the database information. There are no “right ways” to do something - push with what you got and see how others react. Though I do wonder - if you are marking the land use, do you mark the roads themselves as residential or commercial, etc? If that is the case, the land use poly can be slightly larger than the individual property polygons, greatly reducing potential problems by not having too many edges leading off of a single vertex. In computer graphics, that is known as a rats nest and systems generally hate that. The other similar route to take is not to include the roads, but to encapsulate the properties out far enough to include the easement for public foot traffic (sidewalks). That again serves to keep the polys nested within each other as a whole. Bears some experimentation.

@compdude

I find the same thing - here in Canada, we are somewhat like the British being that we have been part of the Commonwealth, but being that we are geographically very close to the Us, we have adopted some of the road features there. OSM has a strong orientation in the mapping structure toward Europe. Not that this is a major problem - but it can cause some interesting difficulties. I am using ID mainly to edit with and some of the tags for roads are generally not used here - you just sort of pigeonhole them into place.

@robert

Thanks for the link - the difference is quite striking! I do not hate Google for wanting to get information like this. After all, people are the greatest source of Geographical Data available. But I don’t like the idea that the information entered becomes their property and falls behind their limited license for use. In the aggregate, I’d rather contribute information to an open project wherein people can view, modify and use my contributions rather than help expand a closed wall.

Thanks for the welcome,Harry. I’ve played around with Google’s maps mostly for the same reason that I imagine that a lot of people do - It’s Google! They’re the good guys - do no evil and all that friendly stuff. Most people think that automatically and figure that they’ll just give them a hand. Why not? Surely Google will appreciate the effort.

But that is not really the case. Google is using it’s massive user base to crowd source it’s map data for it’s own gain. We are basically helping them create proprietary information for their database that they can then dictate the terms of use to others. That is bad enough in of itself, but the insult to that injury is that we are second guessed in the process. Taking the time to update records and add to the map only to have them get picky about it is beyond belief. OSM is both open to editing and open to use by any that need mapping data. That difference is quite striking.

Thanks for the comment, Hjart!