Since I've not yet heard anything from the too-long message below,
let me summarize my plea for help. My lack of understanding is blocking
my attempts to do any repair on the NYS DEC Lands import, and making
me concerned that the NYC DEP Watershed Recreation Areas import
will need a revert. (The latter surprises me, since the geometry and tagging
were both generated by ogr2osm from well-formed multipolygons in a
PostGIS database.)
Russ has expressed concern that the proposed repair of the
NYS DEC Lands import will damage
https://www.openstreetmap.org/way/32036186
which is closely related to
https://www.openstreetmap.org/way/387275831
and
https://www.openstreetmap.org/relation/91728
What I see in the external data is illustrated in:
https://www.flickr.com/photos/ke9tv/27805345215
The red polygon is the outline of the 91728 relation. Crosshatched polygons
are other polygons from OSM. The magenta area is the state forest. (There's
a slight misalignment between red and magenta. That is part of what a
reimport would be trying to fix.)
There are no tags on the 91728 relation apart from type=multipolygon. All
of the tagging is on the outer way. There's a natural=wood tag on the inner way.
Russ says that he did it as he did in order not to have to repeat natural=wood,
but I surely don't understand the tagging as it stands. He is sufficiently self
assured that I'm convinced that my understanding of how multipolygons work
is wrong. I would have thought that to represent data that belong to the
polygon-with-a-whole, tags would have to be applied to the relation, and not
to the outer way. Tags applied to the outer way would apply to the hole as well.
But that's surely not what Russ intended, since the state forest does
not include
the private inholding represented by the hole.
The only way that I can see the current tagging working is if there
is some hidden coupling where it is understood that tags that apply
to an outer way of a multipolygon relation actually belong to the relation
itself, and the inner ways are excluded implicitly. If so, that puzzles me,
because that's also not what I see the renderer assuming.
Can someone please explain to me how I should be tagging things
so that the polygon-with-a-hole becomes a protected area? The ones I did
in the Catskills, like https://www.openstreetmap.org/relation/6304902
appear to render as I intended, but I know that there is lots of nonsense
tagging that still renders prettily.
Kevin
On Sat, Jun 18, 2016 at 4:02 PM, Kevin Kenny <kevin.b.ke...@gmail.com> wrote:
> I'm looking at that relation, and I really don't understand what
> you're trying to accomplish - although when I run it through my
> script, the script at least detects the tagging as something that
> requires manual inspection. When I got to that parcel, I'd surely be
> writing to you, asking what you meant by it! I suspect there's
> something badly wrong with my understanding of multipolygons.
>
> When I look at the multipolygon relation, I see no tags, which makes
> its purpose difficult to understand. What is the meaning of a
> multipolygon without tags? It's a piece of land, about which no
> information is given.
>
> The tagging for the state forest is all on the outer ring, which,
> according to what I had previously understood, means that it applies
> to the entire interior of the area, including the inner ring. I don't
> think that's right, but you're local and I'm not. I haven't been there
> in the field to see the posters and survey blazes, but the current
> version of the NYS DEC Lands file shows a parcel with an inholding. I
> assume that you intended by your tagging to assert that the DEC Lands
> file is obsolete and incorrect and the inner parcel is actually part
> of the state forest? If so, I defer to your local knowledge.
>
> The inholding is tagged with 'natural=wood', which would make its
> interior 'natural=wood' AND part of the state forest. That's
> reasonable, I suppose. landuse=forest doesn't necessarily imply tree
> cover (a piece could, for instance, be incompletely regrown from a
> clearcut). I'm trying to avoid reigniting the whole 'forest
> controversy' - we have land use ("this area is managed for the
> production of timber"); land cover ("this area is covered by trees");
> and cadastre ("this land is designated as 'state forest', and as such
> is protected from sale or development and open to the public for
> recreation when logging is not in progress"). The current tagging
> structure doesn't distinguish the concepts well, but I see that as
> something I just have to live with and tag as best I can. natural=wood
> or landcover=trees appear to be the best tags for land cover,
> landuse=forest an appropriate tag for a producing forest, and
> boundary=protected_area to describe the status of protection and
> public access,
>
> So the semantics appear to be that the entire outer ring is the state
> forest, there's an inner area that's a wood (as well as being part of
> the state forest), and there's a multipolygon of unknown purpose
> joining the two.
>
> The way that I've handled parcels with holes in the past - and what
> ogr2osm generates - is a structure where the tagging for the parcel is
> on the relation, like https://www.openstreetmap.org/relation/6304902.
> Mapnik certainly appears to understand that situation, as do QGIS and
> JOSM. The 'protected area' shading appears on the correct side of the
> lines, both inner and outer. In this specific case I've not specified
> land use or land cover on the inner rings - I've not been to those
> specific sub-areas in the field and don't know what they are. I have
> been to the reservoir and can confirm that there s one private
> inholding on the north shore that's posted. And there's no tagging on
> the outer ring, because I had no common features that I wanted to
> specify between the enclosed area and the holes. There's at least once
> case in the Catskills where one of the inholdings in a "hole" in a
> Wild Forest is a NYC recreation area, and the proposed fixup describes
> that situation accurately.
>
> So, if I were conflating your changes with mine, and making what looks
> to me like a reasonable assumption, I'd put all the tagging for the
> state forest parcel on the relation that you directed me to, have no
> tags on the outer ring, and retain the natural=wood on the inner ring.
> If the multipolygon and all holes shared some attribute in common, I
> might promote that to the outer ring, but I try to avoid that, because
> it's brittle - someone changing the attributes of the outer way may
> not realize that the inner way will be affected.
>
> But this is one parcel where if I couldn't reach you, I'd likely just
> put the reimport in abeyance because I don't just overwrite the work
> of mappers willy-nilly.
>
> If I've erred on the way parcels with holes are handled, I need to
> know ASAP because I'll need to revert or repair the NYCDEP import.
> There were a bunch of holey parcels in that data set. In that case,
> I'll also want to involve the developers of ogr2osm, because that's
> also the way that it converts multipolygon data.
>
> Can you suggest a better path forward? Considering the number of
> changes that there are between "NYS DEP Lands" as imported and the
> current version of the file, which include not only several
> significant land acquisitions but also significant realignments of the
> property lines, I'm reluctant simply to leave the seven-year-old
> imported data as it stands.
_______________________________________________
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us
