[Talk-us] Michigan Forest Land

[David Martin]

Hi,

I'm new to editing OSM, having been a heavy user of OSMAnd for Android for 
several years.  I primarily use the maps for snowmobiling here in Northern 
Michigan, and building my own database of gpx tracks.

The Michigan maps are lacking the information for state forest land.  I have 
noted that the Upper Peninsula does have some state and national forest areas, 
but there is much missing here in the Lower Peninsula.

I have found the data on the State of Michigan website, and have successfully 
downloaded the shapefile for all state forest land.

I would like to proceed with adding this data to OSM, with the help of 
experienced editors.

This is public data, available at 
http://gis-michigan.opendata.arcgis.com/datasets/dfe0bcec31184b57b9f0d96bc02d6548_1

This is high-value data for all OSM users in Michigan, to understand when they 
are public land and help prevent trespassing onto private land.  I often have 
to switch over to Google Maps to see if I am on state land.

Please advise as to how I may proceed.

Thanks,
David Martin

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

Re: [Talk-us] Michigan Forest Land

[Clifford Snow]

David,
Thanks for asking on the talk-us mailing list before importing the data.
Guidelines for importing data into OSM are available at
https://wiki.openstreetmap.org/wiki/Import/Guidelines. Please read the
guidelines before proceeding. Basically the guideline want to insure that
the data is licensed suitably for import into OSM, that the data is
suitable for OSM, how you plan to convert between the states tagging to OSM
tagging, conflating the data with what's already in OSM, and what account
you plan to use to upload the data. A quick look at the states site it
would appear that there is no license issue and the data seems suitable for
import. Especially the state parks and wildlife preserves.

The best editor I've found for this type of import is JOSM [1]. It sounds
like you may not be familiar with JOSM. You can get help at Learnosm.org
[2].

I would recommend getting started by doing some edits in JOSM before
tackling this project.

[1]. josm.openstreetmap.de
[2]. https://learnosm.org/en/josm/

Best,
Clifford


On Thu, Mar 7, 2019 at 8:57 AM David Martin  wrote:

> Hi,
>
> I'm new to editing OSM, having been a heavy user of OSMAnd for Android for
> several years.  I primarily use the maps for snowmobiling here in Northern
> Michigan, and building my own database of gpx tracks.
>
> The Michigan maps are lacking the information for state forest land.  I
> have noted that the Upper Peninsula does have some state and national
> forest areas, but there is much missing here in the Lower Peninsula.
>
> I have found the data on the State of Michigan website, and have
> successfully downloaded the shapefile for all state forest land.
>
> I would like to proceed with adding this data to OSM, with the help of
> experienced editors.
>
> This is public data, available at
> http://gis-michigan.opendata.arcgis.com/datasets/dfe0bcec31184b57b9f0d96bc02d6548_1
>
> This is high-value data for all OSM users in Michigan, to understand when
> they are public land and help prevent trespassing onto private land.  I
> often have to switch over to Google Maps to see if I am on state land.
>
> Please advise as to how I may proceed.
>
> Thanks,
> David Martin
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>


-- 
@osm_seattle
osm_seattle.snowandsnow.us
OpenStreetMap: Maps with a human touch
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Michigan Forest Land

[Martijn van Exel]

Hi David, 

We’d have to look into how public vs private land in OSM is mapped. I am not 
sure if there is an established convention. Others may know more.. 

The issue with official data in OSM is that someone needs to keep it updated. 
If you rely on public land boundaries in OSM you are relying on someone keeping 
this data up to date in OSM as well. With a data layer that could get you in 
actual trouble if it’s outdated or otherwise inaccurate, that is a real issue.

Engaging in quite a bit of  backcountry fun myself I understand and appreciate 
your use case. I tend to rely on official maps for public lands and use an 
outdoor specific mapping app to get my intel in the field. I recommend Gaia GPS 
which is not free, but in my and my outdoor loving friends’ opinions well worth 
the money.

Best
Martijn  

> On Mar 7, 2019, at 9:55 AM, David Martin  wrote:
> 
> Hi,
> 
> I'm new to editing OSM, having been a heavy user of OSMAnd for Android for 
> several years.  I primarily use the maps for snowmobiling here in Northern 
> Michigan, and building my own database of gpx tracks.
> 
> The Michigan maps are lacking the information for state forest land.  I have 
> noted that the Upper Peninsula does have some state and national forest 
> areas, but there is much missing here in the Lower Peninsula.
> 
> I have found the data on the State of Michigan website, and have successfully 
> downloaded the shapefile for all state forest land.  
> 
> I would like to proceed with adding this data to OSM, with the help of 
> experienced editors.
> 
> This is public data, available at 
> http://gis-michigan.opendata.arcgis.com/datasets/dfe0bcec31184b57b9f0d96bc02d6548_1
>  
> 
> 
> This is high-value data for all OSM users in Michigan, to understand when 
> they are public land and help prevent trespassing onto private land.  I often 
> have to switch over to Google Maps to see if I am on state land.
> 
> Please advise as to how I may proceed.
> 
> Thanks,
> David Martin
> 
> ___
> 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

Re: [Talk-us] Michigan Forest Land

[Kevin Kenny]

On Thu, Mar 7, 2019 at 11:58 AM David Martin  wrote:
> I'm new to editing OSM, having been a heavy user of OSMAnd for Android for 
> several years.  I primarily use the maps for snowmobiling here in Northern 
> Michigan, and building my own database of gpx tracks.
>
> The Michigan maps are lacking the information for state forest land.  I have 
> noted that the Upper Peninsula does have some state and national forest 
> areas, but there is much missing here in the Lower Peninsula.
>
> I have found the data on the State of Michigan website, and have successfully 
> downloaded the shapefile for all state forest land.
>
> I would like to proceed with adding this data to OSM, with the help of 
> experienced editors.
>
> This is public data, available at 
> http://gis-michigan.opendata.arcgis.com/datasets/dfe0bcec31184b57b9f0d96bc02d6548_1
>
> This is high-value data for all OSM users in Michigan, to understand when 
> they are public land and help prevent trespassing onto private land.  I often 
> have to switch over to Google Maps to see if I am on state land.
>
> Please advise as to how I may proceed.

A bit of background: I am the original importer of the 'New York City
Watershed Recreation Lands' data set, and I re-imported and continue
to update the "New York State Department of Environmental Conservation
Lands and Campgrounds" data set, so I appear to be the primary
custodian of OSM's representation of about 25000 km² of public
recreational land. I certainly think that representation of State
Forests on OSM is a worthy goal.

With that said, an iimport is a really tricky thing to get right. If
you're imagining a process whereby you could take a shapefile from
Michigan's GIS department and pour it into OSM, it's by no means that
simple!

A few questions and comments, to get us started --

How familiar are you with OSM mapping? In order for an import on the
scale that you're contemplating to be successful, the importers have
to be extremely fluent in the editor of choice - most importers use
JOSM, and many use external tools in addition. In particular, if
you're not familiar with mapping multipolygons, or with 'conflation' -
the process of merging data with what's already there - an import is
likely NOT the place to learn! I'm surely willing to advise and
assist, but I really want to be advising before any major moves,
rather than trying to clean up the massive mess that results from a
botched import.

Anticipating some of the objections: OSM ordinarily does not map land
ownership, but only land use, land cover, land access, land
protection. What we're going to have here is 'land open to the public
- managed by the State of Michigan Department of Xxx -  a protected
area (IUCN class #nnn) - etc." Those are the salient facts, rather
than the fact that the State owns it. Since we routinely map parks,
forests, nature reserves, an objection on the grounds that we are
dealing with land ownership data can be rebutted on these grounds.

How observable in the field is the presence of a state forest?  In New
York, where state land abuts a road, or where a trail enters or
leaves, there is ordinarily signage, comparable to a private
landowner's posters, that looks like
https://upload.wikimedia.org/wikipedia/commons/3/31/NYS_Forest_Preserve_sign.jpg.
In addition, where the road is entering or leaving the forest, turning
off to a parking area, or othewise in need of a 'welcome' sign, there
will be a larger sign like
https://andyarthur.org/data/photo_021252.jpg.  Moreover, in the back
country, while the posters may be absent, the survey line for the
border of the parcel will ordinarily be blazed, either with paint
blazes, or for many of the older lines, axe blazes.  Axe blazes are
visible for decades, even when a tree is nearly healed -
https://howtowilderness.com/wordpress/wp-content/uploads/2011/10/blaze.jpg
is an example. In general, while it might be possible to stray outside
a forest parcel unwittingly if the adjacent landowner has neglected to
post, someone who knows the approximate location of a boundary line
and is looking for it will find it. If we have "there is signage
identifying the forest" and "there is at least this minimal level of
field visibility of the boundary", then in my opinion at least, the
import clears the bar of 'verifiability.'

Now comes the issue of compliance with the import guidelines.
https://wiki.openstreetmap.org/wiki/Import/Guidelines . You're already
well into Step 2, and doing OK so far. I'd recommend that the next
step is to draft an import plan. (This is actually called out as item
2 under step 4, but you'll find that if you approach the 'imports'
mailing list without a plan, you'll not get a favourable response.)
There's an outline for the plan on
https://wiki.openstreetmap.org/wiki/Import/Plan_Outline.  For similar
imports that I did, you can see the plans at
https://wiki.openstreetmap.org/wiki/Import:_NYCDEP_Watershed_Recreation_Areas
- this one is a full plan - and
https://wiki

Re: [Talk-us] Michigan Forest Land

[Kevin Kenny]

On Sat, Mar 9, 2019 at 1:18 PM Kevin Kenny  wrote:
> > The Michigan maps are lacking the information for state forest land.  I 
> > have noted that the Upper Peninsula does have some state and national 
> > forest areas, but there is much missing here in the Lower Peninsula.
> >
> > I have found the data on the State of Michigan website, and have 
> > successfully downloaded the shapefile for all state forest land.
> >
> > I would like to proceed with adding this data to OSM, with the help of 
> > experienced editors.

I took a look at the data set, and we'd need to do some research
before importing on what the various "ManagementType" might correspond
to in terms of boundary=protected_area protect_class=* tagging.  In
addition, the data set has a large number of parcels where adjacent
parcels are identical except for FC_Key (intended to be a unique ID
for the parcel?), County and YOE.  (I don't know what YOE means - it
appears to be "Year Of" something - and there are dates in both the
future and the past, so I don't think it's "year of expiration").

In some cases, the dividing lines appear to be township and range
lines, but in many places, they're too irregular to be simple PLSS
lines and aren't meander lines either, so I suspect they simply
represent former lot boundaries.  Most parcels appear to be about
three sections in size, and given that they're consistently elongated
in an E-W direction, may simply be consecutively numbered sections.
(If you don't know what township, range and section mean in this
context, read https://en.wikipedia.org/wiki/Public_Land_Survey_System).

Given the large number of parcels that are named alike, we probably
need to look at coalescing adjacent ones. I suspect the division is
just to keep accounting straight for parcels that were acquired at
different times or from different former owners, and not something we
ought to be replicating in OSM.

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

Re: [Talk-us] Michigan Forest Land

[Marcus W. Davenport]

Hello!
I'm a decently experienced mapper from the Lansing and Hillsdale, MI areas
and noticed the same issues with state owned land in OSM.  I've been using
State of Michigan data to draw and maintain the two State Game Area's that
I hike regularly: the Portland State Game Area (on the Grand River just
south of Portland) and the Lost Nations State Game Area (just south of
Pittsford; sometimes known as "Pittsford State Game Area").
One issue I've found with the State Forest Compartments shapefile that was
originally linked is that JOSM does not seem to import this file with the
metadata required to make any addition without local knowledge. Other State
of Michigan shapefiles will open names and superfluous data as keys and
values, but his shapefile appears to be outlines only.
Also, it's my understanding that SGA's and forests would be either
"protect_class" = 4 or 5 (depending on whether the enclosed species or
landscape are of greater importance).  That is solely my interpretation
based on reading
https://wiki.openstreetmap.org/wiki/Tag:boundary%3Dprotected_area.

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

Re: [Talk-us] Michigan Forest Land

[Kevin Kenny]

On Mon, Mar 11, 2019 at 11:31 AM Marcus W. Davenport
 wrote:
> I'm a decently experienced mapper from the Lansing and Hillsdale, MI areas 
> and noticed the same issues with state owned land in OSM.  I've been using 
> State of Michigan data to draw and maintain the two State Game Area's that I 
> hike regularly: the Portland State Game Area (on the Grand River just south 
> of Portland) and the Lost Nations State Game Area (just south of Pittsford; 
> sometimes known as "Pittsford State Game Area").
> One issue I've found with the State Forest Compartments shapefile that was 
> originally linked is that JOSM does not seem to import this file with the 
> metadata required to make any addition without local knowledge. Other State 
> of Michigan shapefiles will open names and superfluous data as keys and 
> values, but his shapefile appears to be outlines only.
> Also, it's my understanding that SGA's and forests would be either 
> "protect_class" = 4 or 5 (depending on whether the enclosed species or 
> landscape are of greater importance).  That is solely my interpretation based 
> on reading https://wiki.openstreetmap.org/wiki/Tag:boundary%3Dprotected_area.

I downloaded the data set and queried it with GDAL, and what I see is:

INFO: Open of 
`Michigan_State_Forest_Compartments/Michigan_State_Forest_Compartments.shp'
  using driver `ESRI Shapefile' successful.

Layer name: Michigan_State_Forest_Compartments
Geometry: Polygon
Feature Count: 2462
Extent: (-90.057938, 41.732556) - (-82.486685, 47.475682)
Layer SRS WKT:
GEOGCS["GCS_WGS_1984",
DATUM["WGS_1984",
SPHEROID["WGS_84",6378137,298.257223563]],
PRIMEM["Greenwich",0],
UNIT["Degree",0.017453292519943295],
AUTHORITY["EPSG","4326"]]
OBJECTID: Integer64 (10.0)
OBJECTID_1: Integer64 (10.0)
MANAGMENTT: String (80.0)
Management: String (80.0)
UNIT_NAME: String (80.0)
FC_key: String (80.0)
COUNTY: String (80.0)
YOE: String (80.0)
Acres: Real (24.15)
ROD_URL: String (113.0)
DDLat: Real (24.15)
DDLon: Real (24.15)
Shape__Are: Real (24.15)
Shape__Len: Real (24.15)

which looks as if all the columns that are listed in the metadata are
there. I also successfully pushed it into my PostGIS instance:

$ ogr2ogr -progress -overwrite -t_srs EPSG:3857 -f PostgreSQL
PG:dbname=gis 
Michigan_State_Forest_Compartments/Michigan_State_Forest_Compartments.shp
-nln Michigan_State_Forest_Compartments -nlt MULTIPOLYGON -lco
'precision=NO'
0...10...20...30...40...50...60...70...80...90...100 - done.

Would the information in 'MANAGMENTT' (spelt thus!) be sufficient to
assign the protect_class? The enumerated values are:

gis=# select distinct managmentt from michigan_state_forest_compartments \g
  managmentt
---
 State Parks
 State Forests
 Wildlife
(3 rows)

That seems to distinguish State Forests from Wildlife Management Areas
(or whatever the correct term is in Michigan).

The name of the facility appears to be in the MANAGEMENT column.  Most
of the 'Wildlife' compartments and all of the 'State Parks'
compartments have this field either null, blank, or 'Unspecified'.
Virtually all the values of 'Management' have multiple compartments -
'AuSable Outwash' has no fewer than 88. We'd want to work on
coalescing these, and I *think* they should merge cleanly if we do it
in PostGIS.

I suspect that the following columns could be safely ignored for State Forests:
UNIT_NAME - Appears to be the name of the office that manages a
parcel. Some forests appear to be split among multiple units. For
State Parks and Wildlife Areas, this is the name of the facility.
FC_Key - Some sort of record ID, most likely better ignored.
County - We already have administrative boundaries in OSM, no need to
replicate this.
YOE - 'Year of Entry'. This can be either past or future, and I
suspect is a historic or projected entry by a forestry crew to study
the plot and plan any timber harvest. This is specific to individual
compartments and would work against coalescing them, and I think it's
information that OSM wouldn't care about.
Acres, DDLat, DDLon, Shape__ARE, Shape__LEN - Redundant, easily
computed from geometry.
ROD_URL - Appears to be a link to a report on the status of the
parcel. Many of the links are dead. I suppose we could include this,
but I'd sure like to know what ROD stands for!

A quick attempt to query for the state forests gives me:


gis=# select managmentt, management, count(1) from
michigan_state_forest_compartments group by managmentt, management
order by management asc \g
  managmentt   |management| count
---+--+---
 State Forests | 8 Mile Corner|12
 State Forests | Alpena Lake Plain|44
 State Forests | Amasa Plains | 6
 State Forests | AuSable Outwash  |88
 State Forests | Avery Hills  |25
 State Forests | Baraga Plains| 5
 State Forests | Ba

Re: [Talk-us] Michigan Forest Land

[Marcus W. Davenport]

Thank you for the information, Kevin!  It does look like all the important
information is there to continue writing up an import proposal.

Looks like ROD is "Record of Decision".  I was able to open that database
table in LibreOffice and a google search for the first filename in that
field shows the 2010 YOE decisions:
http://www.michigandnr.com/publications/pdfs/ForestsLandWater/Cmpt_Reviews/Gladwin/2010/gladwinROD.pdf.
While interesting to read, I don't think that would be relevant to end
users of OSM.


On Mon, Mar 11, 2019 at 10:28 PM Kevin Kenny 
wrote:

> On Mon, Mar 11, 2019 at 11:31 AM Marcus W. Davenport
>  wrote:
> > I'm a decently experienced mapper from the Lansing and Hillsdale, MI
> areas and noticed the same issues with state owned land in OSM.  I've been
> using State of Michigan data to draw and maintain the two State Game Area's
> that I hike regularly: the Portland State Game Area (on the Grand River
> just south of Portland) and the Lost Nations State Game Area (just south of
> Pittsford; sometimes known as "Pittsford State Game Area").
> > One issue I've found with the State Forest Compartments shapefile that
> was originally linked is that JOSM does not seem to import this file with
> the metadata required to make any addition without local knowledge. Other
> State of Michigan shapefiles will open names and superfluous data as keys
> and values, but his shapefile appears to be outlines only.
> > Also, it's my understanding that SGA's and forests would be either
> "protect_class" = 4 or 5 (depending on whether the enclosed species or
> landscape are of greater importance).  That is solely my interpretation
> based on reading
> https://wiki.openstreetmap.org/wiki/Tag:boundary%3Dprotected_area.
>
> I downloaded the data set and queried it with GDAL, and what I see is:
>
> INFO: Open of
> `Michigan_State_Forest_Compartments/Michigan_State_Forest_Compartments.shp'
>   using driver `ESRI Shapefile' successful.
>
> Layer name: Michigan_State_Forest_Compartments
> Geometry: Polygon
> Feature Count: 2462
> Extent: (-90.057938, 41.732556) - (-82.486685, 47.475682)
> Layer SRS WKT:
> GEOGCS["GCS_WGS_1984",
> DATUM["WGS_1984",
> SPHEROID["WGS_84",6378137,298.257223563]],
> PRIMEM["Greenwich",0],
> UNIT["Degree",0.017453292519943295],
> AUTHORITY["EPSG","4326"]]
> OBJECTID: Integer64 (10.0)
> OBJECTID_1: Integer64 (10.0)
> MANAGMENTT: String (80.0)
> Management: String (80.0)
> UNIT_NAME: String (80.0)
> FC_key: String (80.0)
> COUNTY: String (80.0)
> YOE: String (80.0)
> Acres: Real (24.15)
> ROD_URL: String (113.0)
> DDLat: Real (24.15)
> DDLon: Real (24.15)
> Shape__Are: Real (24.15)
> Shape__Len: Real (24.15)
>
> which looks as if all the columns that are listed in the metadata are
> there. I also successfully pushed it into my PostGIS instance:
>
> $ ogr2ogr -progress -overwrite -t_srs EPSG:3857 -f PostgreSQL
> PG:dbname=gis
> Michigan_State_Forest_Compartments/Michigan_State_Forest_Compartments.shp
> -nln Michigan_State_Forest_Compartments -nlt MULTIPOLYGON -lco
> 'precision=NO'
> 0...10...20...30...40...50...60...70...80...90...100 - done.
>
> Would the information in 'MANAGMENTT' (spelt thus!) be sufficient to
> assign the protect_class? The enumerated values are:
>
> gis=# select distinct managmentt from michigan_state_forest_compartments \g
>   managmentt
> ---
>  State Parks
>  State Forests
>  Wildlife
> (3 rows)
>
> That seems to distinguish State Forests from Wildlife Management Areas
> (or whatever the correct term is in Michigan).
>
> The name of the facility appears to be in the MANAGEMENT column.  Most
> of the 'Wildlife' compartments and all of the 'State Parks'
> compartments have this field either null, blank, or 'Unspecified'.
> Virtually all the values of 'Management' have multiple compartments -
> 'AuSable Outwash' has no fewer than 88. We'd want to work on
> coalescing these, and I *think* they should merge cleanly if we do it
> in PostGIS.
>
> I suspect that the following columns could be safely ignored for State
> Forests:
> UNIT_NAME - Appears to be the name of the office that manages a
> parcel. Some forests appear to be split among multiple units. For
> State Parks and Wildlife Areas, this is the name of the facility.
> FC_Key - Some sort of record ID, most likely better ignored.
> County - We already have administrative boundaries in OSM, no need to
> replicate this.
> YOE - 'Year of Entry'. This can be either past or future, and I
> suspect is a historic or projected entry by a forestry crew to study
> the plot and plan any timber harvest. This is specific to individual
> compartments and would work against coalescing them, and I think it's
> information that OSM wouldn't care about.
> Acres, DDLat, DDLon, Shape__ARE, Shape__LEN - Redundant, easily
> computed from geometry.
> ROD_URL - Appears to be a link to a report on the status of the
> parcel. Many of the links are dead. I suppose we could include this,
> but I'd sure li

Re: [Talk-us] Michigan Forest Land

[Kevin Kenny]

Would it be useful for me to try coalescing the areas, to see what
we're up against with respect to inconsistent borders? Some of these
state databases come in with almost perfect topological consistency,
others are messes where you get self-intersections, slivers, gaps, and
Lord-knows-what-all-else all over the place when you try to merge
parcels.

I can also try to expand the coverage area of
https://kbk.is-a-geek.net/catskills/test4.html west far enough to
include the whole of the state, which would give me a basemap to
overlay the borders on. That probably can't happen for at least couple
of weeks because life is seriously getting in the way of mapping.


On Wed, Mar 13, 2019 at 8:56 AM Marcus W. Davenport
 wrote:
>
> Thank you for the information, Kevin!  It does look like all the important 
> information is there to continue writing up an import proposal.
>
> Looks like ROD is "Record of Decision".  I was able to open that database 
> table in LibreOffice and a google search for the first filename in that field 
> shows the 2010 YOE decisions:  
> http://www.michigandnr.com/publications/pdfs/ForestsLandWater/Cmpt_Reviews/Gladwin/2010/gladwinROD.pdf.
>   While interesting to read, I don't think that would be relevant to end 
> users of OSM.
>
>
> On Mon, Mar 11, 2019 at 10:28 PM Kevin Kenny  wrote:
>>
>> On Mon, Mar 11, 2019 at 11:31 AM Marcus W. Davenport
>>  wrote:
>> > I'm a decently experienced mapper from the Lansing and Hillsdale, MI areas 
>> > and noticed the same issues with state owned land in OSM.  I've been using 
>> > State of Michigan data to draw and maintain the two State Game Area's that 
>> > I hike regularly: the Portland State Game Area (on the Grand River just 
>> > south of Portland) and the Lost Nations State Game Area (just south of 
>> > Pittsford; sometimes known as "Pittsford State Game Area").
>> > One issue I've found with the State Forest Compartments shapefile that was 
>> > originally linked is that JOSM does not seem to import this file with the 
>> > metadata required to make any addition without local knowledge. Other 
>> > State of Michigan shapefiles will open names and superfluous data as keys 
>> > and values, but his shapefile appears to be outlines only.
>> > Also, it's my understanding that SGA's and forests would be either 
>> > "protect_class" = 4 or 5 (depending on whether the enclosed species or 
>> > landscape are of greater importance).  That is solely my interpretation 
>> > based on reading 
>> > https://wiki.openstreetmap.org/wiki/Tag:boundary%3Dprotected_area.
>>
>> I downloaded the data set and queried it with GDAL, and what I see is:
>>
>> INFO: Open of 
>> `Michigan_State_Forest_Compartments/Michigan_State_Forest_Compartments.shp'
>>   using driver `ESRI Shapefile' successful.
>>
>> Layer name: Michigan_State_Forest_Compartments
>> Geometry: Polygon
>> Feature Count: 2462
>> Extent: (-90.057938, 41.732556) - (-82.486685, 47.475682)
>> Layer SRS WKT:
>> GEOGCS["GCS_WGS_1984",
>> DATUM["WGS_1984",
>> SPHEROID["WGS_84",6378137,298.257223563]],
>> PRIMEM["Greenwich",0],
>> UNIT["Degree",0.017453292519943295],
>> AUTHORITY["EPSG","4326"]]
>> OBJECTID: Integer64 (10.0)
>> OBJECTID_1: Integer64 (10.0)
>> MANAGMENTT: String (80.0)
>> Management: String (80.0)
>> UNIT_NAME: String (80.0)
>> FC_key: String (80.0)
>> COUNTY: String (80.0)
>> YOE: String (80.0)
>> Acres: Real (24.15)
>> ROD_URL: String (113.0)
>> DDLat: Real (24.15)
>> DDLon: Real (24.15)
>> Shape__Are: Real (24.15)
>> Shape__Len: Real (24.15)
>>
>> which looks as if all the columns that are listed in the metadata are
>> there. I also successfully pushed it into my PostGIS instance:
>>
>> $ ogr2ogr -progress -overwrite -t_srs EPSG:3857 -f PostgreSQL
>> PG:dbname=gis 
>> Michigan_State_Forest_Compartments/Michigan_State_Forest_Compartments.shp
>> -nln Michigan_State_Forest_Compartments -nlt MULTIPOLYGON -lco
>> 'precision=NO'
>> 0...10...20...30...40...50...60...70...80...90...100 - done.
>>
>> Would the information in 'MANAGMENTT' (spelt thus!) be sufficient to
>> assign the protect_class? The enumerated values are:
>>
>> gis=# select distinct managmentt from michigan_state_forest_compartments \g
>>   managmentt
>> ---
>>  State Parks
>>  State Forests
>>  Wildlife
>> (3 rows)
>>
>> That seems to distinguish State Forests from Wildlife Management Areas
>> (or whatever the correct term is in Michigan).
>>
>> The name of the facility appears to be in the MANAGEMENT column.  Most
>> of the 'Wildlife' compartments and all of the 'State Parks'
>> compartments have this field either null, blank, or 'Unspecified'.
>> Virtually all the values of 'Management' have multiple compartments -
>> 'AuSable Outwash' has no fewer than 88. We'd want to work on
>> coalescing these, and I *think* they should merge cleanly if we do it
>> in PostGIS.
>>
>> I suspect that the following columns could be safely ignored for State 
>> Forests:
>> UNIT_NAME - Appears to be the name

Re: [Talk-us] Michigan Forest Land

[Max Erickson]

The compartments likely aren't the right data for a general purpose
map; I'm not entirely sure, but they seem to be the basic management
unit for state forest land, so when they consider a cut or whatever
they consider it for that area. For OSM, the right things is probably
to have individual objects for each state forest, game area, park,
etc.

Complicating things, the state seems to have moved away from saying
much about the top level state forests. But I think they are probably
still the right thing for a general purpose map.


Max

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

Re: [Talk-us] Michigan Forest Land

[Kevin Kenny]

On Wed, Mar 13, 2019, 10:17 Max Erickson  wrote:

> The compartments likely aren't the right data for a general purpose
> map; I'm not entirely sure, but they seem to be the basic management
> unit for state forest land, so when they consider a cut or whatever
> they consider it for that area. For OSM, the right things is probably
> to have individual objects for each state forest, game area, park,
> etc.
>
> Complicating things, the state seems to have moved away from saying
> much about the top level state forests. But I think they are probably
> still the right thing for a general purpose map.
>

Right. That's why I was talking about coalescing compartments that have the
same management type and name. The table in my earlier message shows the
number of compartments to be combined for each facility.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Michigan Forest Land

[Max Erickson]

On Wed, Mar 13, 2019 at 11:20 AM Kevin Kenny  wrote:

>>
>> Complicating things, the state seems to have moved away from saying
>> much about the top level state forests. But I think they are probably
>> still the right thing for a general purpose map.
>
>
> Right. That's why I was talking about coalescing compartments that have the 
> same management type and name. The table in my earlier message shows the 
> number of compartments to be combined for each facility.

The management units in the data are subunits of the state forests
still. For instance, "Gwinn Forest Management Unit" is/was part of the
Escanaba River State Forest.

The question is which data is better to present to the average end
user. I guess if the state isn't using the state forest names anymore
it makes sense to have the management units in OSM. But then because
people know the older names, does it make sense to also have the state
forests?


Max

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

Re: [Talk-us] Michigan Forest Land

[Kevin Kenny]

(Is there a Michigan-specific forum that we could take this to? We're
probably boring the daylights out of most of talk-us.)

On Wed, Mar 13, 2019 at 9:16 PM Max Erickson  wrote:

> The management units in the data are subunits of the state forests
> still. For instance, "Gwinn Forest Management Unit" is/was part of the
> Escanaba River State Forest.
>
> The question is which data is better to present to the average end
> user. I guess if the state isn't using the state forest names anymore
> it makes sense to have the management units in OSM. But then because
> people know the older names, does it make sense to also have the state
> forests?

What I see in the data doesn't match your description.  'Unit_name'
appears to be one of sixteen large rectangular regions, and then
'management_name' is a fairly small region.

I've sliced the data both ways, and put the results in
https://kbk.is-a-geek.net/tmp/mi_sf.zip, so that you can open the data
in JOSM and see what's up with it. DO NOT IMPORT - the translation is
very rough and doesn't even pass JOSM's validation - I'm simply
sharing it so that locals can see whether either division makes any
sense in the local context.

Simply coalescing the data led to topological problems, as I
anticipated. I did some jiggery-pokery with ST_Buffer in PostGIS to
force the topology to be consistent. The result is that every parcel's
boundary is set back 2.5 metres from where it was in the original data
set. This is surely no big deal as far as the map is concerned, but
cuts way back on the validation errors.

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

Re: [Talk-us] Michigan Forest Land

[Max Erickson]

The US forum is pretty low traffic (a couple posts this year), so I
guess a topic wouldn't bother anyone:

https://forum.openstreetmap.org/viewforum.php?id=20

There's also a michigan channel on the osm us slack.

( https://slack.openstreetmap.us/ )

On Wed, Mar 13, 2019 at 10:58 PM Kevin Kenny  wrote:
>
> (Is there a Michigan-specific forum that we could take this to? We're
> probably boring the daylights out of most of talk-us.)
>
> On Wed, Mar 13, 2019 at 9:16 PM Max Erickson  wrote:
>
> > The management units in the data are subunits of the state forests
> > still. For instance, "Gwinn Forest Management Unit" is/was part of the
> > Escanaba River State Forest.
> >
> > The question is which data is better to present to the average end
> > user. I guess if the state isn't using the state forest names anymore
> > it makes sense to have the management units in OSM. But then because
> > people know the older names, does it make sense to also have the state
> > forests?
>
> What I see in the data doesn't match your description.  'Unit_name'
> appears to be one of sixteen large rectangular regions, and then
> 'management_name' is a fairly small region.
>
> I've sliced the data both ways, and put the results in
> https://kbk.is-a-geek.net/tmp/mi_sf.zip, so that you can open the data
> in JOSM and see what's up with it. DO NOT IMPORT - the translation is
> very rough and doesn't even pass JOSM's validation - I'm simply
> sharing it so that locals can see whether either division makes any
> sense in the local context.
>
> Simply coalescing the data led to topological problems, as I
> anticipated. I did some jiggery-pokery with ST_Buffer in PostGIS to
> force the topology to be consistent. The result is that every parcel's
> boundary is set back 2.5 metres from where it was in the original data
> set. This is surely no big deal as far as the map is concerned, but
> cuts way back on the validation errors.

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

Re: [Talk-us] Michigan Forest Land

[Marcus W. Davenport]

For those interested, I've started a post on the OSM US forum:
https://forum.openstreetmap.org/viewtopic.php?id=65666
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Michigan Forest Land

[Kevin Kenny]

I did another round of extracts to cover state parks and state
wildlife areas.  You can see the geometry of everything now in the
.osm files inside https://kbk.is-a-geek.net/tmp/mi_sf.zip.

The tagging is still pretty sketchy - you guys need to discuss what
tagging can be created automatically (as with
https://wiki.openstreetmap.org/wiki/Import:_NYCDEP_Watershed_Recreation_Areas)
- I think that at least 'boundary=protected_area' 'protect_class' and
'protection_title' can be worked in, and there may be others.  There
are a few validation errors in the data that are probably best patched
manually. Then there needs to be a plan for how you plan actually to
do the work of conflation, produce coherent change sets, and offer a
limited-scale sample for review. (And once there *is* an import plan,
then we need to go over to 'imports' to discuss it more broadly)

The next immediate step, I think, is for the locals to review the
extracts that we have and provide feedback. That's certainly a part
that I can't do. I'm willing to be on this project as a programmer,
but can't be a local mapper - I'm not familiar enough with Michigan.

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