Oh wow. So Data Items basically is what I'm proposing. I also didn't know
it also had a role in the Wikibase Registry (probably wouldn't want to get
rid of that).
I guess my only issues with the current system would be:
1. Lack of quality control (it said in the Wiki page for Data items that it
has not been implemented yet). Quality control should probably apply to the
corresponding Wiki pages themselves too.
2. Lack of synchronization between the Data items and their Wiki pages.
3. JOSM doesn't use Data items yet.
4. The MediaWiki interface is still hard for new users to grasp.
5. Layouts for Wiki pages aren't standardized. Something else my proposal
could address would be the conversion of Proposed Feature pages to actual
Wiki pages (would require a standardization) but honestly it is not the
most important thing.
6. Devs still have to manually add presets. One of my first issues on the
iD repo was actually concerning this (btw uneducated at how approved
features worked at the time):
https://github.com/openstreetmap/iD/issues/7552
On Sun, Nov 15, 2020 at 4:01 PM wrote:
> Send dev mailing list submissions to
> dev@openstreetmap.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.openstreetmap.org/listinfo/dev
> or, via email, send a message with subject or body 'help' to
> dev-requ...@openstreetmap.org
>
> You can reach the person managing the list at
> dev-ow...@openstreetmap.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of dev digest..."
>
>
> Today's Topics:
>
>1. Standardized feature/tag database idea & proposal (Seth Deegan)
>2. Re: Standardized feature/tag database idea & proposal
> (Mateusz Konieczny)
>
>
> ------
>
> Message: 1
> Date: Sun, 15 Nov 2020 12:14:19 -0600
> From: Seth Deegan
> To: dev@openstreetmap.org
> Subject: [OSM-dev] Standardized feature/tag database idea & proposal
> Message-ID:
> ej5vff...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> *Idea*
> Has anyone ever thought of creating an official database that stores all of
> the approved and in-use tags/features in OSM?
>
> *Reasoning*
> This could allow the editors (iD and JOSM, StreetComplete, GoMap!) and data
> consumers (osm-carto,. Mapbox etc.), to easily stay up-to-date with new
> features, without requiring their developers to browse the Wiki etc.
>
> *Examples*
> Both iD and JOSM have their own preset file/repo and are independent of
> each other. Creating a database that could be used as a dependency of both
> that would store these feature presets and their fields means:
> - Both are up-to-date and in-sync
> - Adding new presets could be done automatically by retrieving and parsing
> data from the DB.
>
> Creating applications that use OSM data can be hard and time-lengthened by
> requiring developers to browse the Wiki to find all of the features and
> their keys and values. Having a database that they could easily get the
> keys they want, their values, etc. would *significantly* allow greater OSM
> developer potential.
>
> *Specifics*
> The specifics as to how this database would be arranged such as to where
> presets/fields/tags/features go has not been thought of yet. I just wanted
> to ask if this has ever been proposed before. If someone would like me to
> make a DB layout to help them better understand what I'm proposing, I'd be
> happy to do so.
>
> *My pre-DB construction proposal *
> Before any type of database is made, one would would *construct a dedicated
> page structure on openstreetmap.org <http://openstreetmap.org> *that would
> display and be in-sync with all of the Features from the DB in a format
> similar to the Wiki, and then *remove all of the features from the Wiki
> altogether.*
>
> *Why?* If you see in *Compiling and distributing the DB* below, a Wiki bot
> is going to be required to get all of the pages for all of the
> already-standard features. Most of the features' pages do have a similar
> structure as to how they are arranged (template that shows what elements
> they use, Keys' values and their descriptions are stored in a table, etc.),
> however these pages would be *impossible* to parse thoroughly with a
> computer and are going to require team of humans to get all of their data.
>
> New features that are proposed and approved after the database would be
> created would require them to be hand-added. Making a standard way to
> propose and approve new features on a new part of the website with
> formatting constraints and database-syncing abilities that MediaWiki cannot
> offer, w
