Re: [Talk-us] Michigan Forest Land
(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
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
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
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
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
Re: [Talk-us] Michigan Forest Land
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
