Changeset: 114157461
corrections tags railway:lzb, railway:pzb inadaptés/superflus en France
Closed by Denis_Helfer
Tags
created_by | JOSM/1.5 (18303 fr) |
---|---|
source | corrections/amélioration |
Discussion
-
Comment from Lee Carré
Smaller changeset areas, please: http://wiki.osm.org/wiki/Changeset#Geographical_size_of_changesets
-
Comment from Denis_Helfer
can't
-
Comment from Lee Carré
Sure you can.
Why do you feel that you can't?
-
Comment from StC
There are two conflicting guidelines here: the one you refer to, and the universal principle that changesets must be consistent (e.g. if you need to revert them).
It is unfortunate that Jersey is included in any bounding box that includes, say, Saint-Malo and Carentan. Do you imagine the number of changesets that would require to avoid that, for a single change in the French rail network?
We have started to discuss solutions such as including #France in large changesets, so as to facilitate automated filtering in your monitoring tools. Would that be an agreeable way forward to you?
-
Comment from Lee Carré
Firstly, thankyou for being constructive, considerate, & solution-focused about this. Unfortunately a lot of other mappers are not, and just dismiss the problem.
“There are two conflicting guidelines here: the one you refer to, and the universal principle that changesets must be consistent (e.g. if you need to revert them).”
I'm unsure of the guideline to which you refer. Would you cite the relevant documentation, please.
I ask not because I doubt the claim, but that I simply want to read more.“It is unfortunate that Jersey is included in any bounding box that includes, say, Saint-Malo and Carentan. Do you imagine the number of changesets that would require to avoid that, for a single change in the French rail network?”
I sympathise.
While more sets would be needed, I don't see that it would have to be many. A central France-only set, then a wide-short one (landscape orientation) to cover St. Malo, Brest, etc. A portrait one to cover the Thumb of France peninsula (since it shouldn't matter about extending out into the sea; perhaps except for those mapping seamarks).
I'm amused by the thought that this would all be so much simpler if the Channel Islands were still French territory.
There are open bug reports re tools handling large bboxes in less simplistic ways. I gather that it's a difficult problem to overcome (perhaps because of all the extra processing it would require).
“We have started to discuss solutions such as including #France in large changesets, so as to facilitate automated filtering in your monitoring tools. Would that be an agreeable way forward to you?”
I greatly appreciate this effort.
Something like tagging the changesets with such a clear hashtag would, I think, work elegantly under the circumstances.
For context; I do surveying via a nano-computer, thus use OSMCha for filtering. Though, if I recall, it handles hashtags. I'll need to check if it's able to apply a negative filter on them, though. For some things it can't; only an inclusive filter (editor string is one parameter which has this problem).
However, even if it can't, yet, then a real-world application makes for a stronger case to have the feature added. Plus, other filtering tools will still benefit.So long as it's consistent, and applied when all the changes are only within France, then yes; simple, graceful, easy (to implement at both ends), and sounds like it would be effective.
I'm inspired to do some tinkering with OSMCha this afternoon.
-
Comment from Lee Carré
“I'm inspired to do some tinkering with OSMCha this afternoon.”
Seems that OSMCha is not able to exclude sets by such parameters. ☹
-
Comment from StC
- about the "other guideline", not sure where it is documented because I'm more or less summarizing discussions from the French-speaking Telegraph channel. I certainly sympathize with it, because it is more or less derived from ACID properties in databases and good practices when pushing commits in codebases. I hope someone else can be more precise about it.
- too bad about OSMCha, but maybe it's something that its developers would accept to consider? The filtering could be done on a polygon (that would work on all changesets) or on a regexp on the comments (that would require some effort from French contributors).
I sincerely hope you and contributors who are more expert than me will be able to find and implement a solution that works. Otherwise, you'll just need a vote from your fellow citizens to change the geography :-)
-
Comment from Lee Carré
“about the "other guideline", […] it is more or less derived from ACID properties in databases and good practices when pushing commits in codebases.”
I'm familiar. It's a good point.
The problem is a result of multiple factors.
Ideally, yes, a single changeset when making country-wide changes of the same type (e.g. to the same key on multiple elements). Unfortunately, especially for Jersey, the ‘noise’ of large irrelevant changesets then exceeds the ‘signal’ of locally-relevant ones. With no viable solution, it seems.
However, tagging the changeset is a good idea; much simpler than anything else I've seen discussed.
“about OSMCha, but maybe it's something that its developers would accept to consider?”
I would certainly hope so. Shouldn't be difficult to implement. The developers seem to have been thinking in terms of finding specific changesets, rather than filtering out non-local sets. So, it likely just hasn't occured to them to implement negation; it does what they currently need.
I'll try to find some time to search for any existing issues about the same problem / request.
However, it would be much more compelling if whole-France sets were already being tagged #France in order to show real-world need for the change (and to give developers something to test against).
Otherwise it may simply be ignored as a wish-list feature.
Bit of a chicken-and-egg problem, as is common with tech 😋.
“The filtering could be done on a polygon (that would work on all changesets) or on a regexp on the comments (that would require some effort from French contributors).”
Currently I use polygon-based filtering. The problem with that, is that in order to exclude enough noise to be worthwhile, it also ends up excluding large sets which DO make locally-relevant changes. For example, when someone updates the tagging of a chain of shops across the whole British Isles; filtering excludes that set because it's much larger than Jersey, yet the set makes local changes.
Otherwise, back to the original problem; more irrelevant sets (that have a bounding box which includes Jersey) which make zero local changes are still included in the local list of changesets, and overwhelmingly outnumber the locally-relevant sets.Hence being most interested in your suggestion of simply tagging such sets in a way which makes them easy to filter out. Anything else is a lot more complicated (and even if possible, won't be implemented for a long time).
Your suggestion is simple enough that it should be possible to automate the tagging of changesets, rather than requiring all French mappers to change their habits (which leaves the problem of there always being newbies who don't yet know to add #France).
“I sincerely hope you and contributors who are more expert than me will be able to find and implement a solution that works.”
As do I. Yours is the most promising suggestion, so far. Thankyou for your thoughtful ideas.
Just for my own understanding; how much do you estimate would be involved in having all whole-France changesets tagged with #France? Besides avoiding of guesswork, I'm also completely unfamiliar with the French OSM community.
“Otherwise, you'll just need a vote from your fellow citizens to change the geography 🙂”
Ha! 😁
I won't hold much hope for that. Our politicians struggle with much more basic concerns.Maybe if the outcome of the Battle of Jersey had been different, than this would be a moot point and we'd be conversing in French.
It would certainly make the current dispute re fishing (post-Brexit) a whole lot simpler, too 😄.
-
Comment from Lee Carré
“I'll try to find some time to search for any existing issues about the same problem / request.”
Just had a very brief look, and there does seem to be (other) demand for negation of multiple fields:
http://www.github.com/mapbox/osmcha-frontend/issues/507
http://www.github.com/mapbox/osmcha-frontend/issues/246 -
Comment from Lee Carré
A left a brief comment, pointing to this CS discussion, in http://www.github.com/mapbox/osmcha-frontend/issues/246
- Ligne de Saint-Georges-d’Aurac à Saint-Étienne-Châteaucreux (2953672), v19
- 3178171, v20
- Ligne de Saint-Germain-des-Fossés à Nîmes-Courbessac (4031680), v15
- Ligne de Saint-Germain-des-Fossés à Nîmes-Courbessac (4032143), v19
- Ligne de Saint-Germain-des-Fossés à Nîmes-Courbessac (4032225), v14
- Ligne de Saint-Germain-des-Fossés à Nîmes-Courbessac (4038027), v14
- Ligne de Savenay à Landerneau (23208833), v27
- Ligne de Savenay à Landerneau (23416806), v21
- Ligne de Brive-la-Gaillarde à Toulouse-Matabiau via Capdenac (23628374), v13
- Ligne de Brive-la-Gaillarde à Toulouse-Matabiau via Capdenac (23628375), v9
- Ligne de Brive-la-Gaillarde à Toulouse-Matabiau via Capdenac (23628376), v12
- Ligne de Brive-la-Gaillarde à Toulouse-Matabiau via Capdenac (23628377), v9
- Ligne de Brive-la-Gaillarde à Toulouse-Matabiau via Capdenac (23628378), v11
- Ligne de Brive-la-Gaillarde à Toulouse-Matabiau via Capdenac (23628379), v9
- Ligne de Brive-la-Gaillarde à Toulouse-Matabiau via Capdenac (23628380), v9
- Ligne de Brive-la-Gaillarde à Toulouse-Matabiau via Capdenac (23628381), v9
- Ligne de Brive-la-Gaillarde à Toulouse-Matabiau via Capdenac (23628382), v10
- Ligne de Brive-la-Gaillarde à Toulouse-Matabiau via Capdenac (23628383), v12
- Ligne de Brive-la-Gaillarde à Toulouse-Matabiau via Capdenac (23628384), v12
- Ligne de Brive-la-Gaillarde à Toulouse-Matabiau via Capdenac (23756201), v16
Relations (4)
- TER 12 : Marseille - Aix-en-Provence - Pertuis (974257), v109
- TER 13 : Marseille - Manosque - Gap - Briançon (974478), v266
- Ligne de Lyon-Perrache à Marseille-Saint-Charles (via Grenoble) (2990554), v171
- Ligne Marseille - Veynes (3253167), v93
- 1913125961, v4
- 1913125963, v4
- 1913125965, v4
- 1913125967, v3
- 1913125983, v3
- 1913125984, v3
- 1913125985, v3
- 1913125986, v3
- 1913125987, v3
- 1913135533, v6
- 1913135534, v5
- 1913135535, v4
- 22 (2522966836), v5
- 34 (2522966852), v5
- 2522966878, v3
- 2522966884, v4
- 2522966911, v4
- 2522966914, v3
- 36 (2522966916), v5
- 2522966919, v3
Welcome to OpenStreetMap!
OpenStreetMap is a map of the world, created by people like you and free to use under an open license.
Hosting is supported by Fastly, OSMF corporate members, and other partners.
https://openstreetmap.org/copyright | https://openstreetmap.org |
Copyright OpenStreetMap and contributors, under an open license |