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

[Mateusz Konieczny via dev]

Nov 16, 2020, 10:21 by si...@poole.ch:

>
> the iD presets  are the law of the land and anything else is simply 
> irrelevant.
>
>
That is so overstating things that it ceases to be an useful statement.

iD presets and 
"press button here to `upgrade tags`  without explanation what and why and how 
actually happens"
are powerful, but it is only a part of what influences tagging.
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] dev Digest, Vol 188, Issue 1

[Mateusz Konieczny via dev]

(0) if you want to reply it would be better to disable digest mode

Nov 16, 2020, 01:21 by jayands...@gmail.com:

> 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.
>
Wiki pages are relatively well watched (warning: I am biased here,
as I am one of people quite active in that field).

Data items are not, as watchlisting them is dysfunctional (no way to skip
translations that given person cannot review, no way of grouping edits, 
standard edit
leave no description of edit and so on)

> 2. Lack of synchronization between the Data items and their Wiki pages.
>
This sort of works and is causing issues due to lack of control in Data Items

> 3. JOSM doesn't use Data items yet. 
>
I am dubious is it useful or going to happen, but it is up to JOSM developers

> 4. The MediaWiki interface is still hard for new users to grasp.
>
And note, that even if data items interface would be very easy - you still need
wiki pages for freeform description/comments

> 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>  
>
I am dubious whatever authors of editors would abandon maintaining presets and 
switch to
simply pulling from Data Items

Note that, for example, JOSM and iD are using icons in different styles.


___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

[Taginfo-dev] [taginfo/taginfo] cb23db: clarify that chronology results are deltas

[Jochen Topf via Taginfo-dev]

  Branch: refs/tags/osmorg-taginfo-live
  Home:   https://github.com/taginfo/taginfo
  Commit: cb23db154ca958d01412e3781b1885817a00411b
  
https://github.com/taginfo/taginfo/commit/cb23db154ca958d01412e3781b1885817a00411b
  Author: Martin Raifer 
  Date:   2020-11-16 (Mon, 16 Nov 2020)

  Changed paths:
M web/lib/api/v4/key.rb

  Log Message:
  ---
  clarify that chronology results are deltas


  Commit: d8fbc5da0c01af7c42807fe4e5aec1f123dc13f1
  
https://github.com/taginfo/taginfo/commit/d8fbc5da0c01af7c42807fe4e5aec1f123dc13f1
  Author: Martin Raifer 
  Date:   2020-11-16 (Mon, 16 Nov 2020)

  Changed paths:
M web/lib/api/v4/tag.rb

  Log Message:
  ---
  clarify that chronology results are deltas


  Commit: d6095440f9392956a18576c1d56cb781e77fedcd
  
https://github.com/taginfo/taginfo/commit/d6095440f9392956a18576c1d56cb781e77fedcd
  Author: Jochen Topf 
  Date:   2020-11-16 (Mon, 16 Nov 2020)

  Changed paths:
M web/lib/api/v4/key.rb
M web/lib/api/v4/tag.rb

  Log Message:
  ---
  Merge pull request #295 from tyrasd/patch-2

clarify that chronology results are deltas


Compare: https://github.com/taginfo/taginfo/compare/fe926740c8b4...d6095440f939

___
Taginfo-dev mailing list
Taginfo-dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/taginfo-dev

[Taginfo-dev] [taginfo/taginfo] cb23db: clarify that chronology results are deltas

[Jochen Topf via Taginfo-dev]

  Branch: refs/heads/master
  Home:   https://github.com/taginfo/taginfo
  Commit: cb23db154ca958d01412e3781b1885817a00411b
  
https://github.com/taginfo/taginfo/commit/cb23db154ca958d01412e3781b1885817a00411b
  Author: Martin Raifer 
  Date:   2020-11-16 (Mon, 16 Nov 2020)

  Changed paths:
M web/lib/api/v4/key.rb

  Log Message:
  ---
  clarify that chronology results are deltas


  Commit: d8fbc5da0c01af7c42807fe4e5aec1f123dc13f1
  
https://github.com/taginfo/taginfo/commit/d8fbc5da0c01af7c42807fe4e5aec1f123dc13f1
  Author: Martin Raifer 
  Date:   2020-11-16 (Mon, 16 Nov 2020)

  Changed paths:
M web/lib/api/v4/tag.rb

  Log Message:
  ---
  clarify that chronology results are deltas


  Commit: d6095440f9392956a18576c1d56cb781e77fedcd
  
https://github.com/taginfo/taginfo/commit/d6095440f9392956a18576c1d56cb781e77fedcd
  Author: Jochen Topf 
  Date:   2020-11-16 (Mon, 16 Nov 2020)

  Changed paths:
M web/lib/api/v4/key.rb
M web/lib/api/v4/tag.rb

  Log Message:
  ---
  Merge pull request #295 from tyrasd/patch-2

clarify that chronology results are deltas


Compare: https://github.com/taginfo/taginfo/compare/fe926740c8b4...d6095440f939

___
Taginfo-dev mailing list
Taginfo-dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/taginfo-dev

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

[Christoph Hormann]

> Simon Poole  hat am 16.11.2020 10:21 geschrieben:
> 
> [...] 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.

From my experience with OSM-Carto that is not really accurate.  Whenever iD 
presets suggest something different from established practice or community 
consensus the result typically is not the meaning of the tag changing to what 
iD says.  The result tends to be a huge mess of inconsistent uses.

In other words: iD's power over the development tagging and tag meaning in OSM 
is primarily either destructive or affirmative.  iD has the power to wreak 
havoc and destroy a tag or it can affirm and support a trend in already 
predominantly consistent use.  Same is the case with OSM-Carto.

-- 
Christoph Hormann 
http://www.imagico.de/

___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

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

[Simon Poole]

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 
 *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 ?*
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 
 too)

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

[Frederik Ramm]

Seth,

On 11/15/20 19:14, Seth Deegan wrote:
> Has anyone ever thought of creating an official database that stores all
> of the approved and in-use tags/features in OSM? 

Yes, of course, this idea has been around in a variety of flavours. I
remember a conference talk by David Earl in 2010
(https://wiki.openstreetmap.org/wiki/SotM_2010_session:_Tag_Central:_a_Schema_for_OSM)
though even then it was not revolutionary.

I think that going from a wiki to a plain database doesn't actually
solve many problems. Many things that are difficult for people to deal
with - like tag definitions leaving room for interpretation, different
editors having different presets, different language versions describing
tags differently, a lot of vagueness about the proposal process and its
importance, etc.etc. - would not be solved by your idea. You'd only
replace the backend but that would not automatically fix the messy bits
(and for some of the messy bits, "fixing" them might also mean breaking
a part of OSM that many cherish).

For example, one point you mention is that with a database, things could
be somehow "locked", but you're completely ignoring the question of who
would get to lock stuff, who would decide which changes are allowed, and
how this relates to translations, what the appeals process would be
etc.etc. - and *those* are the difficult questions, not the question of
whether I could technically have a mechanism that would restrict editing
to certain people.

And of course, as has been pointed out, the wiki stuff can already be
accessed in a database-like fashion, not only through the data endpoint
but also through the taginfo-wiki SQLite database from
https://taginfo.openstreetmap.org/download.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev