Talk:Parcel

From OpenStreetMap Wiki
Jump to navigation Jump to search

Summary of Mailing List Correspondence

Thread: Parcel Data in OSM?

The original OSM-talk thread started by Christopher Schmidt on Feb 17, 2009 can be viewed here. (nabble) In short, Chris proposed the possibility of uploading parcel boundaries and attributes from [MassGIS]. The thread contains enthusiasm for the idea along with concerns about the quantity of data and how updates would be managed. A question about which zoom levels (if any) would be appropriate for rendering parcel boundaries. From the [MassGIS] page, it appears that building outlines and open space ended up making it into the map, but there is no indication that parcel boundaries made it.

Thread: Parcel data

The original OSM-talk thread started by Anthony on Sept. 21, 2009 can be viewed here. (nabble) Anthony proposes uploading the parcel boundaries from a public dataset that he acquired from his local assessor in Florida along with some discussion about a tagging scheme. He mentions particular interest in the address information. Frederick Ramm encouraged proper resolution of overlapping boundaries. Pieren mentioned that he and fellow users in France decided not to upload the parcel boundaries because they change frequently, are not verifiable, and may not be valuable to the OSM community. A discussion proceeded around other import best practices, tagging practices, updating pitfalls, and an offer for collaboration.

Thread: Importing Arkansas data

The original imports thread started by Al Pascual on Mar. 21, 2011 can be viewed here. Al announced his intention to use a custom ArcGIS tool to import state-wide parcel data for Arkansas, and then proceeded with the automated import. Others expressed concerns that this import had not been properly discussed. After a few days of importing, Al's account was blocked to halt the import. He subsequently deleted the parcel boundaries. In the aftermath of this, the discussion broadened to question the importing techniques used by Al and a debate regarding the value of parcel data to the OSM community. The main points regarding the latter included concerns that:

  • Are parcel boundaries useful to OSM?
  • Can parcel data possibly be kept up to date considering how frequently it changes?
  • Does parcel data meet the verifiability criteria?
  • Parcel data is too big and clogs up editors
  • Continual imports of parcel data (and other data) undermine OSM as a human-editable map

Thread: Fresno castradal [sic] imports

The original talk-us and import threads initiated by Paul Norman on April 26 2012 can be viewed here (nabble) and here respectively. Paul mentions a number of problems with the Fresno cadastral import that was performed in 2010 by Nathan Mixter. He cites a consensus against "dumping" cadastral data in OSM and proposes to delete all of the parcel polygons. Martijn van Exel and Nathan Mixter dispute the existence of a consensus against cadastral data, but agree that "dumping" (i.e., imports that violate best practices) are unacceptable. Toby Murray cites the Arkansas case as support against parcel boundaries. Paul Norman mentions a Spanish cadastre import that ultimately decided not to import parcel boundaries. Nathan Edgars II and Alan Mintz make the point that the parcel data density restricts the size of the maximum area that can be edited. Ian Dees points out problems with "on the ground" verifiability of parcel boundaries, and that parcel data is difficult to keep up to date because it is created administratively by official entities outside of OSM. Paul Johnson and Nathan Mills point out that parcel boundaries are verifiable (albeit with notable difficulty). Paul Johnson and Brett Lord-Castillo report that parcel boundaries are useful in the context of natural disaster recovery. Toby Murray disputes natural disaster recovery as being within OSM's scope. Gregory Arenius defends parcel data as a nice touch in rendered maps, and a solid base to work with for other mapping tasks, like updating landuse. He also responds to the matter of parcel data density as a tool problem, not a data problem with parcel data specifically. As of this writing, the Fresno parcel boundaries still appear in the data base.

Thread: parcel data in OSM

The original talk-us thread initiated by Jason Remillard can be viewed here. (nabble)

Fresno and data quality

I don't have a problem with importing parcel data if it of high quality and can actually be useful. But sometimes the data will have only the shape of the parcel and nothing else included. If they have address data included with the parcel or zoning designation then they become more helpful. Many counties offer parcel data or zoning data.

I was able to get permission from Fresno County to add their parcel data to OSM. The data set was extensive. It included exactly what the parcel was used for, many of which could be translated into OSM. It even included down to what individual crop was grown. It did not include addresses, but these could easily be added later in areas that are surveyed. Some of the parcels were empty or did not translate into an OSM value and need to be surveyed later on to see what the land use is. Overall it was a good way to turn a blank white map into a map full of color and meaning.

http://www.openstreetmap.org/?lat=36.779&lon=-119.835&zoom=11&layers=M -- Srmixter 22:38, 23 March 2011 (UTC)

Thanks for the feedback. I'd agree that just parcel geometry is not worthy of import, but address or landuse information is. - Joshdoe 12:02, 24 March 2011 (UTC)

Please do not import as landuse=residential

Please do not import this as landuse=residential. It'd make things only worse. We need a new tag for a parcel, since usually it is contained in a landuse=residential. Let it not be the same. It contradicts years of work in which human mappers handcrafted landuse=residential data from survey or aerial data. Mixing in official data does not help keeping things right. --Cmuelle8 21:19, 6 September 2011 (BST)

is verifiable

In developed countries at least the parcel corners are in fact marked on the ground by the state surveyors. Or were when the parcel was defined. Difficult and extremely tedious to verify, but they exist. Alv 09:00, 8 September 2011 (BST)

It's easier than that – fences tend to follow parcel boundaries reasonably well. Ploppy 17:02, 19 December 2011 (UTC)

Subdivision boundaries

I found boundary=cadastre might be a good way to use on the boundary between thousands of parcels A0001 throgh A6666, and another set B0001 through B7777. Jidanni (talk) 05:46, 13 June 2020 (UTC)

A June 2021 summary by a cadastral land surveyor

The following intends to answer questions concerning the handling of parcel-related information within the OSM community. The Parcel page was updated to supplement the US-focused recording with some international perspectives. Here, after three initial positions, arguments of the Parcel and the Talk:Parcel pages are commented upon.

  1. An OSM understanding on the role of parcel boundaries and associated parcel attributes has to reflect the administrative capacity of the country concerned. However, the specifics of 'administrative capacity' or 'governance system structures' are research issues, so most likely alternative characteristics have to be found
  2. The most important element of OSM activities is the potential of contributing to social development: ' ..many OpenStreetMap participants have gone on to become more fully engaged citizens'[1]
  3. The Guide of the Humanitarian OpenStreetMap Team concludes with a 'first step for developing critical basemaps and spatial understanding'[2]. The role of parcel-related data should be specified within the context of an update of these basic recommendations

Verifiability

The very idea of OSM is to map what you find. So my general position is that any claim of having recorded in OSM the legal boundary of the parcel should be avoided. The parcel boundary in OSM should be considered on par with the administrative status of 'assessor parcels'

Feel free to opine that I want to reserve the legal boundary domain for me and my land surveying colleagues world-wide. The fact is, however, that licensed surveyors, organized in societies with established professional codes of conduct, where cases are regularly assessed by a tribunal, (cf. for the United States) are not available all places world-wide. Therefore, volunteered mapping of parcels offers an important potential for social development.

The above general position may be nuanced. Take a jurisdiction where the land registry has insufficient information technology capabilities. A group of land surveyors or others from the jurisdiction submits a request to the local OSM Chapter or similar body/team, and proposes OSM used for recording the spatial aspects, primarily boundaries, of the content of documents, which are recorded at the land registry. I see no reason why such request should not be accepted, say for a limited (5 years ?) period. Such use of OSM is not import of data in the technical sense, but advises at Import Guidelines should be observed.

Data and data structure

Parcel-related data includes parcel boundaries (with geometry, identifier, and marked parcel corners), building outlines/footprint, post addresses, zoning/ open space, and area. The latter relate to the complex Area_datatype issue. Note the Proposals

I suggest to avoid using 'parcel data' as a general term, including 'parcel boundaries and some associated data, including addresses, land use, .. , ..'

The international standards and the CaLAThe vocabulary provides for definitions and concept structures, which should be used as reference. The section on United States mentions that 'assessors may combine adjacent parcels owned by the same entity for administrative reasons.' Such collection of parcels are proposed as Super Areas. The concepts are covered by the OGC LandInfra standard and CaLAThe as well.

Marker and Survey Markers are included in OGC LandInfra as SurveyMark (7.2.1.4), together with SurveyMonument (7.10.5) and a number of SurveyMonumentTypes. The type boundaryMark compares to 'Marked parcel corner'.

Building outlines/footprint should be considered independent from Parcel, following Buildings

Post addresses are considered a 'parcel attribute'. In my view, the options presented at Addresses should take precedence and the post address issue kept out of the Parcel discussion.

Zoning redirects to Parcel. The OGC LandInfra includes two attributes of LandParcel: currentLandUse: optional, jurisdiction-specific enumeration, e.g. of actual land use (cropland, forest, grassland, wetland, settlements, …), and plannedLandUse: optional spatial planning land use categories (urban, rural, coastal zone, …) The ISO LADM is being revised, and the new version shall include a part on spatial planning.

Parcel boundaries are supposed to match existing administrative boundaries and boundaries of roads.

Administrative boundaries are recorded in OSM in the context of national and subnational boundaries. Jidanni in 2020 suggested ' boundary=cadastre might be a good way to use on the boundary between .. parcels'. - I support this proposal.

Boundaries of roads seem not presently addressed by Highways, but Detailed geometries for roads is addressed on the Talk page. - I suggest that matching problems are deferred to an eventual implementation phase

Interaction with external sources, imports

'The most efficient way to populate an area with parcel data would surely be to import a government dataset'. - Well, this statement seems to ignore that OSM is in operation in jurisdictions, which yet do not have complete parcel datasets available.

An account of world-wide coverage is available from joost schouppe's diary (Dec. 2020): Growth of the OpenStreetMap Foundation membership - impact of the active contributor membership program.

OpenStreetMap for Government provides some examples, including e.g. OSM & government, in Lithuania.

More details are found in the report: Crowdsourcing and Government … about governmental projects that incorporate crowdsourced data. The report includes a section on VI. Land Tenure in Tanzania, stating that 'The “Mobile Application to Secure Tenure (MAST)” project enables villagers to identify property boundaries and gather the information officials need to issue land ownership documents. .. .. The [USAID funded] project which started in 2013 will be active until 2018 and will be funded with approximately $18,800,000.' However, a 'Lessons Learned Report, JUNE 2016' states that 'The Mobile Application to Secure Tenure (MAST) pilot project (2014-2016) was originally designed to test a concept: can a participatory or crowdsourced approach to capturing land rights information using mobile technology be deployed and used effectively to create an inventory of land rights? Over the course of the pilot, the focus of efforts expanded from testing a concept to actually delivering formalized documentation of land rights in collaboration with the Government of Tanzania (GOT).' 'The pilot grew out of an idea proposed in a RICS Crowdsourcing Report entitled “Crowdsourcing Support of Land Administration - a new, collaborative partnership between citizens and land professionals.” The RICS report states that 'The highest profile mapping based crowdsourcing initiative is OpenStreetMap', but reference to OpenStreetMap is missing in the Lessons Learned report. Its Conclusion section mentions in subsection 5 on technology tools: 'The project also explored an assortment of mobile applications or tools kits that could either be used for a mobile application. Most prominent among these was ESRI’s ArcGIS mobile application. Options were also explored to build the platform using Open Data Kit (ODK). The project decided, however, to issue a Request for Proposals for the development of an integrated solution: a mobile data capture tool and data management facility, given that these were identified as key elements to test the technology in Tanzania and given opportunities for securing tenure by issuing land rights documents. ' This is not the place to development on the findings of the Lessons Learned report. It is sufficient to note that the ambition to prepare and issue land rights documents goes beyond the general position taken above under Verifiability: 'any claim of having recorded in OSM the legal boundary of the parcel should be avoided'; and this holds even more for documentation of land rights.

The Kingdom of Lesotho is using OSM to transition its national GIS away from traditional tools. - An article on 'Remaking land and maps in Lesotho' addresses cadastral mapping and hence parcels. The initial Highlight of the paper claims: 'Maps are instrumental in making land investable'. Again, this emphasis goes beyond what is verifiable, and moreover, no mention is made of the potential of OSM.

Import guidelines are now available. Among others, they note that 'Different geographic areas in OSM have different acceptance levels for imports'

Category Government notes register_office, but not offices /agencies related to parcels: Land registry or Cadastre

Data density, zoom level

The Import/Past problems page seems to suggest that the data density issue is assessed in the context of mandatory discussions on data import.

Keep server resources in mind informs on, how to avoid overloading the server.

OpenStreetMap has no concept of layers.


--CadProf (talk) 12:31, 22 June 2021 (UTC)

References

Parcel Address Data

I am almost certain this exact question has been asked somewhere, but I thought by mentioning it here, someone can point me in the right direction. I am currently transforming some data for a address import (import page here), and I am wondering if I should filter out the addresses that are not associated with structures. Thoughts? IanVG (talk) 20:45, 3 July 2022 (UTC)