<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Frederik has already pointed out some of the relevant historic
points.</p>
<p>On top of that there is <a class="moz-txt-link-freetext" href="https://github.com/osmlab/editor-presets">https://github.com/osmlab/editor-presets</a>
and I proposed something similar a couple of years back as a GSOC
project. <br>
</p>
<p>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. <br>
</p>
<p>You should have also given my talk at SOTM 2018 a look
<a class="moz-txt-link-freetext" href="https://2018.stateofthemap.org/2018/T061-An_excursion_in_to_the_world_of_OSM_tagging_presets/">https://2018.stateofthemap.org/2018/T061-An_excursion_in_to_the_world_of_OSM_tagging_presets/</a></p>
<p>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.</p>
<p>Simon</p>
<div class="moz-cite-prefix">Am 15.11.2020 um 19:14 schrieb Seth
Deegan:<br>
</div>
<blockquote type="cite"
cite="mid:CAAk9NOJqNPhb1OvrRrXLB-gEXPH9BxQbSxeM33ed=EJ5Vffg5w@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div><u>Idea</u></div>
Has anyone ever thought of creating an official database that
stores all of the approved and in-use tags/features in OSM?
<div><br>
</div>
<div><u>Reasoning</u></div>
<div>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.<br>
<br>
<u>Examples</u><br>
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:<br>
- Both are up-to-date and in-sync</div>
<div> - Adding new presets could be done automatically by
retrieving and parsing data from the DB. </div>
<div><br>
</div>
<div>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 <b>significantly</b> allow greater OSM
developer potential.</div>
<div>
<div><br>
</div>
<div><u>Specifics</u></div>
<div>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. </div>
<div><br>
</div>
<div><u>My pre-DB construction proposal </u></div>
<div>Before any type of database is made, one would would <b>construct
a dedicated page structure on <a
href="http://openstreetmap.org" moz-do-not-send="true">openstreetmap.org</a>
</b>that would display and be in-sync with all of the
Features from the DB in a format similar to the Wiki, and
then <b>remove all of the features from the Wiki
altogether.</b></div>
<div><b><br>
</b></div>
<div><b>Why?</b> If you see in <u>Compiling and distributing
the DB</u> 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 <i>impossible</i>
to parse thoroughly with a computer and are going to require
team of humans to get all of their data. </div>
<div><br>
</div>
<div>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.</div>
<div><b><br>
</b></div>
<div><b>So why basically delete one of the primary functions
of the Wiki and create a new system on <a
href="http://openstreetmap.org" moz-do-not-send="true">openstreetmap.org</a>?</b></div>
<div>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. </div>
<div>(Also, this would mean moving the proposal process over
to <a href="http://osm.org" moz-do-not-send="true">osm.org</a>
too)</div>
<div><br>
</div>
<div>Therefore, I think creating a easily accessible, pretty,
and easily-contributable interface on <a
href="http://osm.org" moz-do-not-send="true">osm.org</a>
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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div><u>Compiling and distributing the DB</u><br>
</div>
<div>
<ol>
<li>One would probably use a Wiki bot like <a
href="https://en.wikipedia.org/wiki/Wikipedia:AutoWikiBrowser"
moz-do-not-send="true">https://en.wikipedia.org/wiki/Wikipedia:AutoWikiBrowser</a>
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. </li>
<li>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.</li>
<li>A team would compare the iD and JOSM present repo and
xml file and create a "standard" matching list.</li>
<li>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.</li>
</ol>
<div><u>Feasibility</u><br>
</div>
</div>
<div>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.</div>
<div><br>
</div>
<div><u>Questions?</u> </div>
<div>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.</div>
<div><br>
</div>
-- <br>
<div dir="ltr" class="gmail_signature"
data-smartmail="gmail_signature">
<div dir="ltr">Thanks,
<div>Seth Deegan (lectrician1)</div>
</div>
</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:dev@openstreetmap.org">dev@openstreetmap.org</a>
<a class="moz-txt-link-freetext" href="https://lists.openstreetmap.org/listinfo/dev">https://lists.openstreetmap.org/listinfo/dev</a>
</pre>
</blockquote>
</body>
</html>