<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
On 11/03/2011 10:19, Steve Chilton wrote:
<blockquote
cite="mid:DEC2FCE18B20734CAFA668E4384829633701ED87FE@WGFP-EXMBV1.uni.mdx.ac.uk"
type="cite">
<pre wrap="">I have been asked by editor of the Cartographic Journal to write a short piece on the effect of the release of OS OpenData on the OpenStreetMap project, and I am just trying to gather my thoughts, and make sure I cover all bases.
I was present at Blackadder's Society of Cartographers talk on "Why OSM won't be bulk importing OS OpenData" and am aware of the work Chris Hill has done on admin boundaries etc.
Obviously also aware of the ITO work with OS Locator and what people have done with that.
There was work on importing detailed water features, was that Chris as well (goes off to read back through his blog).
Can anyone point me to others who have explored the possibilities that OS OpenData provided - PARTICULARLY if they can evidence WHY it is NOT of value to OSM?
Cheers
STEVE
Steve Chilton, Learning Support Fellow
Educational Development Manager
Centre for Learning and Teaching Enhancement
Middlesex University
phone: 020 8411 5355
email: <a class="moz-txt-link-abbreviated" href="mailto:steve8@mdx.ac.uk">steve8@mdx.ac.uk</a>
<a class="moz-txt-link-freetext" href="http://www.middlesex.wikispaces.net/user/view/steve8">http://www.middlesex.wikispaces.net/user/view/steve8</a>
Chair of the Society of Cartographers: <a class="moz-txt-link-freetext" href="http://www.soc.org.uk/">http://www.soc.org.uk/</a>
'Inspire Me!' lunch time showcase on Assessment and Feedback, organised by the Centre for Learning and Teaching Enhancement <a class="moz-txt-link-freetext" href="http://inspireme.middlesex.wikispaces.net/">http://inspireme.middlesex.wikispaces.net/</a>
_______________________________________________
Talk-GB mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Talk-GB@openstreetmap.org">Talk-GB@openstreetmap.org</a>
<a class="moz-txt-link-freetext" href="http://lists.openstreetmap.org/listinfo/talk-gb">http://lists.openstreetmap.org/listinfo/talk-gb</a>
</pre>
</blockquote>
<br>
Sorry this has been sitting in my outbox for a few days. Ignore if
not of interest now (post new release of VDM & duplication of
others comments).<br>
<br>
A quick summary of other imports known to me:<br>
<ul>
<li>Boundaries: Notts/Derbys (me, will_p), Norfolk (PinkDuck),
Tendring (EdLoach)</li>
<li>Power-lines: a few (me), lots in Scotland (tms13), chillly</li>
<li>These are relatively straightforward imports as the
information can be left as is. In practice powerlines are much
more easily added from Bing imagery than from OSGB VDM.</li>
<li>Woodland, numerous places by various people.</li>
<li>Waterbodies/rivers etc: Tendring (EdLoach), lots in Scotland
(tms13), River Trent & lower reaches of Derwent (me)</li>
<li>VDM Building outlines: done at CenterParcs, Sherwood Forest</li>
<li>Buildings derived from OS StreetView (mapseg by TSC): various
locations, including Preston, Surrey, West Bridgford area.</li>
</ul>
Known areas substantially traced from StreetView:<br>
<ul>
<li>Bolton (steely)<br>
</li>
<li>Oldham (steely)<br>
</li>
<li>Middlesbrough (CGT)<br>
</li>
<li>Darlington</li>
<li>Grimsby & Cleethorpes (warofdreams)<br>
</li>
<li>substantial areas of S. Yorkshire (warofdreams)</li>
</ul>
Areas with names predominantly sourced from OS data, <i>inter alia</i>:<br>
<ul>
<li>Oldham (done by me)<br>
</li>
<li>Darlington</li>
<li>most of NW London (Hayes, Hillingdon, Northolt ...) (done by
me)<br>
</li>
<li>Liverpool suburbs (done by me)<br>
</li>
<li>Corby (and I presume many other areas in Northants)</li>
</ul>
Where I added names it was only to ways already traced beforehand
(both from aerial imagery & from OSSV), and I usually did the
minimum of alteration to what was already there.<br>
<br>
Looking at each available class of data (sorry rather long):<br>
<br>
<b>Boundaries</b>. Some don't like them for mainly reasons of
policy/philosophy. Others (like me) see them as an integral part of
a map. Main problem in importing them was merging with existing data
(to retain things like relation history). Quite a lot of work and
somewhat error prone, but substantially improved data as well.
Experience shows that boundaries are <b>very</b> prone to be being
broken in OSM. On the other hand I think that the process of using
boundaries direct from shapefiles is beyond what most people feel
willing or capable to do. So, OS data was relatively straightforward
to use, somewhat tedious to integrate, convenient for <b>some </b>uses
in OSM. I'd say pros & cons evenly balanced.<br>
<br>
<b>Powerlines.</b> See chillly's blog on this. Major powerlines are
conveniently provided as many short lines with a gap where the pylon
is located. Really tedious to manage directly. Much, much easier to
do from Bing data. Largely useless.<br>
<br>
<b>Water. </b>Riverbanks and lakes as large scale features were
generally better than existing OSM features, often because those had
been traced from landsat/NPE maps etc. Requires significant
post-processing to remove bridge outlines etc. (artefacts of the
fact that VDM is a render dataset). See Mike Collinson's recent
email for issues concerned with this. I have generally only used
this on waterways I have recently encountered (mainly the Trent S
&W of the end of Yahoo Aerial imagery). Some canals have been
imported, as have the banks of smaller waterways. I'm not at all
sure about this: primarily I would like to have base hydrography as
a connected network with flows. Again render artefacts are a pain.
Absence of flowlines in the data for many streams is a real pain.
Generally the most useful of the VDM layers by a long chalk.<br>
<br>
<b>Woodland</b>. In principle as for water, <b>but </b>suffers
from a number of issues. The main one is that the woodland is
subdivided into an absurd number of small parcels (some of this is a
production artefact). Secondly is that perhaps 20% is not woodland,
but scrub, small plantations (e.g., new planting on golf courses),
foliage of individual trees in parkland, avenues, narrow wood belts,
or erroneously interpreted (or coded) reedbeds, sedge-beds and other
'green' areas. Thirdly, woodland paths often separate woodland
parcels even when the path is narrow and in summer canopy is closed
over it. So the woodland data has to be treated with a great deal of
caution. In general most useful as a hint as to where to look at
Bing to trace woodland. <br>
<br>
<b>Residential buildings.</b> Not useful at all, even though it has
been imported in one or two places (see above).<br>
<br>
<b>Other VDM layers.</b> I'm not aware that these have been used in
earnest by anyone. In principle they could be used to identify major
features which are still pretty inaccurate in OSM (e.g., a lot of
motorways, which are often 10s of metres off GPS tracks, presumably
because they were mapped early on). Fun to play with, but not hugely
useful yet for OSM.<br>
<br>
<b>OS StreetView.</b> I've used this to add names to pre-existing
un-named streets on the basis that at least OSM data would then be
more useful. I have only added streets by tracing OSSV to flesh out
a set of roads I'd surveyed and only had stubs at their starting
point (Buckingham). I do use it now to add streets when reported in
a MapDust bug report. Generally useful for improving alignment of
other features. Tracing from OSSV has more in common with tracing
from aerial images than other sources (old maps, landsat etc): a lot
of ground can be covered quickly. A lot of freshly traced OSSV stuff
has never been followed up on the ground. My personal worst case was
the 'Carlton incident' when a user realigned a lot of ground
surveyed roads to OSSV: many have not been restored, and I was by no
means the only mapper affected.<br>
<br>
<b>Buildings from OSSV.</b> mapseg and similar. I don't regard these
imports as successful. I did one and am now working through all the
buildings redrawing them properly. I originally did it because I was
finding adding addresses in the particular area to be a nightmare,
and the Yahoo imagery was not really good enough for useful building
outlines. The data look OK at zoom 15 & 16, its only when one
gets to 17 & 18 that its clear that it's not good quality. In
probability all such data will probably need to be re-done one way
or another. mapseg also used the full new conversion rather than
OSGB36 so is probably out of alignment with other data which used
EPSG:27700.<br>
<br>
<b>OS Locator</b>. Has been useful, both for adding names (for
MapDust, short stub roads) and for quality assurance (ITO, OSM
Musical Chairs). <br>
<br>
<b>CodePoint. </b>Has become useful now that buildings are being
added from Bing, particularly with Chris Hill's postcode tiles.<br>
<br>
<b>Other issues:</b> VDM areas are obviously assembled from 1km by
1km tiles as the polygons all have boundaries on these lines.
Projection and conversion issues across the OSM toolset,
particularly from shapefiles to osm XML.<br>
<br>
<b>Summary:</b> most useful things from OS have been names, and
probably postcodes. Almost everything else has substantial
drawbacks: as has become really obvious with the availability of
Bing data. Apart from the deterrence (TIGER ?) effect of apparently
well-mapped areas, many mappers have invested signficant time into
playing with OS OpenData which may otherwise have been directly used
to map or add to OSM tools. Adding more data from OS OpenData has
merely confirmed what we already knew: "Build and they will come" is
not true.<br>
<br>
Sorry for being so long-winded.<br>
<br>
Jerry<br>
<br>
</body>
</html>