Hi Sam,
Given the way the discussion went, I believe that (and I am willing to be
corrected here) the consensus was that the forest landuse polygons were, at
best, inaccurate and, at worse, a liability. It seemed that these polygons
are seen very negatively outside the Canadian OSM group. Part of the
consernation regarding these chunks of data was a lack of review by the
importer - basically, the importer should carefully review everything when
importing data into the map and painstakingly correct the dataset to ensure
that its not creating on the ground errors. The other part was, again, the
aftermat difficulty of dealing with imports that did not pass through this
review stage.
Given all of that, perhaps it would be better to skip the forest portion of
the data (and the resulting multi-multi-polygon mess that it creates and
stick to the data you are interested in and have the time to properly
review. If this Manitoba Lands Initiative forest data is very accruate and
much easier to work with, then that might be a better bet, still with the
stipulation that it be closely reviewed and compared to the satellite
imagery to ensure that it's not out to lunch.
You know, it suddenly strikes me that part of the reason that there is so
much trouble with the forest polygons from the Canvec data is less the
accuracy of the data and more the fact that it is brutally difficult to
work with. These enormous multipolygon relations, linking the forests to
open areas, wet lands, and water polygons, creating inner and outer
relationships all within the confines of the Natural Resources map
divisions. I wonder would these be nearly as hard to work with if the
multpolygon relation itself didn't exist? I understand the reasoning for
relations themselves - they are core mapping elements meant to describe
logical arrangements between items. Bus routes are one of the prime
examples of such a thing. Has anyone leaned back and just considered that,
in the case of this forest data, we might be going a bit far to have inner
and outer boundaries to describe breaks in the tree line? Think of it this
way, what is the use of a multipolygon relation? In the Wiki, it is used to
create an area for which the boundary is defined by multiple ways and / or
an area possessing holes. When we import a forest multipolygon, what are we
trying to describe exactly? An area of forest with holes ... which are
not holes, but are simply areas when the tree line breaks and another
feature is present (open grassy area, a lake, a marsh, etc. Looking over
some of these polygons, it is notable that houses or owned are often not
provided a gap if they are not in a city centre. Even more unnerving is the
fact that roads, major or minor, are also not provided gaps nor are they
part of the relation. Essentially, the most important human feature of an
area - the transportation network, is not important enough to be part of
the relation.
Perhaps it would be better to eliminate the multipolygon itself? Simply map
the forest areas and open areas and lakes and so forth and add them to
logical relations afterwards. Take my home province of Newfoundland. If one
were to build a forest polygon, it could be logically broken down into
regional multipolygons (such as one for the Avalon Penninsula). Or it could
even be further divided based on localized geometry.
Just some thoughts on the matter.
Adam
On Thu, Sep 29, 2016 at 6:26 PM, Sam Dyck wrote:
> Hi everyone
>
> Sorry for bringing this up, but I need to some Canvec importing. Given the
> controversy about Canvec earlier this month, I'm trying to decide how to do
> this. I could:
>
> - Leave the forests out entirely.
> - Or use it as an opportunity to experiment with the Manitoba Lands
> Initiative forest data. We've discussed MLI before and done some limited
> importing. And I'm curious to take a look at the data.
>
> Thoughts?
>
> Sam
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca
