[OSM-dev] Standardized feature/tag database idea & proposal

Mon Nov 16 09:21:44 UTC 2020

Frederik has already pointed out some of the relevant historic points.

On top of that there is https://github.com/osmlab/editor-presets and I 
proposed  something similar a couple of years back as a GSOC project.

I would consider the concept moot. On the one hand, while theoretically 
still possible, the iD preset scheme now has little generalisation and 
has become very UI specific, requiring to capture a lot more editor 
specific data than just a couple of years back if you wanted the output 
to be similar to the original. On the other hand, not just because of 
the demographics, but also because of the OSMFs involvement, like it or 
not, the iD presets are the law of the land and anything else is simply 
irrelevant. That is not a statement about quality (I would maintain that 
my presets continue to be the best curated set of presets), but about mass.

You should have also given my talk at SOTM 2018 a look 
https://2018.stateofthemap.org/2018/T061-An_excursion_in_to_the_world_of_OSM_tagging_presets/

In any case both iD and Vespucci use taginfo and associated information 
to synthesize parts of, or complete presets. Vespucci as part of an 
explicit search process, iD built in to how their presets work. For a 
number of reasons the results are at best mixed, but clearly could be 
improved with some work on taginfo. I would consider this a better way 
forward than starting something new.

Simon

Am 15.11.2020 um 19:14 schrieb Seth Deegan:
> _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, would mean that the DB would never have to be physically 
> touched again and ensure greater long-term DB management efficiency.
> *
> *
> *So why basically delete one of the primary functions of the Wiki and 
> create a new system on openstreetmap.org <http://openstreetmap.org>?*
> I recently have got into the OSM community head-on in the past two 
> months. I have never really contributed to Wikipedia or any other site 
> that uses the MediaWiki website format so learning about how to 
> contribute and get around the OSM Wiki took time (learning about the 
> proposal process, Templates, talk pages, formatting, the list goes on 
> and on...). It also made me realize that this could discourage new 
> users from ever looking into the depths of OSM or even finding the 
> Wiki at all. The WikiMedia interface is not the prettiest either. It 
> can take time for new users to explore and find what they are looking 
> for.
> (Also, this would mean moving the proposal process over to osm.org 
> <http://osm.org> too)
>
> Therefore, I think creating a easily accessible, pretty, and 
> easily-contributable interface on osm.org <http://osm.org> would 
> strengthen the OSM community significantly. For example, a heading 
> called "Features" could be added to the left "GPS traces". It would 
> greet the user with the primary features of OSM (kind of like the "Map 
> features" on the Wiki already does) and Feature pages would have a 
> standard format that is consistent throughout the website (unlike Wiki 
> pages where tables for values can be different, proposals can be 
> different, etc.). Pages could also be "locked", or require a proposal 
> before ever changing any of the contents of their page/feature. This 
> would ensure the DB is secure and uniform with the community's 
> agreement on Features (the database is directly synced and edited 
> through changes on the website) and no "random edits' by users like on 
> the current Wiki would have to tracked (since anyone can directly 
> edit). There are other possible benefits that you could probably think of.
>
> Also, other pages on the Wiki would not be deleted. There are plenty 
> of great pages on it that have nothing to do with the DB and work well 
> in the open environment the Wiki has to offer.
>
> _Compiling and distributing the DB_
>
>  1. One would probably use a Wiki bot like
>     https://en.wikipedia.org/wiki/Wikipedia:AutoWikiBrowser
>     <https://en.wikipedia.org/wiki/Wikipedia:AutoWikiBrowser> to get
>     all of the features with Categories "approved" and "in-use" (and
>     "depreciated" as well just to let possible future editors know
>     what to get rid of) and add their Keys and Values, descriptions,
>     what elements they are allowed on (nodes, ways, areas, relations),
>     etc. to the DB.
>  2. A team would have to go through all of their Key Values that don't
>     have Wiki pages and add them to the DB along with their
>     descriptions, etc.
>  3. A team would compare the iD and JOSM present repo and xml file and
>     create a "standard" matching list.
>  4. When the DB is finished, iD and JOSM would use it as a dependency
>     and an announcement would be made to data consumers that it is
>     available for use.
>
> _Feasibility_
> This would probably be a huge undertaking and require a funding grant. 
> A plan and dedicated team would be required to ensure all of the tasks 
> are complete and put in-place. I personally think the benefits 
> outweigh the costs, specifically from a developer point-of view. Also, 
> I am not an OSMF member so I'm not sure how much say I would have in 
> making this possible.
>
> _Questions?_
> Please reply. I like big OSM ideas and am not afraid to get shut-down 
> as I have before with previous ideas. I am clearly a newer 
> contributor, but I hope my ideas and work can foster progress for OSM.
>
> -- 
> Thanks,
> Seth Deegan (lectrician1)
>
> _______________________________________________
> dev mailing list
> dev at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20201116/02e20654/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x4721711092E282EA.asc
Type: application/pgp-keys
Size: 4922 bytes
Desc: not available
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20201116/02e20654/attachment-0001.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 495 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20201116/02e20654/attachment-0001.sig>