[Talk-us] Proposed import cleanup: NYSDEClands

[Kevin Kenny]

Retrying because a previous attempt bounced:

On 06/18/2016 12:26 AM, Russ Nelson wrote:
>
> Kevin Kenny writes:
>   > The rule for coalescing would be to group by facility number, so all
>   > the parcels of Burnt-Rossman Hills State Forest would be one relation,
>   > while the ones of adjacent Mallet Pond State Forest would be another.
>
> How's that going to work where people (e.g. me) have made changes to
> the multipolygon? E.g. https://www.openstreetmap.org/way/32036186
> where I didn't want to duplicate the "landuse=forest" as I was adding
> landuse= or natural= to its borders?

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, likehttps://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.

On Sat, Jun 18, 2016 at 11:07 AM, Kevin Kenny <kevin.b.kenny at gmail.com> wrote:
> On 06/18/2016 12:26 AM, Russ Nelson wrote:
>>
>> Kevin Kenny writes:
>>   > The rule for coalescing would be to group by facility number, so all
>>   > the parcels of Burnt-Rossman Hills State Forest would be one relation,
>>   > while the ones of adjacent Mallet Pond State Forest would be another.
>>
>> How's that going to work where people (e.g. me) have made changes to
>> the multipolygon? E.g. https://www.openstreetmap.org/way/32036186
>> where I didn't want to duplicate the "landuse=forest" as I was adding
>> landuse= or natural= to its borders?
>>
> 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.