3 ms·

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 po

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

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?).