[Talk-ca] CanVec Reverts

john whelan jwhelan0112 at gmail.com
Thu Sep 1 11:22:01 UTC 2016


Note to Michael Reichert

I think you should respect the views of the local community.

We know the data isn't perfect but for the most part its good data and as
Daniel has said when I've imported the work is done in JOSM off line over a
period of time so the time apparently taken doesn't really indicate this.

In many parts of the country there are no local mappers for many miles or
kilometers if you prefer.  We do have some very experienced GIS people
around and I'm under the impression that we really do know what we are
doing.

Cheerio John

On 1 September 2016 at 06:26, Begin Daniel <jfd553 at hotmail.com> wrote:

> Thank for contacting the Canadian community Michael,
> You provided us with a short but useful reminder of current rules we
> should apply when importing data (or even just making standard edits).
>
> However, I understand from your last paragraph that you will keep deleting
> changesets. I was hoping your email started a discussion on best practices
> that we could be put in place in our context since adjusting Canvec data to
> the latest rules is a daunting task. I rather feel it is an ultimatum.
>
> Do your future actions will apply to the imports made a few months, a few
> years ago, which are 'full of errors' and for which nobody seems to care?
> Are you going to check with concerned contributors (old/future imports) if
> they bother or not to see their work deleted before you do it?
>
> 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.
>
> -----Original Message-----
> From: Michael Reichert [mailto:nakaner at gmx.net]
> Sent: Thursday, 1 September, 2016 01:39
> To: talk-ca at openstreetmap.org
> Subject: [Talk-ca] CanVec Reverts
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Hi,
>
> unfortunately posting via Gmane does not seem to work (the website is down
> but NNTP still works), that's why I have to start a new thread. :-(
>
> Am Tue, 30 Aug 2016 21:41:21 -0500 schrieb Sam Dyck:
> > After reading through the changeset discussion, I discovered that one
> > of my imports in Northern Manitoba made Worst of OSM.
> > (http://worstofosm.tumblr.com/post/22180046353/dear-
> > openstreetmap-isnt-it-strange-how-the). As someone who spends a some
> > time amount of time in some of relatively unpopulated areas of Canada
> > and makes an effort to check the quality of Canvec data (which is
> > usually pretty good), I do agree that it is impossible to do
> > everything to the same level of quality that we would provide in
> > Toronto or Timmins or even small prairie towns.
>
> First of all, it is ok that an import takes a few years and therefore
> creates ugly green rectancles on the map. If an import is "unavoidable"
> :-), a manual import is the best thing that can be happen. But if someone
> uploads a changeset without a manual review beforehand, he counteracts the
> aim of a manual import: addind good data to OpenStreetMap. That's what I am
> mainly fighting against. If a users uploads much more than 100 objects per
> minute [1], you can be sure that he has not done any manual review. A
> manual review by myself confirmed this these. I am fighting against such
> changesets/users.
>
> A good imports must be reviewed *before* it is being uploaded. The review
> contains:
> - - Run JOSM validator, fix all warnings and errors. This includes all
> warnings regarding validity of areas. (you can argue if all warnings about
> "deprecated" tagging have to be fixed)
> - - Compare the data with available imagery. Is the forest really a forest
> or is another tag more appropiate? Right-click on a Bing tile at JOSM and
> have a look how old/recent the imagery is.
> - - Check if CanVec data fits to itself.
> http://worstofosm.tumblr.com/post/22180046353/dear-openstreetmap-isnt-
> it-strange-how-the
> - - Check if there has been any other data before. If yes, adapt the
> either the CanVec data or the old data.
> https://wiki.openstreetmap.org/wiki/File:Import-Fails-Powerlines-Not-Ins
> ide-Cutting.png
> https://www.openstreetmap.org/way/439631732
> - - Ways should not overlap with other ways if it is not necessary. The
> outer ring of a lake should also be inner member of the forest
> multipolygon. Maybe the program which created the OSM files should be
> imprved?
> - - Keep the history.
> https://wiki.openstreetmap.org/wiki/Good_practice#Keep_the_history
>
> If a tile has been imported without being checked manually and no
> post-upload fixes have been done (i.e. upload without any checks), I will
> not shrink from reverting it. If a tile has been uploaded to OSM without a
> review and if it has not been fixed within a month, it is worthless and can
> easily be reimported at a later time if someone has the time to check and
> fix it.
>
> For the future, I will abstain from reverting changesets which have been
> imported before September 1, 2016 and whose users are currently doing the
> fixes that should already have been done. But if I come across an imported
> tile of low quality which has not been touched for a few weeks and is full
> of errors, it is just a question of time until it is reverte d.
>
> Best regards
>
> Michael
>
> [1] I had a look on a few of my changesets which added a large number of
> buildings to OSM. The fastest changeset contained about 60 objects per
> minute and was full of missing buildings as I later detected while
> collecting the housenumbers and usage of the buildings.
>
> _______________________________________________
> 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/fd8b4bfc/attachment.html>


More information about the Talk-ca mailing list