[Talk-ca] Canvec reverts

Thu Sep 1 13:54:52 UTC 2016

Hi all,

I'm still a fairly new mapper and I've yet to gather much first-hand
experience on much of what is being discussed here, but I've been following
the discussion and I certainly agree Nakaner does not appear to have a very
conciliatory attitude for someone who does not belong to the relevant
mapping community.

Surely a single remote contributor shouldn't be able to unilaterally
reverse the consensus of the local mappers?

As for the calculation of the changeset speed, isn't it possible that a
contributor would work on different changesets in a row and then upload
them one after the other?

On a final note, though, I certainly would approve of any effort to reduce
the size of the upload chunks and the assorted polygons. For new mappers
like me, those create daunting challenges when trying to make incremental
improvements to an area. Shortly after joining the OSM community I was back
in my home town of Saint-Félicien, in a fairly remote region that hasn't
had tons of local mapping done. Some of the inhabited areas I aimed to
improve were covered by Canvec forest multipolygons, and I ended up giving
up on them until I could get some more experience as I absolutely did not
understand what the hell was going on....

Cheers
Loïc

On Thu, Sep 1, 2016 at 9:06 AM, <talk-ca-request at openstreetmap.org> wrote:

> Send Talk-ca mailing list submissions to
>         talk-ca at openstreetmap.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://lists.openstreetmap.org/listinfo/talk-ca
> or, via email, send a message with subject or body 'help' to
>         talk-ca-request at openstreetmap.org
>
> You can reach the person managing the list at
>         talk-ca-owner at openstreetmap.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Talk-ca digest..."
>
> Today's Topics:
>
>    1. Re: broken forests in eastern Canada (James)
>    2. Re: CanVec Reverts (Begin Daniel)
>    3. Re: broken forests in eastern Canada (Begin Daniel)
>
>
> ---------- Forwarded message ----------
> From: James <james2432 at gmail.com>
> To: john whelan <jwhelan0112 at gmail.com>
> Cc: Talk-CA OpenStreetMap <talk-ca at openstreetmap.org>
> Date: Thu, 1 Sep 2016 08:54:10 -0400
> Subject: Re: [Talk-ca] broken forests in eastern Canada
>
> I'm not sure if anyone from the DWG will do anything, but I agree he
> should be prevented from making changes to Canada. He thinks he knows
> better than the local mappers
>
> On Sep 1, 2016 8:49 AM, "john whelan" <jwhelan0112 at gmail.com> wrote:
>
>> It would appear that Michael has no appreciation of how we the local
>> community work or of how large Canada is nor does he appear to be able to
>> communicate with us and understand our concerns.
>>
>> I suggest we formally request that he is prevented from making any
>> changes within Canada and his reversals be reverted.
>>
>> The Canvec data was imported with the knowledge and support of the local
>> mappers and I think that's all that matters.
>>
>> Cheerio John
>>
>> On 1 September 2016 at 08:39, Michael Reichert <nakaner at gmx.net> wrote:
>>
>>> Hi,
>>>
>>> Am 01.09.2016 um 01:21 schrieb dega:
>>> > On Aug 31, Daniel Bégin wrote:
>>> >> On the same topic, it has been suggested to split wooded areas in
>>> smaller
>>> >> chunks by using features on the ground as outer limits (mostly roads,
>>> >> streams, rivers) and get rid of arbitrary rectangles from Canvec.
>>> >> Is it something we are aiming at?
>>> >
>>> > The grid is an important source of problems. Here are some examples:
>>> > 1) If a lake is on the grid, it will be split in 2 parts. Each part
>>> will have
>>> > a name tag and and 2 identical names will be displayed on the map, one
>>> on each
>>> > part. This problem exist in thousands of lakes. I even saw a lake with
>>> a
>>> > triplicated name.
>>> > Merging the parts would require modifying 2 or more relations and many
>>> > importers don't do it (even if they use JOSM) because of the
>>> complexity. Some
>>> > have used a quick fix where they remove names from the parts and put
>>> it in a
>>> > POI. It looks fine but that's bad for database integrity.
>>>
>>> If someone does not merge two lakes because it is too "complex", he
>>> should evaluate if he is the right person to import such data. If an
>>> import contains much multipolygon relations, the people how import the
>>> data should know how they work, what can be done wrong, how to edit and
>>> how to fix them. :-/
>>>
>>> > 2) A addr:interp way may be split in 2 parts. 2 consequences:
>>> > - the interpolation way become useless because it's now 2 different
>>> objects.
>>> > - the mid-point becomes 2 superposed nodes. Useless duplication.
>>> >
>>> > 3) A grid tile has a fixed size. It may be appropriate for unpopulated
>>> areas
>>> > but it is too large for urban areas where editors work at a high zoom
>>> level
>>> > (17 and up). It's easy to damage a relation without knowing it.
>>> >
>>> > But there are other problems (not related to the grid):
>>> > 4) the relations seem to be designed to be stand-alone. Thus the
>>> relation
>>> > borders don't share a way. They use 2 superposed ways. Useless
>>> duplication.
>>> > It's very confusing and we frequently alter the wrong way.
>>> >
>>> > 5) lakes are represented by 2 superposed identical objects, one for
>>> the hole
>>> > and one for the lake. If the hole happen to be on top, the name will
>>> not be
>>> > displayed. It's an unjustifiable complexity for the casual user.
>>> > I've also seen triplicated contour (one for the lake, on for the inner
>>> role
>>> > and one for the outer role)
>>> >
>>> > Yes, all these quirks can be fixed manually but it's time-consuming
>>> and error-
>>> > prone.
>>>
>>> What about reverting the tiles which have all these issues and seem to
>>> be uploaded with too few checks beforehand, run a better version of the
>>> preprocessor on the CanVec raw data and reimport them again? (That
>>> causes a loss of OSM history but an import changeset is not as much
>>> valueable than a manual changeset)
>>>
>>> > Ideally, the contour of a forest must not split any object and it's not
>>> > possible with a grid.
>>> > The sole advantage of a grid IMHO is to simplify the CanVec exports.
>>>
>>> What about replacing the grid by less artificial borders, e.g. roads,
>>> rivers, powerlines etc. If an area has too few of theses objects,
>>> artifical borders could be automatically drawn which are optimized to
>>> cut as few objects as possible into two parts.
>>>
>>> > Some years ago I would have proposed that someone write a guide "How
>>> to fix a
>>> > CanVec import". But now I would rather propose that someone write a
>>> "How to
>>> > pre-process a CanVec export before importing it into OSM".
>>>
>>> +1
>>>
>>> All ongoing changesets which import CanVec data should either use an
>>> improved version of the preprocessor or should undergo the manual
>>> quality checks I described in my other emails and the changeset comments.
>>>
>>> Best regards
>>>
>>> Michael
>>>
>>>
>>> --
>>> Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
>>> ausgenommen)
>>> I prefer GPG encryption of emails. (does not apply on mailing lists)
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>>
>>
>
> ---------- Forwarded message ----------
> From: Begin Daniel <jfd553 at hotmail.com>
> To: Michael Reichert <nakaner at gmx.net>, Begin Daniel <jfd553 at hotmail.com>,
> "talk-ca at openstreetmap.org" <talk-ca at openstreetmap.org>
> Cc:
> Date: Thu, 1 Sep 2016 13:04:30 +0000
> Subject: Re: [Talk-ca] CanVec Reverts
> I understand your point. You might be right about the time between
> changesets (even though it may depends on if the users is working with
> layers), but I maintain my points about the time it may take within a
> changeset.
> Daniel
>
> -----Original Message-----
> From: Michael Reichert [mailto:nakaner at gmx.net]
> Sent: Thursday, 1 September, 2016 08:37
> To: Begin Daniel; talk-ca at openstreetmap.org
> Subject: Re: [Talk-ca] CanVec Reverts
>
> Hi Daniel,
>
> Am 2016-09-01 um 12:26 schrieb Begin Daniel:
> > Furthermore, I hope you will not use you 100 objects per minute to
> > decide whether or not you will delete a changeset. I think this
> > threshold is value doesn't' apply (see below)
> >
> > Daniel
> >
> > About the100 objects threshold.
> > From my experience, if I load a Canvec tile in JOSM, make all the
> necessary corrections and then import the result to OSM, I throw up to 25K
> objects to the database within five minutes.  As far as I know, the
> timestamps attached to the changeset and to the objects is generated by the
> OSM database when receiving the data. The five minutes it takes to upload
> the data to the database (5K objects per minute) do not reflect the time I
> spent editing the data prior to the upload.
>
> That's the base of my calculation I did with Rps333's changesets:
>
> changeset       start           end             object count
> ------------------------------------------------------------
> 39517571        19:30:53        19:32:56        4311
> 39517686        19:35:30        19:41:12        11724
> 39517944        19:45:15        19:47:27        4963
> 39518147        19:53:25        20:04:55        19286
>
> As you see, he took less than three minutes minutes after uploading
> 39517571 to prepare 39517686. You cannot check such an amount of data very
> well within that time.
>
> Best regards
>
> Michael
>
>
> --
> Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
> ausgenommen)
> I prefer GPG encryption of emails. (does not apply on mailing lists)
>
>
>
> ---------- Forwarded message ----------
> From: Begin Daniel <jfd553 at hotmail.com>
> To: Michael Reichert <nakaner at gmx.net>, "talk-ca at openstreetmap.org" <
> talk-ca at openstreetmap.org>
> Cc:
> Date: Thu, 1 Sep 2016 13:05:48 +0000
> Subject: Re: [Talk-ca] broken forests in eastern Canada
> Few comments...
> - The people how import the data should know how [multipolygon] work (), +1
> - Run a better version of the preprocessor on the Canvec raw data and
> reimport them again? Not possible. Canvec data has been produced and renew
> between 2010 and 2012 by our national mapping agency (NRCan). The product
> is now static (no updates) but NRCan graciously keeps it available to us...
> - Replacing the grid by less artificial borders, e.g. roads, rivers,
> powerlines... Some of us have started doing this - including myself.
> However I do not consider it as a real problem since the multipolygon have
> to be split somewhere anyway.
> - [Imports] should undergo the manual quality checks I described in my
> other emails and the changeset comments. Agreed, but how many errors will
> you tolerate in a changeset before deleting it?
>
> Daniel
>
> -----Original Message-----
> From: Michael Reichert [mailto:nakaner at gmx.net]
> Sent: Thursday, 1 September, 2016 08:40
> To: talk-ca at openstreetmap.org
> Subject: Re: [Talk-ca] broken forests in eastern Canada
>
> Hi,
>
> Am 01.09.2016 um 01:21 schrieb dega:
> > On Aug 31, Daniel Bégin wrote:
> >> On the same topic, it has been suggested to split wooded areas in
> >> smaller chunks by using features on the ground as outer limits
> >> (mostly roads, streams, rivers) and get rid of arbitrary rectangles
> from Canvec.
> >> Is it something we are aiming at?
> >
> > The grid is an important source of problems. Here are some examples:
> > 1) If a lake is on the grid, it will be split in 2 parts. Each part
> > will have a name tag and and 2 identical names will be displayed on
> > the map, one on each part. This problem exist in thousands of lakes. I
> > even saw a lake with a triplicated name.
> > Merging the parts would require modifying 2 or more relations and many
> > importers don't do it (even if they use JOSM) because of the
> > complexity. Some have used a quick fix where they remove names from
> > the parts and put it in a POI. It looks fine but that's bad for database
> integrity.
>
> If someone does not merge two lakes because it is too "complex", he should
> evaluate if he is the right person to import such data. If an import
> contains much multipolygon relations, the people how import the data should
> know how they work, what can be done wrong, how to edit and how to fix
> them. :-/
>
> > 2) A addr:interp way may be split in 2 parts. 2 consequences:
> > - the interpolation way become useless because it's now 2 different
> objects.
> > - the mid-point becomes 2 superposed nodes. Useless duplication.
> >
> > 3) A grid tile has a fixed size. It may be appropriate for unpopulated
> > areas but it is too large for urban areas where editors work at a high
> > zoom level
> > (17 and up). It's easy to damage a relation without knowing it.
> >
> > But there are other problems (not related to the grid):
> > 4) the relations seem to be designed to be stand-alone. Thus the
> > relation borders don't share a way. They use 2 superposed ways. Useless
> duplication.
> > It's very confusing and we frequently alter the wrong way.
> >
> > 5) lakes are represented by 2 superposed identical objects, one for
> > the hole and one for the lake. If the hole happen to be on top, the
> > name will not be displayed. It's an unjustifiable complexity for the
> casual user.
> > I've also seen triplicated contour (one for the lake, on for the inner
> > role and one for the outer role)
> >
> > Yes, all these quirks can be fixed manually but it's time-consuming
> > and error- prone.
>
> What about reverting the tiles which have all these issues and seem to be
> uploaded with too few checks beforehand, run a better version of the
> preprocessor on the CanVec raw data and reimport them again? (That causes a
> loss of OSM history but an import changeset is not as much valueable than a
> manual changeset)
>
> > Ideally, the contour of a forest must not split any object and it's
> > not possible with a grid.
> > The sole advantage of a grid IMHO is to simplify the CanVec exports.
>
> What about replacing the grid by less artificial borders, e.g. roads,
> rivers, powerlines etc. If an area has too few of theses objects, artifical
> borders could be automatically drawn which are optimized to cut as few
> objects as possible into two parts.
>
> > Some years ago I would have proposed that someone write a guide "How
> > to fix a CanVec import". But now I would rather propose that someone
> > write a "How to pre-process a CanVec export before importing it into
> OSM".
>
> +1
>
> All ongoing changesets which import CanVec data should either use an
> improved version of the preprocessor or should undergo the manual quality
> checks I described in my other emails and the changeset comments.
>
> Best regards
>
> Michael
>
>
> --
> Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
> ausgenommen)
> I prefer GPG encryption of emails. (does not apply on mailing lists)
>
>
>
> _______________________________________________
> Talk-ca mailing list
> Talk-ca at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-ca/attachments/20160901/ab753887/attachment-0001.html>