User:EmericusPetro/sandbox/OpenStreetMap CLDR equivalent

This article is a stub. You can help OpenStreetMap by expanding it. This is an early draft, however, as 2023-10-26, already contain the core of the idea

TL;DR

The OpenStreetMap CLDR equivalent on the title is a placeholder name inspired by Common Locale Data Repository (CLDR) from Unicode Consortium. The context for this a analogy:

• The Unicode Consortium have the primary purpose is to maintain and publish the Unicode Standard. One example: https://www.unicode.org/versions/Unicode15.0.0/UnicodeStandard-15.0.pdf
• One big problem for the Unicode Consortium: only publishing the Unicode Standard (e.g. how to encode text) and expecting operational system developers to consistently employ the user interfaces for data input and output wasn't working.
  • Even the most well intentioned developers don't necessarily know the languages and cultures of the target audience, which may not be able to express the problem clearly.
  • Fixing issue in one implementation in contradiction with the others causes interpretation issues for data meant to be shared without awareness of target audience. And not attempting to fix causes stagnation.
• The CLDR was the collection of additional machine-readable files (sometimes not so obvious in relation to Unicode Standard for general public, but was for implementers) decided by a technical committee inside the Unicode Consortium.

This text argues that, in addition to the OpenStreetMap data dumps (See Dump and Planet.osm), additional machine-parseable files reusable by software processing the data, but in particular the ones aiding the collecting the data from humans, could mitigate some issues while speeding up innovation. This page gives a overview of a draft of how could be done the early stage, and the /Ideas a list of potential individual packages, with some with data already published, but not centralized and endorsed like the data isefl is.

General organization

Note: for inspiration of similar idea, check the CLDR live repository at https://github.com/unicode-org/cldr . The natural language explanation of the directory is at https://cldr.unicode.org/index/downloads#Repository_Organization .

Directory structure of the collection of packages

The proposal here is, far as possible from existing sources or viability of humans to handcraft structured content, in order of priority:

1. to deliver machine readable output on each package of additional knowledge not already in the OpenStreetMap data dumps.
2. natural language explanations (ideally, close to technical specifications, but could be simply informal texts, such as based on OSM Wiki)

Frequency of releases

1. The proposal is to have a full release, with all parts together in the same downloadable project at minimum one time of the year, on a planned date, potentially aligned with the agenda of relevant working groups or community meetings. However, in the first years, potentially also have a mid-term release. One reason to have a planned yearly release, even if most discussions would happen directly in the source of the packages months before, is both to increase awareness, be the last stage to resolve disputes and aid strategies for financial support for OpenStreetMap project.
2. Individual packages may optionally have far frequent releases (such as daily release), so software could consume these instead of the versioned global version, but these would not be considered fully reviewed for consistency. One good example would be a machine-readable format of the data mining of the tagging on Wiki without any kind of human review, but with the same schema of how this package would be on the global release.

Targeted audience

While individual packages likely have own self-organization before be compiled as the common global release, by analogy with similar projects (from CLDR to publications by standards organizations), by inference the target audience (and, when relevant, candidates for decision taking) is the following:

1. Individuals who already have software deployed in production focused on aid mappers for OpenStreetMap project, in special but not only:
   1. collect or update data, such as OpenStreetMap editors (see Editors)
   2. support good practices based on conventions (see Quality assurance)
   3. Open question: should we expect the individual to be a OpenStreetMap Foundation member?
2. Representative for corporations in good standing with their obligations as OSMF corporate members (see https://osmfoundation.org/wiki/Corporate_Members)
   1. In addition to these people already work directly with the data, this potentially reduce likelihood of fragmentation of alternatives to OSMF
3. Invited experts with relationship not applicable in any previous category

The draft above attempts to focus on interested individuals and corporate organisations which are already strongly likely to use and be impacted by decisions (because this audience already create the interfaces for output and in special input). The "Invited experts" is a catch-all term for pre-approved (maybe formalized by EWG or directly by OSMF Board meeting?) to cooperate beyond guests or by proxy.

While this obviously would need better discussion, the hope is make easier consensus-based decisions, which is challenging if proponents aren't already close to the impact of any real world implementation. Still feasible to meet such a baseline if individuals collaborated on existing projects, maybe even explicitly indicated by main maintainers. The impact of new tagging and deprecations can go as far as require refactoring depending on the type of software, which is why consensus (to not say empathy) is necessary, as merely encoding the changes in machine-readable format wouldn't be sufficient.

Working Group inside OpenStreetMap project

The suggested OSMF Working Group to be the primary contact would be the Engineering Working Group. One of its responsibilities already is "Offering a platform for coordination of software development efforts across the OSM ecosystem". Following tradition on standards organizations, the last step typically involves approbation at higher levels, not merely the working groups part of it. So, naturally, OpenStreetMap Foundation, represented by OSMF Board, ultimately would be responsible. A 1-year release might fit such a calendar.

One problem with create a new working group might not be a good start, since because result would be compilation of several packages, the tendency might be smaller (not a central) working group. From OSMF Working Groups, EWG also has regular meetings, so this could help with formalizing irregular activity around the year with an audience potentially focused on their subject or/or using their preferred medium of discussion.

Some explicitly non-goals

As rule of thumb: neither is granted adoption from software developers nor is free pass to mappers to do mass editing without following existing procedures for many years.

Similar to the disclaimers on Proposal process such as "the outcome of a proposal vote does not compel a change in tools which use and generate OSM data", while the deliverables focus be usable between the target audience, hopefully be reasonable consensuses and in special avoiding contradictions, the adoption with developers is voluntary. This approach of non-enforcement is also aligned with how standards organizations operate. And similar with disclaimers also on Quality assurance, even with any kind of higher endorsement than previously status quo, would not be a reason to large-scale re-tagging or mass geometry change of existing objects on the main OpenStreetMap server.

Potential list of initial packages

Moved to User:EmericusPetro/sandbox/OpenStreetMap_CLDR_equivalent/Ideas.