Hi,
On 2016-09-01 21:06:57, Sam Dyck wrote:
> I believe the given what we have just spent the last 24 hours discussing
> this request is unreasonable and the issue is not significant. Thoughts?
An importer who imports data into OSM that doesn't match up with already
existing data and doesn't
Hum
First discussions about importing NRCan data can be find here...
https://lists.openstreetmap.org/pipermail/talk-ca/2008-November/000228.html
They are talking about importing GeoBase - which is exactly the same content
that is found in Canvec since Canvec is the merging of GeoBase
Hello,
Multiple people have referred this issue and changeset 39517002 to the
OpenStreetMap Foundation Data Working Group about this issue. The Data
Working Group has responsibility for the resolution of disputes beyond
the normal means of the community, as well as some responsibilities
>From what Rps333 told me in person he had worked many hours on that
changeset and was frustrated when someone reverted before fixes could be
applied. Could you revert the revert?
On Sep 1, 2016 4:09 PM, "Paul Norman" wrote:
> Hello,
>
> Multiple people have referred this
Sam,
On 09/01/2016 11:26 PM, Frederik Ramm wrote:
>> I believe the given what we have just spent the last 24 hours discussing
>> this request is unreasonable and the issue is not significant. Thoughts?
>
> An importer who imports data into OSM that doesn't match up with already
> existing data
If people from outside of Canada have decided that our data is so bad that it
needs to be completely wiped out in its entirety, then I guess we're going to
have to do something drastic to try to prevent this.
@Michael, Frederik, Paul: would it be good enough for us to wipe out any and
all
I received the following changeset comment from Nakaner for a Canvec import
(changeset
38158126) at 15:55 Central Time (20:55 UTC):
"This changeset has uploaded data which does not fit to each other. There
is an offset between the water areas and the forest areas. Example:
Hi Sam,
Am 01.09.2016 um 23:06 schrieb Sam Dyck:
> I received the following changeset comment from Nakaner for a Canvec import
> (changeset
> 38158126) at 15:55 Central Time (20:55 UTC):
>
> "This changeset has uploaded data which does not fit to each other. There
> is an offset between the
After reading Paul's email again, its possible that what Nakaner is doing
is in line with Paul's suggestion, if unnecessarily confrontational. I
tried to play around in JOSM to see if I could get the forest polygons to a
point where Nakaner would leave us alone by mercilessly deleting all of the
Hi all,
My colleagues created a set of MapRoulette challenges for Canada
recently, based on various topology checks. A lot of them need work
still, but I was curious about one in particular, the 'Unnamed Roads'.
Example: http://maproulette.org/map/341/363201
Is it possible to fix these without
A correct example link is http://maproulette.org/map/342/362184 rather
than the one in my previous message. Due to a bug in either MapRoulette
or Leaflet you would need to zoom out 1 level to see the map context.
--
Martijn van Exel
m...@rtijn.org
On Thu, Sep 1, 2016, at 16:31, Martijn van
Why and by what authority? We are talking individual imports here by
different people. At least two members of OSMF were and are aware of them
and nothing has been said before. Whose rules are we talking here?
Cheerio John
On 1 September 2016 at 15:42, Michael Reichert
Hi John,
Am 2016-09-01 um 14:47 schrieb john whelan:
> The Canvec data was imported with the knowledge and support of the local
> mappers and I think that's all that matters.
An import of such a size and has to be discussed and approved on an
international level.
Best regards
Michael
--
Per
Canvec data has been imported for many years so why the sudden challenge
and change? Are you willing to reimport the CANVEC data or are you intent
on leaving a blank area in the map?
Cheerio John
On 1 September 2016 at 15:41, Michael Reichert wrote:
> Hi James,
>
> Am
And as someone who has deleted quite a few things in OSM I would agree with
that statement. When I didn't have a better replacement available then I
prefer not to delete unless I have done a ground level inspection and there
really isn't anything there.
I think my favourite was a mapper who was
That is the key here. Deleting information without replacing it with
something more accurate is inherently destructive. There must be some
thought as to what will be put back or one is essentially ripping the map
up simply because you don't like how something looks or how it closely it
follows a
See that's where I have an issue with your revert logic, if errors are
mostly corrected and say theres only 1 or 2 warnings, you want to revert
the whole thing which is very bad for: 1. The community and 2. The
database. Let me explain: there are many hours that go into merging down
CanVec ways
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
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
>I think a super good first step would be try and ensure that future
imports are done diligently and don't introduce new issues.
I think that is a reasonable way forward, and I concur with the rest of
your post.
I think we need to identify which parts of CANVEC are giving concern, each
province
I agree with Frederik here. New imports need to make sure they follow the
import guidelines, including using a dedicated import account.
The wiki information could all be cleaned up, consolidated, and then new
users would know the current status and process for importing new
information.
For
I agree that forest that are way too costly in time should be removed, but
they should also be replaced with something(better) not just mass removed,
oh well we'll get to it later kind of thing
On Sep 1, 2016 8:05 PM, "Sam Dyck" wrote:
> I took a break to make supper, so
I took a break to make supper, so I'm going to have to respond
collectively.
- Sammuell and sammuell_imports are my accounts. Both the forest and the
lake are from Canvec data imported together as in the same tile. I Imported
the whole thing (I would never import over existing data that
Please remove me from this mailing list.
--
***
Matthew Dance
MA Candidate
Department of Earth and
Atmospheric Sciences
University of Alberta
Edmonton, Alberta, T6G 2R6 CANADA
C: 780.554.9222
@mattdance
Andrew,
On 09/02/2016 12:47 AM, Andrew Lester wrote:
> If people from outside of Canada have decided that our data is so bad
> that it needs to be completely wiped out in its entirety, then I guess
> we're going to have to do something drastic to try to prevent this.
I think a super good first
On Thu, Sep 1, 2016 at 11:27 AM, Adam Martin
wrote:
> That is the key here. Deleting information without replacing it with
> something more accurate is inherently destructive. There must be some
> thought as to what will be put back or one is essentially ripping the map
What tells you he didnt prepare batches outside the upload time(offline)?
Your logic is skewed
On Sep 1, 2016 8:39 AM, "Michael Reichert" wrote:
> 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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi,
Am 2016-09-01 um 13:22 schrieb john whelan:
> 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
>
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.
>>
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
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
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
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
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" wrote:
> It would appear that Michael has no appreciation of how
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
On 2016-09-01 09:05 AM, Begin Daniel wrote:
>
> - 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
You are right about Canadian government open data; I was referring at the
Canvec data in OSM format most of us used.
Daniel
-Original Message-
From: Stewart C. Russell [mailto:scr...@gmail.com]
Sent: Thursday, 1 September, 2016 11:53
To: talk-ca@openstreetmap.org
Subject: Re: [Talk-ca]
Regarding the burning of forests, I find the problems with forests tend to
occur when the forests meet up with human activities (communities, gravel
pits, etc.) If I'm importing in an area with some human settlement (and
decent imagery) I will try and clean up the forest and landuse polygons
On 9/1/2016 8:17 AM, Paul Ramsey wrote:
I'm "glad" to see someone else w/ this issue. It's glancingly related
to the canvec import issue, since the land use polygons are a source
of some of the issues the reverter is complaining about (malformed
multipolygons / boundary overlaps).
In my own
On 9/1/2016 1:22 PM, Paul Ramsey wrote:
I'm not sure I agree. "Better than nothing" I guess is the principle,
but when what is there (not nothing) gets in the way of improving
other features, then it's not better than nothing. And what if what's
there is, from an information point of view,
On September 1st, John Whelan wrote:
> 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.
I disagree!
Micheal
Thanks for contacting us. I must object strongly to your use of the Worst
of OSM example and generally assumption that the data is broken if it
doesn't line up. I checked multiple commercial imagery providers before I
found a digitalglobe image that covered the area during the summer.
His goal might be to improve the data quality and that us something I'm in
favour of but the CANVEC data was imported over a long period of time.
Deleting the imported changesets on basically a whim is not improving data
quality.
Yes some of the data could have been better imported, but Canada is
I'm usually just a lurker on these lists but this has dragged me out of my
cave.
Michael,
I'm glad you care about the quality of the map, I do too. I welcome you to
take an constructive approach to working with these problems. Canada has
an area of 9,984,670 square kilometers with a population
Why don't we ... burn down all the forests (and the urban areas too)?
Been in Fort-McMurray lately? (Ok it is a bad joke)
Seriously, these discussions about what should be mapped or not, what is
valuable content or not are raging since the beginning of OSM. More recently,
discussions around the
I like this! The only thing I might change is the bit mentioning the
satellite imagery. I think it also has roots in air photos from the NTS
work.
Cheers!
--G
On Wed, Aug 31, 2016 at 10:24 PM, Sam Dyck wrote:
> Here's my suggestion for a sort of FAQ (in wiki markup),
I agree with you that Michael is forcing us to improve the quality of our data.
However, the way he is doing this also matters. Until we are convinced that he
will not delete what has been done over the years, this thread should keep
running. Then we will able to discuss about improving the
I'm "glad" to see someone else w/ this issue. It's glancingly related to
the canvec import issue, since the land use polygons are a source of some
of the issues the reverter is complaining about (malformed multipolygons /
boundary overlaps).
In my own work in my old home town of Prince George,
because it is a tangible item in the real world, it should be mapped?
OpenStreetMap is not just about roads and navigation, it's an Open GIS
representation of the world around us. People may be using that
information, even if you are not. While we are at it why not just nuke
lakes and rivers as
On Thu, Sep 1, 2016 at 8:49 AM, Begin Daniel wrote:
> What is very cool with OSM is that you can edit the data. Urban polygon is
> wrong? Modify it! The definition is obscure in the Wiki? Change it! But
> yes, the learning curve is often steep, and you may need to discuss
P: OSM is very much an "add only" project, since the social consequences of
incorrectly deleting things seem so high.
What I do perceive in the current thread is that deleting something not perfect
without replacing it with something better hurts, not that it is not acceptable
to delete
51 matches
Mail list logo