[Talk-ca] Large polygons in JOSM

[Bruno Remy]

Hello,

Well... i agree with you, Daniel, about use of inner/outer membership roles
of multipolygons : regardless of rendering priorities, this is mandatory
for an accurate outlines extraction for a specific feature: wood, water,
etc...

However, in my opinion, such "raw" multipolygones from Canvec imports and
splitted by square tiles needs to be tuned (splited or merged) mostly close
to urban areas...

Bruno

Le 2014-09-15 17:41, "Daniel Begin" <jfd553 at hotmail.com> a écrit :
>
> Bonjour,
>
>
>
> Well, I understand that multipolygons are often not easy to work with.
However, from what I understand of OSM data model, they should be used
whenever appropriate.
>
>
>
> In that sense, I do not agree with Bruno that 'inner' roles are useless
for lakes in the case of wooded areas. It might be OK for rendering (you
see lakes inside wooded areas because priorities have been used to create
the map) but, IMHO, it is not the case if you work only on wooded areas –
or any feature type!
>
>
>
> About Canvec, the product often duplicates water bodies and inner
polygons of wooded areas; which is not necessary where both were imported.
In order to keep only the necessary geometries, I usually transfer all the
tags from a waterbody to the duplicated geometry of an inner polygon and
then, I delete the original - now duplicated - waterbody.
>
>
>
> a humble two cents...
>
>
>
> Daniel
>
> From: Bruno Remy [mailto:bremy.qc.ca at gmail.com]
> Sent: September-15-14 12:59
> To: Tom Taylor
> Cc: Sam Dyck; Talk-CA OpenStreetMap
> Subject: Re: [Talk-ca] Large polygons in JOSM
>
>
>
> Tom's strategy seems to be appropriate for woods areas:
>
> Canvec 'giant monster' multipolygons represents a set of several polygons
quite closed but not adjascent ,  mostly separated by  meadow/scrub or fire
cut-lines or rivers, or roads ....
>
> By the way: membership as 'inside' role of wood multipolygon is useless
for a lake
>
> So, you never need 'outside' or 'inside' role: just keep outlines of wood.
>
> Mapping this way avoid the use of multipoygons, and encourage the use of
simple polygons (prefered).
>
> (imo)
>
> Simplier is better ;)
>
> But .... indeed.. i agree with Sam: is time consuming ! :(
>
> Perhaps a motivation to encourage membership of new OSM contributors, as
we celebrate the 10th of OpenStreetMap !! ;-)
>
> The more we are.. the less we do ;)
>
>
>
> Bruno
>
>
>
>
>
> 2014-09-15 11:46 GMT-04:00 Tom Taylor <tom.taylor.stds at gmail.com>:
>
> Might be dull, but I generally split multipolygons into reasonably-sized
adjacent chunks rather than giant monsters. In my case, it's usually when
I'm outlining a river.
>
> Tom Taylor
>
> On 14/09/2014 10:29 PM, Sam Dyck wrote:
>
> HI
>
> Currently I'm working on importing the Canvec tiles that make up Lac
> Seul in NW Ontario into OSM. Importing the data as it is, split into
> tiles and subtiles, is poor practice, and manually merging is time
> consuming and dull. So I began using JOSM's Join Overlapping Areas
> feature. This tool however requires that all ways be complete before
> merging. Resulting is a 100 000 node area that far exceeds JOSMs import
> limit and is time consuming to split up, and slows down JOSM. Is there
> an faster way to split this?
>
> Sam
>
>
> _______________________________________________
> Talk-ca mailing list
> Talk-ca at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
>
> _______________________________________________
> Talk-ca mailing list
> Talk-ca at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
>
>
>
> --
> Bruno Remy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-ca/attachments/20140917/212bd5ca/attachment.html>