OpenStreetMap

Land Use versus Residential Private Property

Posted by Adam Martin on 29 June 2013 in English (English)

So there aren't a whole lot of mappers on my side of the pond (the Atlantic). This makes sense - the OSM project started in Europe and has had to gain acceptance in the North American landscape against Google Maps. The lack of mappers in general makes it such that there are not a lot of examples of people handling some of the more unique architecture that this continent sports.

For example, there is very little markings within OSM specifically for laying out trails meant primarily for offroad vehicles - Quads, trikes, etc. The closest times are footpaths with a flag for motor vehicles, though that might tend to imply that this is a road that allows cars to pass, which is not accurate. Looking around the continent, I don't see a lot of these marked and ones that are marked are not done in a manner that provides the user a great deal of information.

The same case falls for the treatment of the local land zoning. Municipalities in my areas zone land between Industrial, Commercial, and Residential use with a fourth option being held for Government facilities. This is not unlike the rest of the world, of course, but I find it odd to mark the use of the land itself, but not mark the boundaries of a particular property within that land area. The reason I find that odd is that, should the use of the land as private parcels be marked (as would seem to be reasonable) the Land Use tag will be basically covered in. So I am left with the question as to what is the best method of breaking down the use of the land and marking the plots themselves.

Fortunately, the OSM project is open enough that I can do several experiments to determine what is the best and most effective method of doing this. In that case, I have been marking some of the local residential properties in my area to test which method will provide more information to the users. I will likely document my findings in a further diary entry - for my own benefit and for others. Besides, a good clear explanation can provide one with a defensible position in terms of rationale - which is the mark of a good process, that of an audit trail.

Comment from SK53 on 29 June 2013 at 15:56

Broadly speaking don't use landuse for zoning areas.

Use the landuse tags for what is on the ground (which of course ought to correspond with local zoning). Many local administrations will do zoning on a long-term timescale of perhaps several decades. It is no use to anyone to mark areas earmarked for new sections as residential if they are still farmland.

Secondly, dealing with many hundreds of landuse polygons will make landuse data from OSM more or less unusable. Because there is no enforcement that given types of polygons must not overlap, a lot of post-processing is needed on OSM data already. Increasing the number of objects (by perhaps a hundred- to a thousand-fold if you map individual house plots as residential and individual shops as retail. Additionally complex algorithms are then needed to define landuse beyond property boundaries.

I've yet to see a convincing use-case for mapping property boundary details in OSM: enough people have done it to show it's possible, but I'm not aware of anyone with a need to get this data from OSM. Incidentally the vast bulk of use-cases for landuse (including cartographic products) require reasonably generalised polygons.

Hide this comment

Comment from Circeus on 29 June 2013 at 18:24

"there is very little markings within OSM specifically for laying out trails meant primarily for offroad vehicles - Quads, trikes, etc."

OSM assumes most "highway" are useable by motor vehicles, on foot and bicycle. Access tags should not be overlooked when dealing in this area! highway=track+access=no+ATV=yes

The only reason the ATV tag has not gained much attention is that all-terrain vehicles are little used overseas, but that doesn't mean that the basic rule of "when in doubts, use whatever new tag you think fits" has lost validity! (worst case, if another use become dominant, your original tagging will be changed to that other tag later on)

Hide this comment

Comment from cartinus on 29 June 2013 at 20:50

It's atv=yes, not ATV=yes. Whenever possible (except in names) OSM uses lowercase tags.

Hide this comment

Comment from CloCkWeRX on 30 June 2013 at 07:06

Here in Australia, I've found it more useful to rely on (commercial) data sets to provide the Cadastre - what a fence says and what a certificate of title say about a property are different beasts.

I find it useful to depict fences for large industrial areas, etc.

For the folks suggesting 'adding a bunch of little polygons to OSM for property boundaries doesnt add much value, I'd counter that:

1) Housing values tend to be made up entirely of land value, and a little bit of improvments (physical structures)

2) Having a polygon for a property means you can calculate the sqm of a property

3) If you have information from an MLS, there's a good chance you can work out an approximate value per square meter figure for a locality, and accordingly provide figures about How Much Is A Block Of Land Worth? These sorts of things drive automated valuation models in the finance industry.

Having a number of the components that go into such a calculation as open data implies that more people can do said calculations - you only need one or two non-free sets of data. That leads to a much lower barrier of entry, and means that if a certain model is wrong, you can sanity check that against an open equivalent.

More models, calculations and proof = more trust; more trust = less speculation, less sharp corrections of housing markets :)

Hide this comment

Comment from Adam Martin on 30 June 2013 at 16:56

@SK53 @Circeus @cartinus @CloCkWeRX

Thanks for the comments so far - my take is that the more data that is available to the users, the better. I notice on the public map, the polygons that make up the individual plots are merged for display. Given that, I am going to make the assumption that the actual polygon weight for the purposes of rendering the images is rather low. Poly limits for the actual display will be fairly low anyway, as long as one doesn't get so ridiculous as to note a pile of sub-shapes in the properties (such as for the compost bin and such).

Structured correctly, I imagine the database weight for the same information should be fairly low as well. I am not aware of much of the structure of the backend of the database for the project, but I can understand that too many shapes in the same place can be a bit of a problem. My intent is not to have too many overlapping polys. I have done some 3D work over time so I am aware of the troubles that this can cause. Still, my intent is not to get completely ridiculous with the concept of nesting polygon within themselves. Residential buildings are situated on an entire property area, so that polygon will nest within the larger property polygon. Things like driveways need not be poly-shaped - that can be saved for ways instead, which reduces the overall weight of the information.

I have done some looking and seen several posts with individuals experimenting with structures for neighborhoods including adding fencing ways and similar. So there are some wide opinions on the matter.

The Land Use tag is an interesting issue in of itself. If I denote an area as "Residential" and then mark the properties within as individual private parcels and the buildings (both the homes and the auxiliary buildings), then I have effectively nested a poly in a poly in a poly. Not sure if that is the cleanest idea, but it does aid the idea of a wide range of potential queries to the database information. There are no "right ways" to do something - push with what you got and see how others react. Though I do wonder - if you are marking the land use, do you mark the roads themselves as residential or commercial, etc? If that is the case, the land use poly can be slightly larger than the individual property polygons, greatly reducing potential problems by not having too many edges leading off of a single vertex. In computer graphics, that is known as a rats nest and systems generally hate that. The other similar route to take is not to include the roads, but to encapsulate the properties out far enough to include the easement for public foot traffic (sidewalks). That again serves to keep the polys nested within each other as a whole. Bears some experimentation.

Hide this comment

Comment from SK53 on 1 July 2013 at 00:06

@CloCkWeRX I still don't get exactly why it needs to be in OSM: are you wanting to free cadastral data from commercial constraints,? 'cos it doesn't sound like it when you mention commercial datasets. The type of application you describe sounds mainly of interest to organisations which can afford non-free data.

Most of the applications that use landuse which I am interested in: contesting major planning changes, pollution in watersheds, environmental (habitats/biotopes etc) value of particular areas, and so on - are things which single individuals, small non-commercial groups, and charities are likely to want to do.

@AdamMartin it's nothing to do with database weight (if I understand what you mean by this), although lots of buildings from cadastral data in France are regarded by many mappers as 'bloat' (largely because houses w/o addresses arent very interesting), it's to do with the pain of processing lots of polygons. The nature of OSM is that one does have polygons in polygons.

Hide this comment

Comment from russdeffner on 1 July 2013 at 02:41

For the Colorado Wildfire mapping project, we're using (and I've been doing the same in my local area) this basic tagging scheme: - landuse (most importantly residential) is drawn roughly around a structure or group of structures where there is a visible difference between that and the natural surrounding; using natural=wood, scrub, or grassland (majority) for the 'ground cover'. - highway=track is typically what we use for 4x4/off-highway vehicles, with or w/o surface, type, smoothness, etc. unless it's got a 'predicted' residential use; i.e. there are multiple homes along it somewhere (single home/ranch typically tagged service). Even if it looks rough, the 'usage' of roads up here are better tagged as residential, etc. You'd be surprised what people will drive up, so hesitate to use footway unless it is restricted to non-motorized vehicles.

Hide this comment

Comment from Adam Martin on 1 July 2013 at 17:42

@SK53

That is very interesting - I can see why some might think having a lot of detail on a map might not be efficient. Can it be a sort of minimalist mentality? In any case, I don't have the same outlook. As an Auditor, I have found in my job that detail being made available is never a bad thing. If the information is present in the database, it is then up to the individual or group drawing on that data to determine if they want to see it. As long as it is accurate, then the users should benefit from the attention to detail.

@russdeffner

That is a good idea - I will likely integrate something similar in my area. The land use tags seem good for blocking in the major sub-areas (residential) instead of mass-setting an entire municipality as one and trying to back off sub-polys within it later.

Hide this comment

Comment from pnorman on 12 July 2013 at 10:25

There is actually a general consensus against the importing of property lot data into OSM.

Stuff like fences, hedges, etc get mapped and are verifiable, but these don't always correlate to property lots. Many times what you'd think was one lot when looking on the ground is really multiple ones. Then you get buildings that sit on multiple lots, etc.

Hide this comment

Leave a comment

Parsed with Markdown

  • Headings

    # Heading
    ## Subheading

  • Unordered list

    * First item
    * Second item

  • Ordered list

    1. First item
    2. Second item

  • Link

    [Text](URL)
  • Image

    ![Alt text](URL)

Login to leave a comment