Re: [OSM-talk] Could/should editors detect/disallow huge changeset bboxes?
For those interested in knowing what a "typical" bounding box size is, check out my diary entry where I sample changesets over the last 8 years and generate a heatmap of bounding box sizes over time. https://www.openstreetmap.org/user/b-jazz/diary/393858 On Sun, Jun 14, 2020 at 3:21 AM wrote: > On Sat, 13 Jun 2020 21:36:37 +0100, Alan Mackie > wrote: > > >I have no problem with big bounding boxes that result from editing large > >objects. I get annoyed by the ones where somebody added twontiny houses on > >opposite sides of the world. > > And those with a normal work method of editing random items in their > 'home location' and an 'away location' on the other side of the country, > with a comment of 'updating'. > > > ___ > talk mailing list > talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk > ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Could/should editors detect/disallow huge changeset bboxes?
On Sat, 13 Jun 2020 21:36:37 +0100, Alan Mackie wrote: >I have no problem with big bounding boxes that result from editing large >objects. I get annoyed by the ones where somebody added twontiny houses on >opposite sides of the world. And those with a normal work method of editing random items in their 'home location' and an 'away location' on the other side of the country, with a comment of 'updating'. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Could/should editors detect/disallow huge changeset bboxes?
> On Jun 13, 2020, at 3:42 AM, Simon Poole wrote: > > And all this because of a API defect (because there is just one bounding > box per changeset instead of a list)? This hints at a reasonable and not terribly difficult solution, which is for the editor to (optionally and automatically) split a single changeset into a sequence of changesets each with their own bbox. Maybe with an extra changeset tag that ties them together. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Could/should editors detect/disallow huge changeset bboxes?
I have no problem with big bounding boxes that result from editing large objects. I get annoyed by the ones where somebody added twontiny houses on opposite sides of the world. On Sat, 13 Jun 2020, 20:40 Mark Wagner, wrote: > On Sat, 13 Jun 2020 08:03:11 +0200 > Florian Lohoff wrote: > > > On Fri, Jun 12, 2020 at 11:19:46AM -0400, James wrote: > > > No they shouldn't, mapping roads in northern Canada, your bbox can > > > become quite large quickly as mapping logging roads/dirt roads is > > > quick and easy, but span over multiple kms > > > > The point is that the line/way of that road should also not span tens > > of kms. You should break that up every couple of kilometers. > > > > Otherwise this is prone to break one day or the other. And its simply > > inefficient. Every time you touch that road you invalidate hundrets > > of tiles. > > Come out to the rural United States sometime. It's not unreasonable > for a road to span tens of kilometers between intersections. > > (And a one-square-kilometer limit on landuse is also unreasonable: the > most common farm shape is a circle one mile in diameter. The > second-most-common is a square one mile on a side.) > > -- > Mark > > ___ > talk mailing list > talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk > ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Could/should editors detect/disallow huge changeset bboxes?
On Sat, 13 Jun 2020 08:03:11 +0200 Florian Lohoff wrote: > On Fri, Jun 12, 2020 at 11:19:46AM -0400, James wrote: > > No they shouldn't, mapping roads in northern Canada, your bbox can > > become quite large quickly as mapping logging roads/dirt roads is > > quick and easy, but span over multiple kms > > The point is that the line/way of that road should also not span tens > of kms. You should break that up every couple of kilometers. > > Otherwise this is prone to break one day or the other. And its simply > inefficient. Every time you touch that road you invalidate hundrets > of tiles. Come out to the rural United States sometime. It's not unreasonable for a road to span tens of kilometers between intersections. (And a one-square-kilometer limit on landuse is also unreasonable: the most common farm shape is a circle one mile in diameter. The second-most-common is a square one mile on a side.) -- Mark ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Could/should editors detect/disallow huge changeset bboxes?
is it just rivers or would that included polygons, river banks, area ? Saturday, June 13, 2020 11:44 AM -05:00 from Joseph Eisenberg : I mostly have mapped in parts of Indonesia where there was no data, and the new road or river was mapped for the first time. Usually I try to split roads and rivers every ~10 kilometers. - Joseph Eisenberg On Sat, Jun 13, 2020 at 8:46 AM Mateusz Konieczny via talk < talk@openstreetmap.org > wrote: > > > >Jun 13, 2020, 08:03 by f...@zz.de : >>On Fri, Jun 12, 2020 at 11:19:46AM -0400, James wrote: >>>No they shouldn't, mapping roads in northern Canada, your bbox can become >>>quite large quickly as mapping logging roads/dirt roads is quick and easy, >>>but span over multiple kms >> >>The point is that the line/way of that road should also not span tens of >>kms. You should break that up every couple of kilometers. >Not alway, there are reasonable cases for mapping long roads without such >splits. > >In many poorly mapped places you can still map 100km of road/river >in one go, without need for splitting it. > ___ >talk mailing list >talk@openstreetmap.org >https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Could/should editors detect/disallow huge changeset bboxes?
>i did that it was 10 feet than someone says it can not be 10 feet a mile or so >down the road and he is right > >so i changed it but it was 10 feet where i was. > >>Saturday, June 13, 2020 11:44 AM -05:00 from Joseph Eisenberg < >>joseph.eisenb...@gmail.com >: >> >>I mostly have mapped in parts of Indonesia where there was no data, and the >>new road or river was mapped for the first time. >> >>Usually I try to split roads and rivers every ~10 kilometers. >> >>- Joseph Eisenberg >> >>On Sat, Jun 13, 2020 at 8:46 AM Mateusz Konieczny via talk < >>talk@openstreetmap.org > wrote: >>> >>> >>> >>>Jun 13, 2020, 08:03 by f...@zz.de : On Fri, Jun 12, 2020 at 11:19:46AM -0400, James wrote: >No they shouldn't, mapping roads in northern Canada, your bbox can become >quite large quickly as mapping logging roads/dirt roads is quick and easy, >but span over multiple kms The point is that the line/way of that road should also not span tens of kms. You should break that up every couple of kilometers. >>>Not alway, there are reasonable cases for mapping long roads without such >>>splits. >>> >>>In many poorly mapped places you can still map 100km of road/river >>>in one go, without need for splitting it. >>> ___ >>>talk mailing list >>>talk@openstreetmap.org >>>https://lists.openstreetmap.org/listinfo/talk >>___ >>talk mailing list >>talk@openstreetmap.org >>https://lists.openstreetmap.org/listinfo/talk > > > > ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Could/should editors detect/disallow huge changeset bboxes?
I mostly have mapped in parts of Indonesia where there was no data, and the new road or river was mapped for the first time. Usually I try to split roads and rivers every ~10 kilometers. - Joseph Eisenberg On Sat, Jun 13, 2020 at 8:46 AM Mateusz Konieczny via talk < talk@openstreetmap.org> wrote: > > > > Jun 13, 2020, 08:03 by f...@zz.de: > > On Fri, Jun 12, 2020 at 11:19:46AM -0400, James wrote: > > No they shouldn't, mapping roads in northern Canada, your bbox can become > quite large quickly as mapping logging roads/dirt roads is quick and easy, > but span over multiple kms > > > The point is that the line/way of that road should also not span tens of > kms. You should break that up every couple of kilometers. > > Not alway, there are reasonable cases for mapping long roads without such > splits. > > In many poorly mapped places you can still map 100km of road/river > in one go, without need for splitting it. > > ___ > talk mailing list > talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk > ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Could/should editors detect/disallow huge changeset bboxes?
Jun 13, 2020, 08:03 by f...@zz.de: > On Fri, Jun 12, 2020 at 11:19:46AM -0400, James wrote: > >> No they shouldn't, mapping roads in northern Canada, your bbox can become >> quite large quickly as mapping logging roads/dirt roads is quick and easy, >> but span over multiple kms >> > > The point is that the line/way of that road should also not span tens of > kms. You should break that up every couple of kilometers. > Not alway, there are reasonable cases for mapping long roads without such splits. In many poorly mapped places you can still map 100km of road/river in one go, without need for splitting it. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Could/should editors detect/disallow huge changeset bboxes?
Splitting changesets does sound like a lot of work if you don't already have for example the multi layer tools that JOSM has. Would a warning that "you already have pending edits ___ km away, please consider saving or discarding those before editing here" be useful in the interim? I think this would "only" need the software to keep track of the bounding box for current edits and notifying users if the closest point of the current edits is out of view by quite some distance. This avoids the need to split pending edits into multiple changesets because the prompt is shown before work on the second region starts. On Sat, 13 Jun 2020, 11:43 Simon Poole, wrote: > I've advocated for this in the past, but getting this right from a > business logic pov is fairly tricky and is yet another thing that an > editor needs to keep track of when creating and modify geometries, and > changing tags. From the top my head at least: new object creation, > dragging nodes and ways, merging and splitting ways, adding and removing > relation members, copy, cut and paste, all tag changes. While each of > these might be minor things, all together they have a clear performance > and complexity impact and require UI additions to handle. This is > assuming that such a bounding box limit would not be enforced by the > API, if enforced you actively have to not allow the user to make the > change which is even more painful. > > If the limit is enforced there are all kinds of vandalism/DoS scenarios > that would probably require lifting the restriction for admins/mods. > > And all this because of a API defect (because there is just one bounding > box per changeset instead of a list)? > > Simon > > Am 12.06.2020 um 13:00 schrieb Frederik Ramm: > > Hi, > > > > I wonder if it would be feasible or desirable for editors to warn users > > if they are at risk of creating country/world-spanning changesets. > > Something like "you have unsaved edits more than 500km away from where > > you are editing at the moment, please upload those before you continue" > > or so. > > > > World-spanning changesets are a constant source of irritation, and very > > rarely intentional. > > > > Bye > > Frederik > > > > ___ > talk mailing list > talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk > ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Could/should editors detect/disallow huge changeset bboxes?
I've advocated for this in the past, but getting this right from a business logic pov is fairly tricky and is yet another thing that an editor needs to keep track of when creating and modify geometries, and changing tags. From the top my head at least: new object creation, dragging nodes and ways, merging and splitting ways, adding and removing relation members, copy, cut and paste, all tag changes. While each of these might be minor things, all together they have a clear performance and complexity impact and require UI additions to handle. This is assuming that such a bounding box limit would not be enforced by the API, if enforced you actively have to not allow the user to make the change which is even more painful. If the limit is enforced there are all kinds of vandalism/DoS scenarios that would probably require lifting the restriction for admins/mods. And all this because of a API defect (because there is just one bounding box per changeset instead of a list)? Simon Am 12.06.2020 um 13:00 schrieb Frederik Ramm: > Hi, > > I wonder if it would be feasible or desirable for editors to warn users > if they are at risk of creating country/world-spanning changesets. > Something like "you have unsaved edits more than 500km away from where > you are editing at the moment, please upload those before you continue" > or so. > > World-spanning changesets are a constant source of irritation, and very > rarely intentional. > > Bye > Frederik > signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Could/should editors detect/disallow huge changeset bboxes?
The issue is actually still open in ID https://github.com/openstreetmap/iD/issues/5424 and references the more recent request https://github.com/openstreetmap/iD/issues/7434 From: Alan Mackie Sent: Saturday, 13 June 2020 2:26 AM To: Paul Johnson Cc: Talk Openstreetmap Subject: Re: [OSM-talk] Could/should editors detect/disallow huge changeset bboxes? On Fri, 12 Jun 2020 at 16:45, Paul Johnson mailto:ba...@ursamundi.org> > wrote: This isn't unique to JOSM, though. This is easily doable with iD as well (as evidenced by watching OSMCha with a bbox edged on Oklahoma's maximum extents, Amazon Logistics does this a good 3-4 times a day every day with changesets spanning the continent). And I've done it in Vespucci by accident. I get notifications because of this sort of behaviour fairly frequently. I think iD and Maps.me are by far the most frequent "offenders", followed swiftly by wheelmap.org <http://wheelmap.org> , but I haven't kept a proper count. In JOSM a better way to select deleted objects (formerly) within a given area would be nice, but is it generally less prone to this anyway as new sessions tend to start as new layers. Manual download for new areas can serve as a reminder that this isn't "live" too. There have been requests for iD to warn users if they have unsaved edits far away before they start editing a new area, but so far these issues have been closed once it is mentioned that other software also does this on occasion. See for example this issue: https://github.com/openstreetmap/iD/issues/7434 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Could/should editors detect/disallow huge changeset bboxes?
On Fri, Jun 12, 2020 at 11:19:46AM -0400, James wrote: > No they shouldn't, mapping roads in northern Canada, your bbox can become > quite large quickly as mapping logging roads/dirt roads is quick and easy, > but span over multiple kms The point is that the line/way of that road should also not span tens of kms. You should break that up every couple of kilometers. Otherwise this is prone to break one day or the other. And its simply inefficient. Every time you touch that road you invalidate hundrets of tiles. When i load some area in josm and there is an object which spans multiple times of my edit area i typically split it down. Be it roads or waterways. And there are few tags which REALLY span that long objects. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Could/should editors detect/disallow huge changeset bboxes?
>I understand fred, how do you know the date of the satelite view, in pre-fab a >building can go up > >in a day. >>Friday, June 12, 2020 7:24 PM -05:00 from Dave F via talk < >>talk@openstreetmap.org >: >> >>On 12/06/2020 15:32, 80hnhtv4agou--- via talk wrote: >>> I am confused, >>> are you telling me being in chicago, where i can go to the place i am >>> editing, not relying on satellite view >>> which is behind by at least 7 month or more here, i should be messing >>> around in London. >>If you have information which you think is substantive enough & improves >>the quality of the OSM database, then why not? >> >>Frederik's claim OSM is restricted to "local knowledge" is false, & >>frankly I'm surprised he claimed it. >> >> > > > > ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Could/should editors detect/disallow huge changeset bboxes?
On 12/06/2020 15:32, 80hnhtv4agou--- via talk wrote: I am confused, are you telling me being in chicago, where i can go to the place i am editing, not relying on satellite view which is behind by at least 7 month or more here, i should be messing around in London. If you have information which you think is substantive enough & improves the quality of the OSM database, then why not? Frederik's claim OSM is restricted to "local knowledge" is false, & frankly I'm surprised he claimed it. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Could/should editors detect/disallow huge changeset bboxes?
On 12/06/2020 23:00, 80hnhtv4agou--- via talk wrote: Friday, June 12, 2020 10:20 AM -05:00 from James : No they shouldn't, mapping roads in northern Canada, your bbox can become quite large quickly as mapping logging roads/dirt roads is quick and easy, but span over multiple kms If the satellite view (imagery) in my local area is 7 mouths old +, why would anybody want me to edit in theirs backyard ? If *you* think the source data isn't accurate enough, then *you* should decide not use that data. DaveF ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Could/should editors detect/disallow huge changeset bboxes?
On 12/6/20 9:19 pm, Colin Smale wrote: On 2020-06-12 13:00, Frederik Ramm wrote: Hi, I wonder if it would be feasible or desirable for editors to warn users if they are at risk of creating country/world-spanning changesets. Something like "you have unsaved edits more than 500km away from where you are editing at the moment, please upload those before you continue" or so. World-spanning changesets are a constant source of irritation, and very rarely intentional. But sometimes they are intentional, so they should not be prevented entirely, but possibly just challenged. Admin boundaries may need to be exempted? I am not sure how the bounding box for the changeset is calculated at present, but for these purposes it should possibly be limited to the nodes that have changed, and not automatically expanded to the entire way or relation that the change impacts. Moving one node on a country boundary should not classify the changeset as covering the whole country. Moving that node may be intentional for a change on a feature that is not part of a admin boundary, never the less that node is part of the admin boundary and moving it may cause an error on the admin boundary. The similar for routes and possibly other large features. I am all for a warning. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Could/should editors detect/disallow huge changeset bboxes?
>Friday, June 12, 2020 10:20 AM -05:00 from James : > >No they shouldn't, mapping roads in northern Canada, your bbox can become >quite large quickly as mapping logging roads/dirt roads is quick and easy, but >span over multiple kms If the satellite view ( imagery) in my local area is 7 mouths old +, why would anybody want me to edit in theirs backyard ? On 12/06/2020 15:32, 80hnhtv4agou--- via talk wrote:> I am confused > >>> are you telling me being in chicago, where i can go to the place i am> >>> editing, not relying on satellite view >>> which is behind by at least 7 month or more here, i should be messing >>> around in London. >> On Fri., Jun. 12, 2020, 11:10 a.m. ndrw, < nd...@redhazel.co.uk > wrote: >>Yes, you can map anywhere you want. There are no rules forbidding that, >>and there are projects like HOT that are mostly based on armchair mapping. >> >>Like with any edits, start with low risk/high impact changes (e.g. >>adding contents to poorly mapped areas), map only what you can see in >>the imagery, follow local conventions and listen to more experienced >>mappers. >> >>More guidelines: https://wiki.openstreetmap.org/wiki/Armchair_mapping >> >>Ndrw >> >> >> ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Could/should editors detect/disallow huge changeset bboxes?
On Fri, 12 Jun 2020 at 18:27, Mateusz Konieczny via talk < talk@openstreetmap.org> wrote: > > > > Jun 12, 2020, 18:26 by aamac...@gmail.com: > > There have been requests for iD to warn users if they have unsaved edits > far away before they start editing a new area, but so far these issues have > been closed once it is mentioned that other software also does this on > occasion. See for example this issue: > > https://github.com/openstreetmap/iD/issues/7434 > > The iD plan is to do https://github.com/openstreetmap/iD/issues/5424 what > sounds OK. > > Issue that you linked was closed as duplicate > > "so far these issues have been closed once it is mentioned that other > software also does this on occasion" > is untrue, see > https://github.com/openstreetmap/iD/issues/7434#issuecomment-608046607 > in issue that you linked with actual close reason > > I did not see that in the final paragraph there. I stand corrected. I thought #5424 had been kicked way down the road as it involves a lot of work and isn't really suited to incremental improvements. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Could/should editors detect/disallow huge changeset bboxes?
Jun 12, 2020, 18:26 by aamac...@gmail.com: > There have been requests for iD to warn users if they have unsaved edits far > away before they start editing a new area, but so far these issues have been > closed once it is mentioned that other software also does this on occasion. > See for example this issue: > > https://github.com/openstreetmap/iD/issues/7434 > > The iD plan is to do https://github.com/openstreetmap/iD/issues/5424 what sounds OK. Issue that you linked was closed as duplicate "so far these issues have been closed once it is mentioned that other software also does this on occasion" is untrue, see https://github.com/openstreetmap/iD/issues/7434#issuecomment-608046607 in issue that you linked with actual close reason ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Could/should editors detect/disallow huge changeset bboxes?
On Fri, 12 Jun 2020 at 16:45, Paul Johnson wrote: > > > This isn't unique to JOSM, though. This is *easily* doable with iD as > well (as evidenced by watching OSMCha with a bbox edged on Oklahoma's > maximum extents, Amazon Logistics does this a good 3-4 times a day every > day with changesets spanning the continent). And I've done it in Vespucci > by accident. > > I get notifications because of this sort of behaviour fairly frequently. I think iD and Maps.me are by far the most frequent "offenders", followed swiftly by wheelmap.org, but I haven't kept a proper count. In JOSM a better way to select deleted objects (formerly) within a given area would be nice, but is it generally less prone to this anyway as new sessions tend to start as new layers. Manual download for new areas can serve as a reminder that this isn't "live" too. There have been requests for iD to warn users if they have unsaved edits far away before they start editing a new area, but so far these issues have been closed once it is mentioned that other software also does this on occasion. See for example this issue: https://github.com/openstreetmap/iD/issues/7434 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Could/should editors detect/disallow huge changeset bboxes?
On Fri, Jun 12, 2020 at 10:31 AM Florian Lohoff wrote: > On Fri, Jun 12, 2020 at 03:45:17PM +0200, Frederik Ramm wrote: > > Hi, > > > > On 12.06.20 15:22, Dave F via talk wrote: > > > There is a lot of negativity about large changsets, but assessment of > > > them should be based on quality, not quantity. > > > > Yes, we're not discussing a popup that says "You dumbass, why did you > > create a world-spanning changeset?" ;) > > > > The way in which editors deal with that would likely differ; in JOSM it > > might be a popup that says "are you sure?" and in ID it might be a > > floating warning somewhere. > > I'd rather let josm not download additional data in some distant > spot as long as you have unpushed changes. > There's some legitimate edge cases for doing this, but I'd say slightly more often than not when I do this, it's because I was on the wrong layer and didn't expect to. A warning that you're not on the layer you think you are if there's another data layer that's closer that isn't the active layer would help. This isn't unique to JOSM, though. This is *easily* doable with iD as well (as evidenced by watching OSMCha with a bbox edged on Oklahoma's maximum extents, Amazon Logistics does this a good 3-4 times a day every day with changesets spanning the continent). And I've done it in Vespucci by accident. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Could/should editors detect/disallow huge changeset bboxes?
On Fri, Jun 12, 2020 at 03:45:17PM +0200, Frederik Ramm wrote: > Hi, > > On 12.06.20 15:22, Dave F via talk wrote: > > There is a lot of negativity about large changsets, but assessment of > > them should be based on quality, not quantity. > > Yes, we're not discussing a popup that says "You dumbass, why did you > create a world-spanning changeset?" ;) > > The way in which editors deal with that would likely differ; in JOSM it > might be a popup that says "are you sure?" and in ID it might be a > floating warning somewhere. I'd rather let josm not download additional data in some distant spot as long as you have unpushed changes. Same could be with id - dont let user pan/zoom aways to distant spots without first pushing their changes. By this you actually force the use to split their changes spatially. It will still let you edit big objects as you loaded them in the first place. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Could/should editors detect/disallow huge changeset bboxes?
On Fri, Jun 12, 2020 at 02:14:15PM +0200, Mateusz Konieczny via talk wrote: > > > > Jun 12, 2020, 13:59 by f...@zz.de: > > > Changeset envelopes which span more than 100s of km² are broken. > > > Except cases where you edit/delete already created huge objects or you create > huge object that actually should be created. > These types of objects should be pretty exceptional. I try to split landuses to sub 1km² because i also feel the pain for rendering tiles. As soon as someone touches those areas you invalidate tons of tiles. So breaking this down also benefits us long term concerning workload on the tile servers. Main reason is still maintainability though. As soon as an object is not in the Mappers complete view things tend to break. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Could/should editors detect/disallow huge changeset bboxes?
No they shouldn't, mapping roads in northern Canada, your bbox can become quite large quickly as mapping logging roads/dirt roads is quick and easy, but span over multiple kms On Fri., Jun. 12, 2020, 11:10 a.m. ndrw, wrote: > On 12/06/2020 15:32, 80hnhtv4agou--- via talk wrote: > > I am confused, > > are you telling me being in chicago, where i can go to the place i am > > editing, not relying on satellite view > > which is behind by at least 7 month or more here, i should be messing > > around in London. > > > Yes, you can map anywhere you want. There are no rules forbidding that, > and there are projects like HOT that are mostly based on armchair mapping. > > Like with any edits, start with low risk/high impact changes (e.g. > adding contents to poorly mapped areas), map only what you can see in > the imagery, follow local conventions and listen to more experienced > mappers. > > More guidelines: https://wiki.openstreetmap.org/wiki/Armchair_mapping > > Ndrw > > > > ___ > talk mailing list > talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk > ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Could/should editors detect/disallow huge changeset bboxes?
On 12/06/2020 13:35, Tobias Knerr wrote: On 12.06.20 13:00, Frederik Ramm wrote: I wonder if it would be feasible or desirable for editors to warn users if they are at risk of creating country/world-spanning changesets. It would certainly be a improvement for day-to-day work. The root of the issue, though, is that bounding boxes are a poor basis to determine whether a changeset is of interest to a mapper watching a particular region. If a changeset contains a change in France and one in Poland, then a mapper observing Germany should really just not be alerted to that changeset in the first place, and it should be possible for a mapper in Poland to view only the subset of the changes that affect their own country. I think the issue is with the cost of querying bboxes of all changed objects vs bbox of the changeset. I don't know how expensive it is to query all objects, though. Perhaps we could keep using the changeset bbox for large changesets (e.g. >100 modified objects) and query all individual objects for smaller changesets? The issue is mostly with the history browser on osm.org, as it is not particularly good tool for checking what has been changed, but that's what most people see first before examining the changeset in osmcha or similar tools. Ndrw ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Could/should editors detect/disallow huge changeset bboxes?
On 12/06/2020 15:32, 80hnhtv4agou--- via talk wrote: I am confused, are you telling me being in chicago, where i can go to the place i am editing, not relying on satellite view which is behind by at least 7 month or more here, i should be messing around in London. Yes, you can map anywhere you want. There are no rules forbidding that, and there are projects like HOT that are mostly based on armchair mapping. Like with any edits, start with low risk/high impact changes (e.g. adding contents to poorly mapped areas), map only what you can see in the imagery, follow local conventions and listen to more experienced mappers. More guidelines: https://wiki.openstreetmap.org/wiki/Armchair_mapping Ndrw ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Could/should editors detect/disallow huge changeset bboxes?
I am confused,
are you telling me being in chicago, where i can go to the place i am editing,
not relying on satellite view
which is behind by at least 7 month or more here, i should be messing around in
London.
>Friday, June 12, 2020 9:26 AM -05:00 from Dave F via talk
>:
>
>On 12/06/2020 14:44, Frederik Ramm wrote:
>> Hi,
>>
>> On 12.06.20 15:22, Dave F via talk wrote:
>>> There is a lot of negativity about large changsets, but assessment of
>>> them should be based on quality, not quantity.
>> Yes, we're not discussing a popup that says "You dumbass, why did you
>> create a world-spanning changeset?" ;)
>
>I'm not convinced that's true. Already in this thread someone is blaming
>large changesets purely because the verifying software they're using
>isn't capable of dealing with them. Judge on quality not quantity.
>
>> The way in which editors deal with that would likely differ; in JOSM it
>> might be a popup that says "are you sure?" and in ID it might be a
>> floating warning somewhere.
>>
>> Your example of a world-wide spelling fix as an acceptable edit does not
>> agree with me; these edits often have unwanted side effects. See
>> https://wiki.openstreetmap.org ("if someone has described a 'horse' as a
>> 'kow' correcting the spelling to 'cow' does not make the description
>> correct").
>
>Tenuous & assumptive.
>It was just one "example".
>
>> OSM is a project of local knowlege.
>
>Just because you believe that, it doesn't make it so.
>Knowledge which effects OSM comes from many sources:
>A walk though town where a new shop has opened, or BBC world news which
>reports how a Far Eastern bridge building project has been cancelled &
>the proposed data requires removing.
>
>> World-spanning changesets compatible
>> with that idea are not impossible but rare; and erroneous or even
>> rule-violating changesets
>
>These rules require amending as they're based purely on size & the
>criticism is usually in the form of " "You dumbass, why did you create a
>world-spanning changeset?". Judge on quality not quantity.
>
>> are much more frequent among world-spanning
>> changesets than among everyday small bbox changesets.
>I'm not convinced. This perception only occurs because changesets over
>large areas stand out.
>
>Cheers
>DaveF
>
>___
>talk mailing list
>talk@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Could/should editors detect/disallow huge changeset bboxes?
On 12/06/2020 14:44, Frederik Ramm wrote:
Hi,
On 12.06.20 15:22, Dave F via talk wrote:
There is a lot of negativity about large changsets, but assessment of
them should be based on quality, not quantity.
Yes, we're not discussing a popup that says "You dumbass, why did you
create a world-spanning changeset?" ;)
I'm not convinced that's true. Already in this thread someone is blaming
large changesets purely because the verifying software they're using
isn't capable of dealing with them. Judge on quality not quantity.
The way in which editors deal with that would likely differ; in JOSM it
might be a popup that says "are you sure?" and in ID it might be a
floating warning somewhere.
Your example of a world-wide spelling fix as an acceptable edit does not
agree with me; these edits often have unwanted side effects. See
https://wiki.openstreetmap.org ("if someone has described a 'horse' as a
'kow' correcting the spelling to 'cow' does not make the description
correct").
Tenuous & assumptive.
It was just one "example".
OSM is a project of local knowlege.
Just because you believe that, it doesn't make it so.
Knowledge which effects OSM comes from many sources:
A walk though town where a new shop has opened, or BBC world news which
reports how a Far Eastern bridge building project has been cancelled &
the proposed data requires removing.
World-spanning changesets compatible
with that idea are not impossible but rare; and erroneous or even
rule-violating changesets
These rules require amending as they're based purely on size & the
criticism is usually in the form of " "You dumbass, why did you create a
world-spanning changeset?". Judge on quality not quantity.
are much more frequent among world-spanning
changesets than among everyday small bbox changesets.
I'm not convinced. This perception only occurs because changesets over
large areas stand out.
Cheers
DaveF
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Could/should editors detect/disallow huge changeset bboxes?
On Fri, Jun 12, 2020 at 6:07 AM Frederik Ramm wrote: > I wonder if it would be feasible or desirable for editors to warn users > if they are at risk of creating country/world-spanning changesets. > Something like "you have unsaved edits more than 500km away from where > you are editing at the moment, please upload those before you continue" > or so. > I don't see why it would be unfeasible. I do see it being desirable. Maybe dial it back to about 50km though, changesets spanning more than 3 or 4 kilometers without having a fairly tight and obvious scope are a pain to QA. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Could/should editors detect/disallow huge changeset bboxes?
Yes please - I am using Osmcha to look at changesets around me and i have a high number of changesets which span half Europe and thus intersect with the area i am looking at. Changeset envelopes which span more than 100s of km² are broken. In which case, isn't it really OSMCha which is 'broken'? Maybe there's a way to split the dataset into smaller chunks & load in series. DaveF ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Could/should editors detect/disallow huge changeset bboxes?
Hi,
On 12.06.20 15:22, Dave F via talk wrote:
> There is a lot of negativity about large changsets, but assessment of
> them should be based on quality, not quantity.
Yes, we're not discussing a popup that says "You dumbass, why did you
create a world-spanning changeset?" ;)
The way in which editors deal with that would likely differ; in JOSM it
might be a popup that says "are you sure?" and in ID it might be a
floating warning somewhere.
Your example of a world-wide spelling fix as an acceptable edit does not
agree with me; these edits often have unwanted side effects. See
https://wiki.openstreetmap.org ("if someone has described a 'horse' as a
'kow' correcting the spelling to 'cow' does not make the description
correct").
OSM is a project of local knowlege. World-spanning changesets compatible
with that idea are not impossible but rare; and erroneous or even
rule-violating changesets are much more frequent among world-spanning
changesets than among everyday small bbox changesets.
Bye
Frederik
--
Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33"
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Could/should editors detect/disallow huge changeset bboxes?
> Yes please - I am using Osmcha to look at changesets around me and i have a high number of changesets which span half Europe and thus intersect with the area i am looking at. Side note to this discussion — in OSMCha you can filter out these wide spanning changesets with “Bbox size bound” filter. If a changeset is larger than the bbox filter area multiplied by this value, it’s filtered out. That doesn’t help if features in large changesets are actually in your area of interest. Would definitely be better if these unintentional large changesets were reduced at the source. Mikel ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Could/should editors detect/disallow huge changeset bboxes?
On 12/06/2020 12:00, Frederik Ramm wrote: and very rarely intentional. Point 1: This is what's always confused me. I occasionally look into world wide changeset & it's often one spurious object in another continent, which the contributor can't explain. I'm unsure if it's one specific editor . It takes a concerted effort to pan across the globe & load extra data P2 makes it virtually impossible Could there be a glitch in the software which augments the changeset with the rest of the database? Point 2: There needs to be a distinction in the types of large area changesets. 1. Where a contributor pans & loads to make random edits on multiple items. This should be discouraged. 2. Global edits to amend one specific item on multiple entities (a spelling correction, for instance). As long as the changeset comment clearly explains the purpose, this is acceptable as it improves the quality of the database. There is a lot of negativity about large changsets, but assessment of them should be based on quality, not quantity. DaveF ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Could/should editors detect/disallow huge changeset bboxes?
Le 12 juin 2020 14:14:15 GMT+02:00, Mateusz Konieczny via talk a écrit : > > > >Jun 12, 2020, 13:59 by f...@zz.de: > >> Changeset envelopes which span more than 100s of km² are broken. >> >Except cases where you edit/delete already created huge objects or you >create >huge object that actually should be created. The time to acknowledge the warning is small compared to the potential harm, so I guess you would not really bother. Yves ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Could/should editors detect/disallow huge changeset bboxes?
On 12.06.20 13:00, Frederik Ramm wrote: > I wonder if it would be feasible or desirable for editors to warn users > if they are at risk of creating country/world-spanning changesets. It would certainly be a improvement for day-to-day work. The root of the issue, though, is that bounding boxes are a poor basis to determine whether a changeset is of interest to a mapper watching a particular region. If a changeset contains a change in France and one in Poland, then a mapper observing Germany should really just not be alerted to that changeset in the first place, and it should be possible for a mapper in Poland to view only the subset of the changes that affect their own country. IMO, an ideal changeset represents one logical unit of work. It shouldn't contain multiple unrelated changes, but at the same time, related changes should not be split across different changesets. Right now we're intentionally doing the latter to work around the limitations in our tools, and I understand and support that, but I hope this view of "large bbox = bad" doesn't get too firmly entrenched. Let's keep in mind that it's essentially a workaround for missing software features, that the proper fix is to improve the software, and that we should drop this rule once the reasons for it no longer exist. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Could/should editors detect/disallow huge changeset bboxes?
Le 12.06.20 à 13:00, Frederik Ramm a écrit : > desirable imho yes, including offline editor like maps.me, when a contributor edit one object at the airport of departure and another at the airport of arrival, both in the same changeset. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Could/should editors detect/disallow huge changeset bboxes?
Jun 12, 2020, 13:59 by f...@zz.de: > Changeset envelopes which span more than 100s of km² are broken. > Except cases where you edit/delete already created huge objects or you create huge object that actually should be created. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Could/should editors detect/disallow huge changeset bboxes?
Hi, showing a warning for huge bboxes is a great idea. I can also imagine to extends this idea to the number of changes. So also showing a warning when there are more than a specific amount of added/changed/deleted nodes or something. I had the situation that I accidentally uploaded a huge bunch of stuff because I clicked the wrong button (in JOSM the "upload data" and "upload selection" button are right next to each other ...). Hauke On 12.06.20 13:00, Frederik Ramm wrote: > Hi, > > I wonder if it would be feasible or desirable for editors to warn users > if they are at risk of creating country/world-spanning changesets. > Something like "you have unsaved edits more than 500km away from where > you are editing at the moment, please upload those before you continue" > or so. > > World-spanning changesets are a constant source of irritation, and very > rarely intentional. > > Bye > Frederik > signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Could/should editors detect/disallow huge changeset bboxes?
On Fri, Jun 12, 2020 at 01:00:56PM +0200, Frederik Ramm wrote: > Hi, > > I wonder if it would be feasible or desirable for editors to warn users > if they are at risk of creating country/world-spanning changesets. > Something like "you have unsaved edits more than 500km away from where > you are editing at the moment, please upload those before you continue" > or so. > > World-spanning changesets are a constant source of irritation, and very > rarely intentional. Yes please - I am using Osmcha to look at changesets around me and i have a high number of changesets which span half Europe and thus intersect with the area i am looking at. Changeset envelopes which span more than 100s of km² are broken. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Could/should editors detect/disallow huge changeset bboxes?
Jun 12, 2020, 13:00 by frede...@remote.org: > Hi, > > I wonder if it would be feasible or desirable for editors to warn users > if they are at risk of creating country/world-spanning changesets. > Something like "you have unsaved edits more than 500km away from where > you are editing at the moment, please upload those before you continue" > or so. > > World-spanning changesets are a constant source of irritation, and very > rarely intentional. > It is both feasible and desirable. For bonus points do not ask when one of already existing edited elements is extremely large (if one edits/deletes continent-sized element then large bbox is unavoidable). But I think that it is topic that should be discussed/reported on bug trackers of editors first, it seems a more efficient method to achieve improvements (avoidable world-spanning bboxes are known to be undesirable, I think that confirmation for that is not necessary). ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Could/should editors detect/disallow huge changeset bboxes?
On 2020-06-12 13:00, Frederik Ramm wrote: > Hi, > > I wonder if it would be feasible or desirable for editors to warn users > if they are at risk of creating country/world-spanning changesets. > Something like "you have unsaved edits more than 500km away from where > you are editing at the moment, please upload those before you continue" > or so. > > World-spanning changesets are a constant source of irritation, and very > rarely intentional. But sometimes they are intentional, so they should not be prevented entirely, but possibly just challenged. Admin boundaries may need to be exempted? I am not sure how the bounding box for the changeset is calculated at present, but for these purposes it should possibly be limited to the nodes that have changed, and not automatically expanded to the entire way or relation that the change impacts. Moving one node on a country boundary should not classify the changeset as covering the whole country. There are probably farms in Texas bigger than Luxembourg... Where do you draw the line?___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Could/should editors detect/disallow huge changeset bboxes?
Hi, I wonder if it would be feasible or desirable for editors to warn users if they are at risk of creating country/world-spanning changesets. Something like "you have unsaved edits more than 500km away from where you are editing at the moment, please upload those before you continue" or so. World-spanning changesets are a constant source of irritation, and very rarely intentional. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
