3 ms·

I'm probably being unreasonable on the tools, you're right that that Osmose is excellent. > Automated fixing of them is generally pushed back against socially

I'm probably being unreasonable on the tools, you're right that that Osmose is excellent. > Automated fixing of them is generally pushed back against socially though. I think for good reasons. One is that a data user can do the automated fixes if they want to, so it's better to put human eyes on all the issues so that the ambiguous ones get fixed correctly. This is perhaps a conservative pov, the less ambiguous cases can probably be safely resolved with automation. I just think that sporadic, automatic editing of the global dataset, without much (or any) pre-approval, doesn't make sense. Better that there was more effort put into coming to formal decisions, and that those decisions, when adopted, become official and consistently applied. To take a trivial example, if someone's going to collapse MacDonalds, Mcdonald's, McDonald's, "MacDonald's Restaurant" and 15 other permutations down to one spelling worldwide, that shouldn't be a decision to be made by one individual, posibly reversed if they really get out of line or end up making some bad mistake, and applied only once or sporadically, it would be better IMO to be debated up-front, approved or rejected as a formal policy, and maintained. On wikipedia, I mean finding ways to couple their structure/geographical data with OSM, for instance if you have a building article on wikipedia, with structured data about construction date, architect, location, possibly 3D model, and similar and overlapping information about construction date, outline, entrances, etc on OpenStreetMap. Probably you'll never have an automatic coupling, but you could for instance have joint efforts to set shared conventions for the structure of the data, and constitency tools to point out where data is available in one but not the other, or disagrees between the two.

maxerickson 10y ago
That's the intended process for automated edits, with a pretty high bar for what should be carried out. This does result in sporadic fixing, as the global edits don't get done. A big issue with such edits in general is that there are restaurants using the other names that aren't a McDonald's, so 'fixing' those ends up breaking the data. In practice, the suggestions in the web editor end up being pretty powerful, so fewer wrong names get created in the first place. I don't really see the need for shared conventions with the Wikipedia stuff, as long as each project ends up settling on a convention it shouldn't be a big deal to reconcile just those 2 conventions. Wikipedia/Wikidata are anyway probably the better place to put endless trivia.
- Brakenshire 10y ago
  The process for the automated edits just seems to be too ad-hoc to me. For instance, you could argue mass edits should require an API key which is granted by positive approval through an automated, formal process, made using formal guidelines which are polished and adjusted over time. Any automated edits should have a link through to the formal discussion in each commit. Excellent point about the suggestions through the web editor, though, perhaps that will be enough. As a matter of interest, do you have any idea who decides what items are in the editor (for instance, if tags are disputed or inconsistent)? And are the suggestions done by popularity, or are they manually decided? On shared conventions, it's just, do you have separate start and end construction dates, or combined, do you write that 1930-34 or 1930:1934, how do you handle approximate dates, are you going to write C19, 19th C, 19th century or 19C, and so on. In general I just think you need more active decision making, and a process towards consistency in the data. It's really tough to consume data from a geographical database where everything is up in the air.
  - maxerickson 10y ago
    A technical policy doesn't stop me from doing it semi-manually in JOSM (it'd merely be annoying to geographically segment some edits and space them out over time). So it ultimately depends on good behavior anyway. The preset system in iD is driven by the data here: https://github.com/openstreetmap/iD/tree/master/data https://github.com/openstreetmap/iD/tree/master/data In particular, the suggestions are built here: https://github.com/osmlab/name-suggestion-index https://github.com/osmlab/name-suggestion-index The process looks at popularity and then tries to do some standardization from there, suggesting a most popular form when less popular forms are encountered. There's a shorter list of committers, but I would say it's overall reasonably open to contributions. My point with the Wikipedia is who cares. If you know Wikipedia does 1930-34 and OSM does 1930:1934, the details of converting one to the other will tend to be a lot simpler than any interesting thing you are trying to do with the combined data. It's a bunch of annoying cat herding to get a little bit of hypothetical convenience (hypothetical because what interesting thing is presently held back by the different forms?).

maxerickson 10y ago

That's the intended process for automated edits, with a pretty high bar for what should be carried out. This does result in sporadic fixing, as the global edits don't get done. A big issue with such edits in general is that there are restaurants using the other names that aren't a McDonald's, so 'fixing' those ends up breaking the data. In practice, the suggestions in the web editor end up being pretty powerful, so fewer wrong names get created in the first place. I don't really see the need for shared conventions with the Wikipedia stuff, as long as each project ends up settling on a convention it shouldn't be a big deal to reconcile just those 2 conventions. Wikipedia/Wikidata are anyway probably the better place to put endless trivia.

Brakenshire 10y ago
The process for the automated edits just seems to be too ad-hoc to me. For instance, you could argue mass edits should require an API key which is granted by positive approval through an automated, formal process, made using formal guidelines which are polished and adjusted over time. Any automated edits should have a link through to the formal discussion in each commit. Excellent point about the suggestions through the web editor, though, perhaps that will be enough. As a matter of interest, do you have any idea who decides what items are in the editor (for instance, if tags are disputed or inconsistent)? And are the suggestions done by popularity, or are they manually decided? On shared conventions, it's just, do you have separate start and end construction dates, or combined, do you write that 1930-34 or 1930:1934, how do you handle approximate dates, are you going to write C19, 19th C, 19th century or 19C, and so on. In general I just think you need more active decision making, and a process towards consistency in the data. It's really tough to consume data from a geographical database where everything is up in the air.
- maxerickson 10y ago
  A technical policy doesn't stop me from doing it semi-manually in JOSM (it'd merely be annoying to geographically segment some edits and space them out over time). So it ultimately depends on good behavior anyway. The preset system in iD is driven by the data here: https://github.com/openstreetmap/iD/tree/master/data https://github.com/openstreetmap/iD/tree/master/data In particular, the suggestions are built here: https://github.com/osmlab/name-suggestion-index https://github.com/osmlab/name-suggestion-index The process looks at popularity and then tries to do some standardization from there, suggesting a most popular form when less popular forms are encountered. There's a shorter list of committers, but I would say it's overall reasonably open to contributions. My point with the Wikipedia is who cares. If you know Wikipedia does 1930-34 and OSM does 1930:1934, the details of converting one to the other will tend to be a lot simpler than any interesting thing you are trying to do with the combined data. It's a bunch of annoying cat herding to get a little bit of hypothetical convenience (hypothetical because what interesting thing is presently held back by the different forms?).