[Talk-GB] Incorrect use of OS VectorMap District when mapping?

[SK53 on OSM]

On 09/02/2011 20:27, Kevin Peat wrote:
> Hi Jason,
>
> I am the mapper (user:devonshire) who imported the woods in your first 
> example around Dartmouth but it was last May so not exactly recently. 
> The woods that are there now are a lot better than the NPE traced ones 
> that we had before. I took the view at the time that importing the 
> VectorMap data would be a major improvement.
>
> Since the Bing imagery (old as it is) became available I am not sure 
> why anyone would bother importing VectorMap woods as it is a lot less 
> hassle to trace from Bing and just take the names from the OS 
> StreetView. Ultimately I will probably replace the OS sourced data but 
> it isn't a big priority for me right now. Feel free if you have 
> nothing better to do.
>
> The VectorMap data for streams is good especially as they are 
> virtually impossible to survey well on the ground. Filling in the 
> blanks may seem like a good idea but whether it is a track bridging 
> the stream, the stream is piped or just disappears for a bit (as often 
> happens in wetland areas) is hard to know without a survey.
>
> Kevin
>
>
>
>
>
>
>
> On 9 February 2011 18:42, Jason Cunningham <jamicuosm at googlemail.com 
> <mailto:jamicuosm at googlemail.com>> wrote:
>
>     OS VectorMap District is an excellent source of data for features
>     like streams and woodland, but these layers of data tend to be a
>     bit of a mess and need to be stitched together as part of a method
>     in importing into OSM.
>     eg Streams will end when they meet a bridge, then reappear the
>     other side of the bridge, so for OSM you need to link all the
>     separate sections of the streams into one long stream
>
>     Started to notice that the VectroMap District data in its "raw"
>     state has started to appear in the map, from more than one mapper
>     http://osm.org/go/erduA_U9K--
>     http://osm.org/go/eugeBnUca-
>     You can see stream are broken presumably at locations of bridges,
>     and woodland has strips missing presumably along paths (and is
>     also made up of several sections if you look at it in an editor)
>
>     Doesn't appear to be guidance in the wiki about how to deal with
>     VectorMap District. I just want to check I'm right in thinking
>     this is the wrong way to go about it? If so I'll try and write up
>     some guidance in the wiki.
>
>     Jason
>
>
>     _______________________________________________
>     Talk-GB mailing list
>     Talk-GB at openstreetmap.org <mailto:Talk-GB at openstreetmap.org>
>     http://lists.openstreetmap.org/listinfo/talk-gb
>
>
>
> _______________________________________________
> Talk-GB mailing list
> Talk-GB at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-gb
  Jason has pointed out a number of issues with the natural features 
layer of VectorMap District. I'd like to add a few more:

    * Larger Streams & Rivers are only present as areas, not vectors, as
      well as not being connected. Absence of vector waterway data,
      particularly when not connected, means that OSM data is useless
      for any kind of hydrographic or hydrological analysis. Old traced
      streams from NPE maps on the other hand are still fit for this
      purpose. Use case: low cost simulation of environmental issues
      (water pollution, flooding) for charities, campaign groups etc.
    * Woodland parcels can be incredibly minute and over detailed: to an
      extent that the detail cannot be verified on the ground.
    * Woodland parcels are often not woodland. So far I have found
      parkland with interspersed trees (see any golf course), small
      groups of trees with no corresponding ground layer (not a wood,
      see first example posted by Jason), wetland features
      <http://www.flickr.com/photos/sk53_osm/4611517582> (exuberant
      over-interpretation of aerial images), avenues of trees, suburban
      and urban parks where one or two old specimen trees have large
      spreads, scrub...
    * Woodland parcels are often separated by a short distance to
      provide for a path, even when the canopy is closed.
    * Many areas are artificially divided by lines corresponding to the
      1 kilometer lines of the National Grid.

The main problem is that although VDM shapes are often extremely 
detailed, in many cases the accuracy and detail is spurious.

Another problem is that adding areas of streams or many woodland 
fragments places a significant burden on a) servers; b) editors and c) 
consumers (see Frederik's post). I like having these things on the map, 
but I do want to be able to have maps on the Garmin which cover a useful 
area. Thus adding this kind of detail may mean thinking either about 
adding new tags or extending existing tagging in the way which is 
happening with buildings. Personally, I might start trying to use 
natural=tree on areas and ways so that some of these 'woodland' 
categories can be separated out: an obvious render approach is like that 
used by the OSGB for 'scattered trees'.

Note that there are vector waterways and woodland available in the OS 
OpenData set which might be more useful as a starting baseline for later 
refinement, notably Meridian 2.

I've recently been looking at Coed y Brenin, in N Wales, one of the 
Forestry Commissions larger forests. I've added from Bing two areas, but 
had contemplated using VDM to do the rest because its so big, and 
reasonable involved. At the moment although MTB trails are well mapped 
none of the forest they traverse is there, so mapnik looks peculiar. 
However, VDM for this area creates around 4000 polygons of woodland: 
some of them tiny. I doubt if anyone will ever be in a position to 
verify each of them, so I dont see that it makes particular sense to 
import this data, but on the other hand I have no desire to spend days 
tracing a 40000 acre forest!

Jerry




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-gb/attachments/20110210/25dd700b/attachment.html>