Re: [Talk-us] Proposed import cleanup: NYSDEClands

[Kevin Kenny]

Ok,  it's reassuring that I'm not totally off in the weeds. Private
inholdings in the state lands are more the rule than the exception in the
Adirondacks, so I expect to have a great many untagged inner rings.

I don't expect to cut out lakes. Since the idea is to tag the areas with
boundary=protected_area, and the protection extends to the waterways, the
tagging should as well. To do otherwise in order to make the map prettier
would be tagging for the renderer.

One exception is that the NYSDEC database includes parcels that are
entirely under water. I propose to ignore those at present.

Another detail: There are several places where the parcel lines appear to
align with watercourses. In some cases the forest and the waterway share
ways. I propose to separate them. If a stream changes course, a lake
dewaters, or the beavers flood another few hundred acres, the property
lines ordinarily do not move. Since I'm displacing property lines a couple
of meters inward to reduce GPS noise, the separation should be clean.
On Jun 21, 2016 10:10 AM, "Eric Ladner"  wrote:

> On Mon, Jun 20, 2016 at 8:08 PM Kevin Kenny 
> wrote:
>
>> 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
>>
>
> I think your perception of how multi-polygons work is correct.  Tagging
> should be at the multipolygon level.  E.g. if it's a  park split by a road
> maybe, both ways are members of the multipolygon, and the relation is
> tagged with "type=multipolygon; leisure=park" and both ways with
> "role=outer".  Maybe if there was something in the middle of the park, it'd
> have a ring, that was tagged with nothing, but has "role=inner" on the
> relation.  But, if it was a substation or lake or something, you could tag
> the inner ring with natural=water or power=substation.
>
> Granted, if you tagged the outer ways directly and left the relation with
> nothing but "type=multipolygon" it would still render correctly, but it's
> not the correct way to convey information.   Just because it looks pretty
> on the map doesn't mean it's right.
>
> JOSM flags this condition (tagging on outer ways instead of the MP itself)
> as a warning when you're uploading.  That's probably a good indication it's
> not a good practice.
>
> Think of it from a data maintenance point of view.  If you have some huge
> national park with 30 outer rings, do you want to manage 30 separate sets
> of information on each outer way, or one set of information on the
> multipolygon relation they all belong to anyway?
>
> Eric
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Proposed import cleanup: NYSDEClands

[Kevin Kenny]

Yes, indeed, I was referring to Russ Nelson.
On Jun 21, 2016 9:27 AM, "Russell Deffner" 
wrote:

> Just making sure, as I know people have confused Russ's before:
>
> "Russ has expressed concern ...
> Russ says that he did it ...
> Russ intended..."
>
> I believe you're talking about RussNelson (
> https://www.openstreetmap.org/user/RussNelson)
>
> From the other Russ (https://www.openstreetmap.org/user/russdeffner),
> =Russ
>
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Proposed import cleanup: NYSDEClands

[Eric Ladner]

On Mon, Jun 20, 2016 at 8:08 PM Kevin Kenny 
wrote:

> 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
>

I think your perception of how multi-polygons work is correct.  Tagging
should be at the multipolygon level.  E.g. if it's a  park split by a road
maybe, both ways are members of the multipolygon, and the relation is
tagged with "type=multipolygon; leisure=park" and both ways with
"role=outer".  Maybe if there was something in the middle of the park, it'd
have a ring, that was tagged with nothing, but has "role=inner" on the
relation.  But, if it was a substation or lake or something, you could tag
the inner ring with natural=water or power=substation.

Granted, if you tagged the outer ways directly and left the relation with
nothing but "type=multipolygon" it would still render correctly, but it's
not the correct way to convey information.   Just because it looks pretty
on the map doesn't mean it's right.

JOSM flags this condition (tagging on outer ways instead of the MP itself)
as a warning when you're uploading.  That's probably a good indication it's
not a good practice.

Think of it from a data maintenance point of view.  If you have some huge
national park with 30 outer rings, do you want to manage 30 separate sets
of information on each outer way, or one set of information on the
multipolygon relation they all belong to anyway?

Eric
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Proposed import cleanup: NYSDEClands

[Russell Deffner]

Just making sure, as I know people have confused Russ's before:

"Russ has expressed concern ...
Russ says that he did it ...
Russ intended..."

I believe you're talking about RussNelson 
(https://www.openstreetmap.org/user/RussNelson)

From the other Russ (https://www.openstreetmap.org/user/russdeffner), 
=Russ


___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Proposed import cleanup: NYSDEClands

[Kevin Kenny]

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  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 

Re: [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 

Re: [Talk-us] Proposed import cleanup: NYSDEClands

[Russ Nelson]

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?

-- 
--my blog is athttp://blog.russnelson.com
Crynwr supports open source software
521 Pleasant Valley Rd. | +1 315-600-8815
Potsdam, NY 13676-3213  | Sheepdog   

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Proposed import cleanup: NYSDEClands

[Greg Troxel]

Kevin Kenny  writes:

> landuse=conservation is formally deprecated.

This is the real bug.  There should be a set of landuse= tags that are
jointly exhaustive and mutually exclusive and this one is obviously
missing.  It describes exactly what you are trying to express.

> I fall back on leisure=nature_reserve unless someone screams.

That sounds fine to me; as long as humans are permitted, it isn't wrong.

However, I'd encourage you to put landuse=conservation if not other
documented landuse= tag plausibly fits.  If enough people use it, we can
reopen the formal discussion.


signature.asc
Description: PGP signature
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Proposed import cleanup: NYSDEClands

[Kevin Kenny]

On Tue, Jun 14, 2016 at 8:24 PM, Kevin Kenny
 wrote:
> Now that I'm done with the NYC DEP Watershed Recreation Areas import,
> I've got some bandwidth to spend on this cleanup again.

I've added a sketch of the plan on the existing import page,
http://wiki.openstreetmap.org/wiki/NYS_DEC_Lands

Once again, the reimport will be only semi-automated, with new
multipolygons and tags being proposed over narrow geographic areas but
then stitched into the map manually. In no case do I wish to overwrite
any work that a mapper has done that still appears valid. I will be
discarding a fair number of armchair edits apparently conducted in
response to automated warnings about data quality, which really did
little to improve the situation.

The reimport, in addition to sorting out the tagging, will clear up a
great many awkward misalignments in places like
http://www.openstreetmap.org/relation/6304830#map=13/42.2111/-74.3611
- where the Balsam Mountain and Pine Island Mountain units are
correctly aligned, while the Hunter-West Kill Mountain Wilderness and
Rusk Mountain Wild Forest are not. There are currently gaffes like
that all over the Catskills. The root cause appears to be that some
program in the pipeline - perhaps in the import, perhaps at the DEC -
got the wrong conversions among the New York East state coordinate
plane (NAD27) on which the state Department of Transportation
projected its quadrangle maps, the Zone 18N UTM (NAD83) coordinates
that NYSGIS now prefers, and the WGS84 coordinates (either plate
carrée or spherical Mercator) that are used in OSM. Since the
projection errors are not consistent from parcel to parcel, I suspect
that the error was at the state's end. It appears to be corrected in
recent versions of the data set. (It also makes most of the property
lines contiguous with lines on the Greene County tax rolls, which are
also available on line, giving the possibility of an independent
cross-check of the data.)

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Proposed import cleanup: NYSDEClands

[Kevin Kenny]

Now that I'm done with the NYC DEP Watershed Recreation Areas import,
I've got some bandwidth to spend on this cleanup again.

MECHANICAL EDITING

I've come to the conclusion that a 'mechanical edit' is appropriate
only in the sense that I will have a program providing me with
suggested geometry and tags. I'll need to go through all the edits
individually, because very few of the areas have actually survived
unchanged from the original import. Most of the changes appear to have
been from what Frederik Ramm referred to as 'drive-by mapping' -
armchair mappers silencing warnings from automated tools - but they
still need to be vetted individually. Moreover, there are various
weird tagging inconsistencies, such as conflicting tags between ways
in a relation, or between the ways and the relation itself.

PROTECTED_AREA

I'm going to maintain the protected_area tagging close to what I
specified below, except that 'Wild Forest,' 'Detached Parcel' and
'Unclassified' will all be upgraded to protect_class=1b. The only
significant differences between these and Wilderness is that slightly
more intensive use is allowed in Wild Forests. Nevertheless, it is
expected that those who enter the Wild Forests will have the skills
and equipment to operate on their own. About the only concessions that
they will find are hardened trail surfaces (NOT paved - but with more
erosion prevention than would be typical in Wilderness), the
occasional marked campsite (with no amenities other than brush
clearance and possibly a privy) and, in rare and exceptional cases,
permission to ride a mountain bike, horse, ATV or snowmobile.

LANDUSE (or leisure=nature_reserve, or landuse=forest, or
natural=wood, or landcover=trees, or what?)

I'm still in a quandary about how to tag the land use, because nothing
makes much sense.

leisure=nature_reserve at least renders, and is consistent with the
actual management - which ls largely, 'protect from encroachment, and
let Nature take her course.' The Wiki suggests that nature_reserve
ought to be used for relatively small areas and that
boundary=national_park might be more appropriate for these large ones.
Since the lands in question are located within the Adirondack and
Catskill parks (which exist as a public and private partnership), and
the outer boundaries of these immense parks are already tagged
'boundary=national_park', having something else designate the specific
land use seems appropriate, and nature_reserve seems as good as
anything, even if the High Peaks Wilderness is, at 832 square
kilometers, small in any sense other than relative to the Adirondack
Park's over 24,000 square kilometers. My inclination is to go with
this tag.

Most of the lands are at present tagged landuse=forest. This appears,
to me, to be incorrect. They are not managed for the production of
forest products. On the contrary, timber harvest is forbidden there in
perpetuity. The big advantage is that it renders with a pretty green
overlay, with trees.

natural=wood or landcover=trees are just plain wrong. There are woods,
fens and bogs, meadows, scrublands, and even some amount of
high-alpine tundra and bare rock. And I'm not about to tag what's
what. I get that information from the National Landcover Dataset when
I want to render a map.

landuse=conservation is formally deprecated.

I fall back on leisure=nature_reserve unless someone screams.

INFORMALITY

Since this is not a new import, and since all changes will be reviewed
(yes, I know it's a big job, but I can take it a few at a time in idle
moments and get it done in weeks to months), I don't plan to go
through an extensive formal review. I'll wikify what I'm doing and run
it by this list again before I start, but I consider this to be more
along the lines of manual editing to clean up a
less-than-ideally-executed import than of a massive mechanical edit to
conduct an import. I'l post again and allow a few days comment before
I start editing in earnest, again, just in case there are screams of
protest.


On Wed, May 25, 2016 at 2:04 PM, Kevin Kenny
 wrote:
> I've been continuing to investigate the NYS DEC Lands file, because,
> as Paul Norman identified, the original import is not up to current
> OSM standards. I'm not going to apologize for reimporting - a reimport
> will surely leave less of a mess than what is there!
>
> It's become clear to me that for most of these lands, and certainly
> for the entirety of the Forest Preserve, leisure=nature_reserve is a
> correct description for legacy renderers. landuse=forest is
> emphatically not correct. These lands are not used for timber
> production. natural=wood may or may not be correct, depending on
> landcover. boundary=national_park would also be semantically close for
> the Forest Preserve lands, except that the Forest Preserve is not
> administered at the national level.
>
> It would be desirable to include boundary=protected_area for these
> parcels, since all of them enjoy some 

Re: [Talk-us] Proposed import cleanup: NYSDEClands

[Kevin Kenny]

Oh, another question.  Some of the New York state land parcels have
rather complicated topology, and the previous import didn't get them
entirely right: duplicated nodes, crossing ways, nodes close to other
ways, and so on. Moreover, the upstream data are fairly arbitrarily
divided. An example is Burnt-Rossman Hills State Forest (which has
some recent changes from me that consisted of detaching the boundary
from crossing ways and deduplicating nodes).

From the upstream system, this arrives as six separate chunks,
corresponding to ways 32035570, 32026630, 32002834, 32047624, 32035988
and 39186229. Some of the fragmentation appears to be simply to avoid
having holes in any of the polygons (Why this is done is unclear: the
shapefile uses multipolygons to represent the parcels, so they can
support inner rings.)

My inclination would be to use PostGIS to coalesce all of these using
ST_Union, and then import the simplified multipolygon, which the tools
surely know how to do. I think that would be more in keeping with our
data model, and would keep us from rendering internal borders on the
parcels. It loses the LANDS_UID of the parcels, but I don't think
that's a particularly useful thing to keep around.

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.

With all this said, I'm better at PostGIS programming than at OSM
modeling, so I could be off in the weeds here. Does this idea make
sense?

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Proposed import cleanup: NYSDEClands

[Kevin Kenny]

I've been continuing to investigate the NYS DEC Lands file, because,
as Paul Norman identified, the original import is not up to current
OSM standards. I'm not going to apologize for reimporting - a reimport
will surely leave less of a mess than what is there!

It's become clear to me that for most of these lands, and certainly
for the entirety of the Forest Preserve, leisure=nature_reserve is a
correct description for legacy renderers. landuse=forest is
emphatically not correct. These lands are not used for timber
production. natural=wood may or may not be correct, depending on
landcover. boundary=national_park would also be semantically close for
the Forest Preserve lands, except that the Forest Preserve is not
administered at the national level.

It would be desirable to include boundary=protected_area for these
parcels, since all of them enjoy some sort of legal conservation
protection, and the Forest Preserve lands enjoy extremely strong
protection - stronger than the US National Parks. If we include this,
it's also desirable to include a protect_class. IUCN's web site
describes all these lands as class VI. The description of class 6,
nevertheless, does not fit the Forest Preserve. It might fit the
Adirondack and Catskill Parks in their entirety, where sustainable use
of natural resources is the goal. The State-owned lands within the
parks, however, are conserved to a much stricter standard.

The purpose of this writeup is to review New York State's land
classification scheme and attempt to assign appropriate protect_class
for the lands, in hopes of not creating yet another mess for someone
else to clean up down the road.

Feel free to scroll all the way down to the summary if you don't care
to follow the arguments for each decision. The summary gives
protect_class and protection_object for each classification of State
land.


1. THE FOREST PRESERVE
==

New York's Forest Preserve was created in 1894 by Article XIV of the
New York State Constitution. Its original wording still stands:

The lands of the State, now owned or hereafter acquired,
constituting the Forest Preserve as now fixed by law, shall be
forever kept as wild forest lands. They shall not be leased, sold
or exchanged, or be taken by any corporation, public or private,
nor shall the timber thereon be sold, removed or destroyed.
http://www.dec.ny.gov/lands/55849.html

It has been amended with many codicils, but in fact remains as strong
as ever. The amendments still must be placed on the ballot by a
supermajority of both houses of the state legislature in two sessions
with a general election intervening, and then presented as a popular
referendum. I can remember one election where there were six such
measures on the ballot, all widely supported by both development
advocates and conservationists. The consensus arose from the fact that
both sides got something: the Forest Preserve was expanded while the
lost land served an economic purpose. One typical example was that the
Sagamore Institute, a non-profit educational foundation, was allowed
to take title to ten acres containing historic buildings (placing them
under unitary ownership) on condition that the site would be conserved
as a historic site and remain open to the public - in return for two
hundred acres of wild forest land.

The Forest Preserve comprises the State-owned lands within the
Catskill and Adirondack Parks. The line fixed by the 1894 law defining
the parks is often called the Blue Line because it is traditionally
drawn in blue on maps of New York State. It also includes several
'detached parcels' that are outside the Blue Line but still located in
the counties that contain the Forest Preserve. These parcels enjoy the
same constitutional protection.

The State-owned lands in the Forest Preserve fall in several
administrative categories.
http://www.dec.ny.gov/lands/7811.html

A. WILDERNESS

The formal definition is found at the above URL. It is close to the
IUCN definition of Class Ib and the Federal definition of Wilderness
Area. It is "an area where the Earth and its community of life are
untrammeled by Man - where Man himself is a visitor who does not
remain." It cannot be class Ia, because public access is unrestricted.
Ordinarily, a parcel will be designated as Wilderness only
if it is at least ten thousand acres (4500 ha) in extent; preserving
smaller parcels in an unimpaired condition is usually impracticable.

Wilderness areas constitute 1.3 million acres (2100 square miles,
5400 km**2) of the lands in question.

I would suggest that Wilderness ought to be protect_class=1.

B. PRIMITIVE, PRIMITIVE BICYCLE CORRIDOR, CANOE

All of these are essentially the same as Wilderness. In the case of
Primitive Areas, there is usually some existing nonconformant use that
cannot be removed on a fixed timetable or are adjacent to private
lands that are sufficiently influential that wilderness designation
cannot be supported. 

Re: [Talk-us] Proposed import cleanup: NYSDEClands

[Martijn van Exel]

That makes sense. Keep it in mind for future cleanups where human mapper 
decisions are called for.

Martijn

> On May 19, 2016, at 10:26 AM, Paul Norman  wrote:
> 
> On 5/19/2016 10:24 AM, Martijn van Exel wrote:
>> There may be cases where a MapRoulette challenge may be in order?
> 
> I don't think it'd make a good MR challenge since all those changes are the 
> same on all the objects.


___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Proposed import cleanup: NYSDEClands

[Martijn van Exel]

Hey Paul, 

I applaud your continuing efforts to detect and try to remedy ill informed 
(even if perhaps well intended) imports!

There may be cases where a MapRoulette challenge may be in order? I am about to 
launch "New MapRoulette” or MapRoulette 2.0 which has native Overpass support 
to generate challenges with an overpass query. Let me know if you want to try 
it out. I am looking for a few interesting ‘Launching’ challenges :)

End of my hijacking this thread.. More on New MapRoulette soon!

Martijn

> On May 19, 2016, at 2:27 AM, Paul Norman  wrote:
> 
> I was debugging some MP issues and came across the NYSDEClands import[1], 
> done in 2010, consisting of natural areas. They have a number of unwanted 
> tags[2], and a couple of other problems with their tags
> 
> Because there's a relatively small number of them, I think a mechanical edit 
> is the best cleanup option. I'm proposing the following
> 
> - Removing NYDEC_Land:* tags
> - Removing area=yes where there are other area tags
> - Changing url=* to website=* where website does not already exist
> - Leaving source=* intact
> - Removing name=Unclassified
> 
> [1]: https://www.openstreetmap.org/user/NYSDEClands
> [2]: e.g. https://www.openstreetmap.org/way/32002190
> 
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us


___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[Talk-us] Proposed import cleanup: NYSDEClands

[Paul Norman]

I was debugging some MP issues and came across the NYSDEClands 
import[1], done in 2010, consisting of natural areas. They have a number 
of unwanted tags[2], and a couple of other problems with their tags


Because there's a relatively small number of them, I think a mechanical 
edit is the best cleanup option. I'm proposing the following


- Removing NYDEC_Land:* tags
- Removing area=yes where there are other area tags
- Changing url=* to website=* where website does not already exist
- Leaving source=* intact
- Removing name=Unclassified

[1]: https://www.openstreetmap.org/user/NYSDEClands
[2]: e.g. https://www.openstreetmap.org/way/32002190

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us