On Mon, Aug 29, 2016 at 11:20 AM, Martin Koppenhoefer < [email protected]> wrote:
> > > Why? Is there a new trend to avoid relations at all cost? > > it's actually an old rule. Relations, being expensive, should be avoided > where not necessary. They are also less reliable, because you can easily > add tags for the cave to the entrance without finding the cave object, but > to add them to a cave relation you will have to find the relation first > > > I would be delighted if we could do that with landcover multipolygons.. > and maybe we should? > > it's up to you. Landuse and landcover should IMHO be mapped as small as > reasonable, inner members are usually not necessary when you split stuff > into small pieces. Those are more lightweight and easier to modify/improve. > On the other hand there's still use for MPs to avoid overlapping edges: > every landuse will have a neighboring landuse, in hilly terrain (e.g.) > those can have a lot of nodes. > I'd argue that in the last few years, the relation management in tools such as JOSM and Meerkartor has improved to the point where "relations are less reliable" is a rule suitable only for the rawest of beginners or the simplest of meshes. Perhaps my experience has been different from most, because I live and recreate in just those hilly areas. I find, where I've been working, that landcover sometimes, but not always, follows landuse; and landuse sometimes, but not always, follows cadastre (boundary=national_park, boundary=protected_area) Moreover, leisure=park and leisure=nature_reserve and similar things intersect with those in complex ways. I find that I wind up creating multipolygons for my own sanity, even where I could create a compact polygon by tracing adjacent ways. I'm much more comfortable splitting a shared way than I am tracing an adjoining polygon that shares hundreds of nodes, and find the process LESS error-prone, because I'm not going to skip a node inadvertently. Then again, I've just come off a project that involved tidying the topology of complex administrative boundaries like http://www.openstreetmap.org/relation/6362702 - so I suspect that my experience isn't typical. Don't blame me for the resulting mess: I didn't draft the administrative boundaries. The complex topology is enfolded in equally complex issues of public policy. Don't get me wrong. I'll use a polygon where a polygon will do the job ( http://www.openstreetmap.org/way/422887495) - but in the areas where I'm working, simple topologoes like that are relatively rare. Even where they exist, more often than not they share line strings with lovely topologies like the one on the other side of the reservoir: http://www.openstreetmap.org/relation/6364894. Physical features tend to have that level of complexity (waterways have bays and islands; mountain ridges run in complex branches, and so on). I tend to assume that cadastre will be equally complex, land use nearly as complex, and land cover highly variable (trees and beavers are no respecters of property lines). This leads to some pretty odd overlapping multipolygons at times: http://www.openstreetmap.org/relation/6385235. If I'm going to preserve the fact that Crary Mills State Forest is a single administrative unit, all managed for forestry, with pubic access for recreation (but with varying actual landcover, since there are marshes, scrub lands, power and transportation corridors within it), I'm going to wind up with something that's tricky to edit. It's surely untidy, but that's the world I inhabit. I map what I find, and I use the features that I think most accurately represent it. Incidentally, I have a very strong preference NOT to share ways between land cover and land use, unless the land cover very obviously follows the formal boundary (and often not even then). It makes the common case where a natural feature crosses a property line much easier to deal with if I don't have to interrupt the natural feature at the administrative boundary. No doubt I'm doing it all wrong.
_______________________________________________ Tagging mailing list [email protected] https://lists.openstreetmap.org/listinfo/tagging
