Proposal:Automated tasks
| Automated tasks | |
|---|---|
| Proposal status: | Abandoned (inactive) |
| Proposed by: | flaimo |
| Tagging: | ata_delete,ata_delete:Key,ata_change:Key,ata_move,ata_copy=* |
| Applies to: |  ,  ,  , 
|
| Definition: | A way for mappers to use simple automated tasks |
| Statistics: |
|
| Draft started: | 2011-04-17 |
| RFC start: | 2011-04-24 |
The problem
Even though the number of mappers is growing rapidly, it is mainly in the urban areas. Chances that a small village in the countryside is permanently maintained in OSM is (at the current moment) rather small. Now, when outside mappers do make some changes in these areas, they will probably not check back on a regular basis to maintain the area, which could lead to wrong and outdated data. An example may describe the problem a bit better:
Mapper A from a big town is visiting a friend in the countryside. On his way he passes a small village and sees a shop informing its customers, that the opening_hours will change for the next 4 weeks. Back at home he changes the value for opening_hours=* for the shop. Even though the shop went back to its original opening hours a long time ago, one year later the outdated opening_hour information is still inside the OSM database, since mapper A forgot about the change or thought someone else would take care of the maintenance.
The (possible) solution
This situation could be solved by giving mappers a handset of special tags which could be evaluated and executed by bots on a regular basis. It would give the mapper the chance to basically set up simple automated tasks (ATA).
The keys
ata_delete
If this key is set it indicates that the element can be deleted after the given date.
Syntax:
ata_delete=<ISO datetime>
Example:
a construction area over a bigger landuse=residetial:
ata_delete:<Key>
If used on an element, the referenced key can be deleted after the given date (if it still exists at that time).
Syntax:
ata_delete:<Key>=<ISO datetime>
Example:
a private road that opens up to public traffic after a certain date:
ata_change:<Key>
If used on an element, the value for the referenced key entry will be changed to the given value after the given date. If an entry for that key doesn't exists anymore (or not yet) it will be created. In case the value itself contains semicolons, they have to be escaped ("\;").
Syntax:
ata_change:<Key>=<ISO datetime>;<New Value>
Example:
A supermarket informs his customers on its homepage, that the opening_hours will change in two weeks
- building=yes
- shop=supermarket
- opening_hours=Mo-Fr 09:00-12:00,13:00-18:00;Sa 09:00-12:00;Su off
- ata_change:opening_hours=2011-07-20T00:00:00Z;Mo-Fr 09:00-12:00,13:00-19:00\;Sa 09:00-18:00\;Su off
ata_move
If used on a node, it should get moved to the new location on the given date.
Syntax:
ata_move=<ISO datetime>;<Latitude>;<Longitude>
Example:
An IT company (mapped as a node inside a building) moves to another office building on the other side of the street coming november
ata_copy
If used on a node, a new node should be created on the given date and the given location. All tags are copied to the new node including any other ata_* entries that have a datetime in the future, except for the used ata_copy entry itself.
Syntax:
ata_copy=<ISO datetime>;<Latitude>;<Longitude>
Example:
Due to high demand a bank will offer another ATM on the other side of the street one week from now
Using more than one ata_* key of the same kind
Even though mappers should only use those keys for simple tasks, sometimes there is the need to add more than one key of the same type. In such a case an underline followed by an unsigned integer number can be appended to the ata_* key (before the colon).
Example:
A software company has to temporarily change to a different telephone number for its support hotline
- office=it
- name=MircoSoft
- phone=+1 555 3241528
- ata_change:phone=2011-10-21T00:00:00Z;+1 555 9998999
- ata_change_2:phone=2011-11-09T00:00:00Z;+1 555 3241528
Recurring tasks
Recurring tasks are not handled by this proposal. In such a case, you normally would write a dedicated bot anyway.
Evaluation
- One or more bots should evaluate the database on a regular basis (daily?) for elements tagged with the keys described above.
- The date value used with the keys doesn't mean that the element gets changed/deleted exactly at the given date and time. It is up to the bots on how often they want to check for eligible elements. It may also depend on the current workload of the servers.
- Ata_* tags should be processed in chronological order, based on the datetime value of those keys.
- Changes should only be executed if there are no conflicts. In case elements share data with other elements (for example a building marked for deletion sharing two nodes with an adjoined building not marked for deletion), the operation should be aborted.
- In case elements share data with other elements which are also marked for an automated task at the same datetime, the task should be executed and there shouldn't be an error.
- In case of an successful operation the ata_* tag should be deleted.
- In case of an unsuccessful operation the ata_* tag should not be deleted.
- In case of an unsuccessful operation the bot could send an e-mail with an error description to the mapper who added the evaluated ata_* tag.
Editors
While simple changes could be done editing the key/value list, editors could provide a GUI for doing more complex tasks. Examples:
- To the right of each entry in the key/value list, a little automated task icon could be displayed. If the user clicks on it he can set a date and time using a date control and the kind of operation that should be done (delete, change). Optionally the new value could also be entered there (maybe prefilled with the current value).
- Since entering the coordinates for a move operation by hand is complicated, a wizard could guide a user through the process. For example if a building, made up of 10 nodes, should be moved to a certain location at a certain time, the user could make a drag and drop operation of the building in the GUI and the wizard calculates the new coordinates for all nodes automatically.
Bot prototype
Since I don't know how to set up and write a bot on a database level, it would be great if a fellow OSM member, who knows how to do that, could set up a prototype bot for a small specific bbox for testing purposes. --Flaimo 01:08, 17 April 2011 (BST)