{% extends "sidebar-page.html" %} {% block content %}
1) How to become a Publisher Member
2) An Introduction to DOAJ and Publishing Best Practice
3) Publishing best practice and basic standards for inclusion
4) Copyright, Licensing and Publishing Rights
5) Applying for your journal to be in DOAJ
6) If your application is accepted
7) If your application is rejected
8) Publishing disclaimer
9) How to get your journal content / article metadata indexed in DOAJ. Uploading content.
10) What to do if your XML upload fails
11) Troubleshooting your XML upload
12) My journal has changed title and ISSN(s)
13) How to correct an error in article metadata on DOAJ
14) How to make a complaint or appeal
15) Does "no Seal" mean we are not indexed in DOAJ?
16) FAQs
DOAJ is a membership organisation that relies entirely on voluntary donations from the community to develop and grow. We urge you to become a Publisher Member.
Being a Publisher Member does not guarantee that your journals will be included in the DOAJ. All applications are treated equally from both members and non-members.
Here are some publishing best practices. These are not ideas generated by DOAJ but are common publishing standards for online journals and digital posting. We have also consulted OASPA's Code of Conduct and we are co-authors to the Principles of Transparency and Best Practice in Scholarly Publishing. Where stated, some of the items below are counted as basic requirements for inclusion in DOAJ.
Coverage:
One URL per site. One dedicated page to the journal.
When a journal gets indexed it will have its own record in the Directory. To make our service comprehensible and user-friendly, the link to a journal from the Directory must go straight to a homepage for the journal and not to a collection of journals or any other service. Whether the URL is a dedicated domain or a sub-domain does not matter; but the journal must have an online space dedicated to it. For example: www.thisisajournal.com or www.publishersite.com/journals/thisisajournal or www.mycollege.org/thisisajournal are all acceptable. www.largesearchengine.com that includes journal content is not accepted. This is a basic requirement for entry into DOAJ.
All the necessary journal business information pages (by 'business information pages', we mean the journal's aims and scope, the editorial board, the instructions for authors, the description of the quality control system, the Open Access statement, the plagiarism policy, and the licensing terms) must be hosted on this same site and not be held centrally on another web site, or must be prominently linked to from the journal's homepage. This is a basic requirement for entry into DOAJ. This applies particularly to multi-journal publishers who may prefer to hold generic information on a corporate website rather than locally on each journal site. Our insistence on this approach makes it easier for visitors to your sites to find specific journal information correctly. Do not assume that visitors to a journal will automatically understand that the journal belongs to a larger group of journals or to a specific publisher, or that important information is held elsewhere. Neither should it be taken for granted that users will search for the necessary information that they need to carry out a full assessment of your journal. It is your responsibility to ensure that the information pages are findable, easily accessible, up to date and relevant.
When submitting URLs in your application, note that we will only accept one URL per answer. Applications with more than one URL in a URL field will be rejected.
DOAJ also requests that a journal has its own dedicated website. No other service or product should be present under that URL. All the journal content that the publisher is including in the application must be in one place and not spread over various locations. This includes archive material. This is a basic requirement for entry into DOAJ.
One unique URL per article. One HTML entry or PDF per article.
Your content should be available article by article, one URL for each article, and not one URL per issue. This enables direct linking to the articles from DOAJ and 3rd party databases that link to DOAJ, promoting findability and increasing usage of your content. When article metadata is uploaded to DOAJ, every article must have a unique URL otherwise the upload will not work.This is a basic requirement for entry into DOAJ.
A journal must have at least one ISSN (International Standard Serial Number) registered at issn.org. This is a basic requirement for entry into DOAJ. DOAJ will use the data registered at issn.org to verify the title, country and alternative titles that you enter in your application. They must match. If we find a discrepancy, we will change the application to match what is registered at issn.org. Applications will be automatically rejected where the ISSN provided: is not recognised; is incorrectly formatted; has not yet been confirmed or is listed as provisional; is fake; does not match the title given on the website. Applications will also be rejected if the title on the website does not match what is held at issn.org.
You can double check what information issn.org holds about your ISSN(s) here: https://portal.issn.org/. If you wish to update the information held at issn.org about your journal, you should contact your national ISSN centre.
In general, if the journal exists in print and online, it will have both an ISSN for the print version and an ISSN for the electronic version.
We strongly recommend that your content is preserved in a dedicated, digital archiving and preservation service, sometimes referred to as Long Term Preservation and Archiving (LTPA). You can find a list some of these services here. We prefer that journals belong to one of these services, although it is not a requirement for entry into DOAJ. We check all preservation statuses in the Keepers' Registry and at PubMed Central. If your journal is hosted on the Open Journal Systems (OJS) software and you have selected to be part of the PKP Private LOCKSS network, we must first see that content has actually been deposited by confirming its preservation status with the Keepers Registry.
Organisation of content
Please pay attention to the fact that having a clear structure when organizing your published material makes it easier
for users to navigate between articles, for your content to be indexed in search engines and to be found online.
All articles must have a Publication Date. Also, DOAJ encourages the use of unique article identifiers, such as the DOI.
Preferably articles will be gathered in volumes and issues, with a start and end page number. Some publishers have moved away from this traditional volume/issue/page structure for their content. A publication year is still required.
Articles should be arranged in to Tables of Contents and there should be Search/Browse features to allow users to search and browse for articles.
Homepage quality, commercials and ads
A journal's homepage should be clear, concise and easy to navigate. It must contain visible links to
the journal information pages. It must 'demonstrate that care has been taken to ensure high
ethical and professional standards.' (From the Principles of Transparency
and Best Practice in Scholarly Publishing.) It must contain clear navigation with links to a Current Issue, the
Archive or Past Issues, Search, Browse, the About page, the Editorial Board and Contact Us. This is a basic
requirement for entry into DOAJ.
If the journal web site carries advertising, ensure that the ads are not in any way offensive, irrelevant and that they don't include information that could decrease the credibility of the journal. Blinking and/or moving objects will distract a reader and will make your web site difficult to use and inaccessible to users who access the Internet using non-traditional methods . These types of ads are strongly discouraged.
Impact Factors
DOAJ does not believe in the value of impact factors, does not condone their use on journal web sites, does not
recognise partial impact factors, and advocates any official, alternative measure of use, such as article level
metrics.
There is only one official, universally recognised impact factor that is generated by Clarivate; it is a proprietary measure run by a profit-making organisation. This runs against the ethics and principles of open access and DOAJ is impact-factor agnostic. DOAJ does not collect metadata on impact factors.
Editor(s) and editorial boards
A journal must have an editor and an editorial board
. (Only for Arts and Humanities journals will
we accept a form of editorial review using only two editors and no editorial board.) If the journal is run by a student body, the
journal must have an advisory board of which at least two members have a PhD or equivalent.
Displaying clear and up-to-date information about the journal's editors and editorial board increases the trustworthiness and credibility of the journal. A site user must be able to find and contact the editor or members of the editorial or advisory board if they need to. A link to the Board must be displayed prominently on the journal's home page. The name and affiliation of the editorial board members must be publicly available on the Editorial Board page. The page must be up-to-date. These are basic requirements for entry into DOAJ.
Quality control and author guidelines
It is very important to show that open access journals have the same, rigorous quality control systems in place as
traditional printed or subscription-based journals. All articles must go through
a quality control system (editorial
or peer review) before publication and the exact type of review must be stated clearly on the web site.
This is a basic requirement for entry into DOAJ.
Having detailed and comprehensive guidelines for authors (Instructions for Authors) is a good way of helping potential contributors. A link to these guidelines must be clearly presented on the journal's homepage. This is a basic requirement for entry into DOAJ.
We recommend that author guidelines include the following information:
Charges, Article processing charges
Every journal must display clearly on its web site information about any charges for an author to
process or publish a paper. This includes article
processing charges (APCs), submission charges,
page charges, colour charges or any instance where money is required to complete the publication process. If a journal does not levy any
charges then this too must be clearly stated. These are basic requirements for entry into DOAJ.
Open Access statement
The journal's Open Access policy must be clearly stated
on the journal's web site (not the publisher's own site). The full text
of the articles of the journal should be freely available without embargo.These are basic requirements
for entry into DOAJ.
Here is an example of an Open Access statement, fitting our criteria, that could be published on your website:
This is an open access journal which means that all content is freely available without charge to the user or his/her institution. Users are allowed to read, download, copy, distribute, print, search, or link to the full texts of the articles, or use them for any other lawful purpose, without asking prior permission from the publisher or the author. This is in accordance with the BOAI definition of open access.
DOAJ will accept a short open access statement—even as short as ‘This journal is open access.’—but ONLY in combination with a Creative Commons licensing statement, or equivalent licensing statement, on the same page and, preferably, in the same paragraph. If the licensing statement is not on the same page as the open access statement then the extended open access statement complying with BOAI definition will be required.
Licensing your material with a CC license: An optimum way of showing exactly how a journal is Open Access is by licensing the content with a Creative Commons (CC) license. DOAJ considers the application of a CC license, or its equivalent, as best practice. Such licensing is very beneficial for authors since it shows, for example, if there are any limits in creating derivative works. Read more about applying licenses and copyright on our Copyright and Licensing Help page.
In all instances the journal web site must state clearly and precisely the terms of use and reuse that readers and authors have when they submit an article or use the published content, particularly if you are not using a Creative Commons license. This is a way of showing that you are sharing your published material to support a greater global exchange of knowledge. It is also a way of protecting your material from illegal use (for example if you are stating that you prohibit reproduction or commercial use of your articles).These are basic requirements for entry into DOAJ
For example, your site might state that: 'users can use, reuse and build upon the material published in the journal but only for non-commercial purposes'. Use, reuse and build upon refer specifically to the common definitions of open access, given for example in Wikipedia. 'Use' is downloading or reading and not much more; 're-use' is making more use of the content, for example distributing, making copies, using in presentations; 'building upon' is a special form of re-use in which material is used to produce a new research work and, possibly, a new publication. Publishers may restrict the re-use of open access content (to Non-Commercial or to Share Alike as described in the corresponding Creative Commons license attributes: NC and SA) and may even prohibit building upon content by not allowing Derivatives (the altering, transformation, or building upon content, as described in the corresponding Creative Commons license attributes: ND) to be made.
Publishers who restrict the re-use of content in line with any of the Creative Commons licenses are all still eligible for indexing in DOAJ. However, DOAJ has a strong preference for the use of Creative Commons licenses, especially the least restrictive: the Creative Commons CC-BY license (Attribution). Under the terms of a CC BY license "you must give appropriate credit, provide a link to the license, and indicate if changes were made". "You may do so in any reasonable manner, but not in any way that suggests the licensor endorses you or your use" (from http://creativecommons.org/licenses/by/4.0/).
Read our dedicated Copyright and Licensing Help page for more information.
For more information on embedded licensing information as referred to in Question 45 of the application form, please refer to the Copyright and Licensing Help page, this FAQ and our blog post on this matter.
If you are NOT using a Creative Commons license, you must fill in your application form specifying what other usage terms apply. This is Question 48 in the form, which is revealed if you have selected 'Other' in Question 47. 'Other' might be a contract, publishing agreement, publisher-specific license and these terms must be equivalent to the terms of the Creative Commons licenses that are listed in order to be accepted into DOAJ. When writing their own license, we strongly advise publishers to get legal advice before adopting a standard text or constructing their own. You must make sure that you use the correct legal language. (The information provided here does not constitute legal advice.)
Please note that "Fair Use" is different to Open Access and is interpreted differently in the United States, Europe and in various other countries in the world. Fair use often means allowing limited use for educational purposes without having to ask for permission. Fair use applies irrespective of Open Access and open access licensing conditions. A journal offering only Fair use will always be rejected.
Please take care to identify any possible contradictions between your Open Access policy and your copyright policy, or any incompatibilities between your copyright policy and Creative Commons licensing. Read more about this on our blog.
If licensing old material, please make sure that your journal holds the copyright for the published material. If you do not, you have to ask the original copyright holder for permission before licensing the articles. (More information can be found in the Creative Commons wiki.)
Plagiarism
It is recommended that publishers make use of one of the several plagiarism detection services that are available.
Plagiarism is a big problem and plagiarised articles on a web site are often an indicator of a poor quality
journal, or a journal that uses no quality control system.
For a journal to be included in DOAJ, it must go through the application process. The application form is very detailed and it will take time to complete. You are advised to collect all the necessary information up front before you start filling in the form. You cannot save your progress in the form so you must submit the application in one session.
IMPORTANT NOTE
If the application you are submitting contains information that is inaccurate or wrong, or if answers have been missed or skipped, then it will be automatically rejected. For example, an application is submitted with multiple URLs in a URL field or the same URL is provided throughout the application form. These applications will be automatically rejected without review.
Filling in the application form
You must submit an application online. Do not email a spreadsheet.
The information that you provide in the application must match what is displayed on your web site. Doublecheck that the information you are submitting matches.
IMPORTANT NOTE
If the application form contains information that is inaccurate or clearly wrong, or if answers have been missed or skipped, then it will
be automatically rejected. To give an example of one of the most commonly encountered errors: sometimes applications are submitted where
every question that asks for a URL contains the same answer over and over, just pointing to the same page, the homepage. Our editorial
teams will not spend time reviewing these applications and they will be automatically rejected.
The details you provide for the Journal Contact must be a real person with their full name. Answers such as Editor, Admin, Webmaster, Editorial etc will be automatically rejected.
The country that you use in your application must be the country of the publisher, where the publisher carries out the majority of the editorial processes, business functions and day-to-day activities. The country of an address registered via a registering agent (typically: the United States) is not allowed.
Alcune risorse sono disponibili anche in italiano | Some further resources are available in Italian. (These posts have been created by one of our Associate Editors, Andrea Marchitelli.)
Once you submit your application
Upon submission you will be shown a confirmation screen and you will be sent a confirmation email. Save this email as it will help us find your application later, should you have any questions about it. If you do not get a cofirmation email, please contact us.
Each journal application may be assessed by up to four different members of the DOAJ Team:
DO NOT submit your application more than once. Duplicate applications are automatically rejected without notification.
Waiting for a decision
You will receive an automated email when your application is assigned to a member of the editorial team. You will receive a second automated email when that person starts working on it. Every application is reviewed manually and it takes time to ensure that we do this carefully and thoroughly. We carry out this process as quickly as possible but also to a very high standard. Currently, due to the number of applications we are receiving every week, it is taking up to 6 months to make a decision on an application or update request. We apologise in advance for the extended wait but please be assured that we are working as hard as we can with the resources that we have. We ask you to refrain for requesting status updates for applications that are under 6 months' old.
One of the most common reasons for rejection is that we receive no response to our emails. We will automatically reject the application after 1 month. Please be sure to check your Spam folder frequently and be aware that the Associate Editor who is reviewing your application is a volunteer and will not be emailing you from a doaj.org email address.
Common reasons for rejection are:
Upon acceptance into DOAJ, the journal is classified by subject and assigned an LCC code by the DOAJ team. An automatic confirmation email is sent to the Journal Contact (this may be different to the Applicant). A second email is sent that contains details on how to log in to your Publisher account. You will need these details to upload article metadata. The journal is then visible in DOAJ immediately. If you do not get your email, check your Spam folder before contacting us. Your journal may have been added to an existing account in which case no email is sent.
If your application is rejected, you will receive an email from us detailing the reason(s) for the rejection. A rejected journal may apply again for inclusion, usually after 6 months, unless otherwise stated, and once it has demonstrated clearly that it meets all of the requirements stated on this page. Applications submitted before the end of the stated period will be automatically rejected.
We ask applicants to wait 6 months (unless a longer time period has been communicated - see below) before submitting another application for two reasons. The first is because we want to discourage repeat applications, made in hsate, and we get many, many of those. Repeat and duplicate applications clog up the system and take our dedicated volunteers and team away from those applications which need some time spent on them. (In 10 months alone, DOAJ received 221 duplicate applications!)
The second reason is that many of the recommendations that we make in our rejection emails, recommendations made to help journals meet our criteria, take time to implement. Adding words to a website isn’t enough. Changes need to be implemented properly, communicated to stakeholders, tested, and managed. Some changes will require other parties to implement changes too. This all takes time. After the 6 months has passed, we welcome a new application but we ask that the journal website demonstrates very clearly that our recommendations have been put into practice and our editorial team will be very careful to check that all our recommendations have been implemented.
The applicant is responsible for providing accurate information when submitting an application for consideration. If the information provided is not sufficient or is incomplete, the application will not be considered. In cases where the information provided is found to be untrue, either during reviewing or even after admission, we reserve the right to reject or remove the journal with immediate effect and to not accept new applications for a period of 1 year. In cases where a single publisher has submitted more than 5 applications with false information, we reserve the right to remove all of the publisher's journals listed in DOAJ and to not accept any more applications for a maximum period of 3 years, depending on the number of journals for which false information was provided and the eventual number of repeated incidents.
DOAJ's general disclaimer is available on our About page.
It is the publisher's responsibility to upload article metadata to DOAJ. At this time, DOAJ doesn't go out and harvest metadata.
PLEASE NOTE that DOAJ doesn't want author email addresses. We kindly ask that you don't send any email addresses to us in metadata uploadeds. Email addresses should be stripped out before the metadata is uploaded. Recent guidelines on the use of personal data restrict what you can send us.
TO UPLOAD CONTENT TO US log in to your Publisher Area and choose 'Upload Article XML' (automated) or 'Enter Article Metadata' (manual).
You can only upload metadata for journals that belong to your account. Uploads will only work if the ISSN(s) you provide matches the ISSN(s) we have on file for your journals. Discrepancies will cause the upload to fail. If you need to update an ISSN on a journal record, submit an update request to us.
Every article you upload to DOAJ must have a unique URL. If you use the same URL for all articles, the upload will fail.
It is strongly recommended that a DOI is provided (where available) for each article.
We can only display one language for titles and abstracts. If your XML contains two or more languages, the first occurring language in the XML will be displayed. On 3rd February 2020, we updated the code lists that we use for country, currency and language. This means that some codes which were previously recognised will no longer work. These code lists are referenced in our XSD file which all XML uploads are compared against. If your upload contains one of the old codes, the upload will fail. You will see the error 'Unable to validate document with identified schema'. The full details of all the code changes can be found in this list. If your uploads suddenly fail on or after Monday 3rd February 2020 then it is worth consulting this list.
For help with creating DOAJ XML and details on XML tags, read the File Upload Info section on our Features pages.
For help with creating Crossref XML use their web deposit form and metadata manager. Using the form will send a copy of the XML back to you which you can then upload to DOAJ. For help validating Crossref XML, use the Crossref parser.
This section describes the possible error messages that you may see when you upload an article XML file to DOAJ. Depending on the message in the "Notes" column of your uploads table, some corrective actions may be available to you.
In cases where there is no action to be taken, or the suggested actions have not successfully resolved the issues, please contact us with the following details:
Reason: From within the provided file, there were some successful article imports (X), but one or more failed article imports (N)
Resolution: Individual articles can fail for a number of reasons. See the section Reasons for individual article import failures below
Reason: From within the uploaded file, there were no successful article imports and one or more failed article imports
Resolution: Individual articles can fail for a number of reasons. See the section Reasons for individual article import failures below
Reason: An unexpected software exception occurred - you may have found a bug!
Resolution: Please contact us immediately with the relevant details.
Reason: Something unexpected happened when we tried to import your articles - you may have found a bug!
Resolution: Please contact us immediately with the details:
We may also ask you to supply the file that you tried to upload, so please keep a copy of it until the issue is resolved.
Reason: A URL (either HTTP or FTP) you provided to the form field "Provide a URL where we can download the XML" led to a file which was larger than 250Mb
Resolution: Please provide a smaller file in either case. You can split the articles across two or more schema valid documents, and make them available to us separately.
Reason 1: The HTTP URL you provided could not be resolved to a resource on the web (e.g. your web server responded with a 404 Not Found)
Resolution 1: Check the following regarding the URL your provided to the form field "Provide a URL where we can download the XML":
Reason 2: The download from an HTTP URL you provided failed part way through for an unspecified reason
Resolution 2: Re-try the upload, as this may be an intermittent network issue.
If you are still unable to get the upload to work after a several attempts, please contact us with the relevant details.
Reason: The XML file you provided (either downloaded from a URL or uploaded via the web form) could not be read as an XML file
Resolution: Check that the file really is valid XML.
In some cases this will be easy - you may have uploaded/provided the wrong file, so double-check that it is the correct one. You'd get this error, for example, if you have uploaded a Word document or a PDF by mistake.
In other cases files can look very much like XML, but still be invalid. They should be run through an XML validator to ensure they have the correct structure and that there are no illegal characters.
Sometimes, special characters - especially those in scientific articles - are submitted in the wrong format. XML does not support many special characters as-is but those that it does can be found on Wikipedia.
You can use one of these validators to check your XML:
Reason: No XML schema could be found which would read the provided XML document (in particular, the DOAJ standard schema)
Resolution: Check that the file conforms to the DOAJ schema, using a validator.
Often the problem arises because the XML is missing a required tag. If you try to upload XML to DOAJ that is missing a specific tag, such as <publicationDate> then the schema validation will fail. You can see exactly which tags are required here.
If you are trying to upload a file that was automatically generated by the OJS DOAJ plugin, then you should first contact OJS for help.
The DOAJ schema is on our site, here: http://doaj.org/static/doaj/doajArticles.xsd
To validate the provided XML against the schema, you can use one of these services:
If both of these services regard the provided XML as schema valid, please contact us with the relevant details.
Reason: Article belongs to a journal that does not belong to your user account
You can only upload XML for the journals that are IN DOAJ and that appear in the list under 'Your Journals' in the publisher area. If you have more than one account and you would like to merge them, please contact us.
The Article's stated ISSNs must match to a journal that is owned by the user account from which you are providing the XML file. If the ISSNs do not match any journals or match a journal that is owned by a different account, the import of that article will fail.
Note that it is also possible that if an article has more than one ISSN (i.e. an E-ISSN and a P-ISSN), that those ISSNs could match more than one Journal (one ISSN matching one journal, the other ISSN matching another). If both matched journals are owned by your account, this will not stop the article from being imported, but if one of the matched journals is owned by a different account this will cause the import of the article to fail.
A journal may have two ISSNs: an ISSN for the print version and an ISSN for the electronic version. Sometimes the ISSNs of the journal have changed. If you need to have the ISSNs of your DOAJ record updated, please contact us and we will check that the ISSNs are registered at www.issn.org and will then update the record accordingly.
Resolution: Check that all the Article ISSNs in the file are correct
If you believe all the ISSNs for the articles are correct, please contact us with the relevant details.
Reason: At least two of the articles in the uploaded file contain the same DOI and/or the same fulltext url
Resolution: Ensure that there are no duplicated articles in the file. Ensure that you are using the correct DOIs and URLs for all the articles.
Reason: At least one of your articles matched two or more other articles already in DOAJ, and as a result we don't know which one to update.
Resolution: Ensure that all your articles have the correct DOI and Fulltext links. If you still don't have any luck, please contact us with the details; we may need to clean up your existing articles manually.
DOAJ is not staffed to help with XML queries. We have put together this list of resources and possible solutions that we have collected over the years. It is your responsibility to provide us with correctly formatted XML. HTML coding is NOT accepted: we only display plain text.
If your journal has a new title then it will also have a new ISSN. This is called a continuation. Continuations occur when journals change title or merge with another journal(s). We have a special process for continuations that you must follow.
First you must submit a new application for the new version of the journal, with its new title and new ISSN(s). DO NOT ask us to update the title and ISSN(s) of the current record in DOAJ. We cannot do this. We must preserve the old version of the journal alongside the new version.
Once you have submitted the new application, email us to let us know. Include the title and ISSN(s) of both versions of the journal in your email so that we can join the two in our system and create a continuation.
If you need to correct an error, you must upload the metadata again. To make sure that your new upload overwrites the old one, at least one of two specific pieces of metadata in the new file must be the same as in the old file. The 2 specific pieces of metadata that we look for are, in priority order:
If there is no DOI, the script will look for the Full Text URL.
Some examples
Use case 1: a publisher wants to correct some article metadata because an author is missing. The publisher must
re-upload the file. The article's DOI in the XML is the same as on the site so the site automatically overwrites the
older version.
Use case 2: a publisher wants to correct the URL for their full text articles because their site has moved.
The publisher does not use DOIs. The publisher must upload a new version. No automatic overwriting
will happen because no matching can occur so the publisher must contact us so we can remove the older version.
Use case 3: one article in an issue contains a spelling mistake in one of the author names. The publisher can correct
the entry manually, without contacting DOAJ, by logging into their account and clicking on the 'Enter Article Metadata'
tab. Enter the new, correct metadata into the form and submit. Since the URL of the article is not changing, the
correction will overwrite the old version.
If you would like to make a complaint, or would like to appeal against the decision to reject your application you should send an email to the DOAJ Managing Editors<EMAIL_ADDRESS>that contains the following information:
- journal title
- journal ISSN
- reason for complaint or appeal
For an appeal, you should attach a copy of the original rejection email that you received. Individual cases will be discussed every two weeks at a team meeting. After the meeting, and within 4 weeks of you sending your email, a Managing Editor will email you with the result of your appeal. This will not be the same Managing Editor who handled your case originally.
For a complaint, your case will be discussed at a meeting between the Editor-in-Chief and the Projects and Community Manager. They may consult the Advisory Board. Within 4 weeks of your email to Clara, the Editor-in-Chief will inform you whether or not your complaint has been upheld.
No. Being awarded the Seal is completely separate to being accepted into DOAJ. The Seal is an extra mark of approval that is awarded to journals in DOAJ. Read our blog post for further details. Only journals that are indexed in DOAJ can be considered for the Seal.
If your journal has been added to an existing publisher account then you should login using the details that you have already.
If a new account has been created, an automated email is sent to the Journal Contact listed in Question 9 of the application form that was submitted to us. The email contains the username and instructions on how to choose a password. The link is valid for 14 days only.
If you have problems logging in, or you cannot see your journal listed, or you would like to merge two publisher accounts, then please Contact us.
Back to topIf you have forgotten your password, you can reset your password here: https://doaj.org/account/forgot. You should enter your username (usually the journal's ISSN without the hyphen) OR the email address associated with the journal in our database.
An automated email will be sent to the email address associated with the journal in our database. If you have requested that email but did not get it then:
If you have forgotten your username:
It maybe that your journal has not applied to be in the DOAJ, in which case, please submit an Application. It may be that the journal's application is still pending or that the journal has been removed. If you believe that your journal has been wrongly removed then please contact us.
Back to topEvery application is reviewed manually and by up to 4 people. It takes time to ensure that we do this carefully and thoroughly. We carry out this process as quickly as possible but also to a very high standard. Currently, due to the number of applications we are receiving every week, it is taking up to 6 months to make a decision on an application or update request. We apologise in advance for the extended wait but please be assured that we are working as hard as we can with the resources that we have. We ask you to refrain for requesting status updates for applications that are under 6 months' old.
Back to topOnce a journal has been accepted into DOAJ, article metadata may be uploaded as XML or created manually. If the journal belongs to an existing DOAJ account, then you must log in to the existing account and then add metadata via the Publisher Area. For more information read 'Uploading Metadata'.
Back to topIf you did not receive any error messages when you uploaded the metadata then it is likely that everything has worked OK. Remember that it may take up to 30 minutes for your articles to appear on the site and up to 12 hours for the tables of contents to show your latest uploads. You can check that the articles have uploaded correctly by doing a search on the full article title in inverted commas " " or by going to your journal's entry in DOAJ.
If, after 24 hours, you still cannot find your article on the site, please Contact us.
Back to topOpen Access Journal:
We define open access journals as journals that use a funding model that does not charge readers or their institutions
for access. From the BOAI definition[1] of open access we take the right of users to 'read,
download, copy, distribute, print, search, or link to the full texts of these articles...or use them for any other
lawful purpose" as mandatory for a journal to be included in the directory.
[1] http://www.budapestopenaccessinitiative.org/read
Quality Control:
A journal must have an editor and an editorial board. (Only for Arts and Humanities journals will we accept a form of editorial review using only two editors and no editorial board.)
Research Journal:
Journals that report primary results of research or overviews of research results to a scholarly community.
Periodical:
A serial appearing or intended to appear indefinitely at regular intervals, generally more frequently than annually, each issue or volume of which is numbered or dated consecutively and normally contains separate articles, stories, or other writings.
Back to topOAI, Open Archives Initiative, supplies a common framework to web communities that allows them to gain access to content in a standard manner by means of metadata harvesting. Read the details of our OAI feature. Read the full Wikipedia entry.
Back to topOpenURL is a standardized format of Uniform Resource Locator (URL) intended to enable Internet users to more easily find a copy of a resource that they are allowed to access. It is most heavily used by libraries to help connect their customers to journal content. DOAJ's OpenURL service is Version 1.0 which is compatible with the previous 0.1 version as well. Read the full Wikipedia entry.
Back to topWe have an 'Indexed in DOAJ' logo in .eps and .png formats. Please contact us to request it and a member of our team will check that your journal qualifies.
Back to topThe DOAJ Seal is a mark of certification for open access journals, awarded by DOAJ to journals that achieve a high level of openness, adhere to Best Practice and high publishing standards. To receive the Seal, the journal must comply with the following 7 conditions:
Here is a list of journals that have the Seal.
Back to topThese are journals that have been awarded the DOAJ Seal.
Back to topThe green tick ("The Tick") is displayed against all journals that were accepted into DOAJ after March 2014 when DOAJ launched its new criteria for journals to be accepted into DOAJ. The new criteria require a higher level of compliance to best practices and publishing standards. Journals that do not have The Tick are in the process of being reviewed for removal.
Back to topYes! We launched a full API suite in 2015. Our API is here and you can join the DOAJ API community by signing up to our Google Groups:
Sign up to the announcement group or follow us on our news channels to find out more about our full API offering, and release dates.
Back to topWhen a journal changes title and get a new ISSN, this is called a 'continuation'.
If your journal has changed title then it must have a new ISSN. If you do not have a new ISSN then contact your local ISSN office. The ISSN must be confirmed and registered at issn.org before you can go further with us.
Once you have the new ISSN then you must submit a new application to us with all of the details of the new journal, including the new title and new ISSN. After you have submitted the application, send an email to us at feedback[at]doaj[.]org and let us know that you have just submitted an application for a continuation. Include the OLD ISSN and title, and the NEW ISSN and title in your email. We will then join the two in the Directory for you.
Back to topIt isn't possible to save your Application just yet; it's a feature that we will add in the future. In the meantime, you could try these two tips to help you keep a record of your application(s):
When applying for a journal to be included in DOAJ, you should include case reports in your article count if they include the retrospective analysis of more than 3 clinical cases. When more than three cases are involved, the article constitutes "research."
Back to topDOAJ recognises that some journals may not publish in a field where peer review is the established form of quality assurance. Instead a system of editorial review—carried out by the editors or the editors and members of the editorial board only—is in place. This is particularly relevant to the Arts and Humanities. 'Editorial review' will only be accepted as an answer to Question 35 of the Application Form if the journal publishes in some such field. We do not accept journals that only have one editor with no editorial board.
Back to topFunders, libraries and authors can all access deposit policy directories to get an overview of publishing channels that are compliant with, for instance, funder policies. This is one of our areas where we are encouraging Best Practice. A good example of a deposit policy directory is www.sherpa.ac.uk/romeo/.
Back to top(You may have an equivalent license in your country that is not a CC license. This is perfectly valid for DOAJ.)
How to choose the CC BY license:
Go to the Creative Commons (CC) web site (http://creativecommons.org/licenses/) and copy the CC BY icon - you can also consult this: http://wiki.creativecommons.org/Before_Licensing .
Put the CC BY icon on the homepage of your journal(s) and on EVERY article. Read how. Best Practice recommends that the license metadata is machine readable that is to say: embedded in the HTML, XML or in the PDF metadata.
Back to topYou can find information on the different types of licenses at the Creative Commons web site: http://creativecommons.org/licenses/ and there is even a page to help you choose the correct license for your content: http://creativecommons.org/choose/.
Both pages are available in 24 different languages.
Back to topWhen applying for a journal to be included in DOAJ, one of the questions asks whether or not you have machine-readable licensing information embedded in your article metadata. There are guidelines on the Creative Commons web site that tell you more about this. The information must be embedded in the HTML, the XML or the PDFs. Sometimes, it will be embedded in individual article components too, such as an MP3, an image or a video. The emphasis for DOAJ is not HOW the license is embedded but that there IS a machine-readable version of it. Here are a couple of examples:


Syrian Rue (extract) & A. muscaria (extract)
I have had two previous experiences with amanita mushrooms. One with freshly picked mushrooms which had no real effect. Another experience with 2 grams of 1:10 amanita extract which I had bought in a 'smartshop' resulted in mild stoning effects which left me wanting more.
This day was beautiful weather and I wanted to take a break from my job search. I decided I was going to go to the park and lie in the sun. I had made an extract of harmala seeds. I buy half a kilogram for three bucks or so. I had extracted the seeds with water and vinegar and added table salt to get the hcl form of the alkaloids. I had left the extract in a box somewhere for half a year after using it a few times.
So I took 150 mg of the extract (which corresponds to 3 grams of the seeds) in water which left a terrible aftertaste. I felt something coming on but it kind of subsided after a half an hour or so. I thought the material must have lost potency. So I took another 150 mg. in a capsule this time. Another buzz which subsided more or less. This was the point where I decided I still have some amanita extract somewhere, maybe it will give a nice mellow buzz to chill in the park. I took my stuff and went to the park. Downed half a gram of 1:10 amanita extract, put on my headphones, and listened to the 'red hot on impulse' jazz cd. I laid in the sun and enjoyed the feeling the small amount of amanita had added to the harmala. Sometimes I could get some minor closed eye faint visuals going, at other times I just felt very relaxed and content. No anxiety or worries which sometimes accompany psychedelics. I had a long phone conversation with a good friend, which went rather smoothly.
Maybe two or three hours after taking the amanita extract I got hungry and wanted to go home.  Biking was better but I still swayed somewhat. When I got home nausea and a faint feeling overwhelmed me. I could not eat and got very drowsy. I went to bed and slept for three or more hours. The rest of the night I was nauseous and sedated. I could only entertain my evening guest lying on the floor, because standing up I would get to nauseous (we did have a good laugh about that!). The feeling reminded me very much of serotonin syndrome, which I have had before when I was on 'Effexor' (an SSRI I quit taking a year ago). Visual shaking of the surrounding reminded me of what I had had with a combination of 5-htp and iboga.
The next day I read this on the net: 'A potentially psychoactive beta-carboline compound, methyltetrahydrocarboline carboxylic acid (MCTHC; I-methyl-3-carboxyl-tetrahydro-B-carboline has been isolated in low levels from European A. muscaria (Matsumoto et al. 1963).' Maybe the compound is an mao-inhibitor? Maybe this could expain the 'serotonin syndrome' feeling? More probably harmala just enhances some aspects of amanita which can turn out not so pleasant? I just wanted to warn people who read the trip report about combining amanita with harmala (as I did), for me it was pleasant in the beginning but after about three hours it got physically very unpleasant.
Experience Reports are the writings and opinions of the individual authors who submit them.
Some of the activities described are dangerous and/or illegal and none are recommended by Erowid.


My Portfolio
This is my portfolio.
Click here to get a random message:
Hello
linkedin profile
Fetch data!
Comment:


module Moongoon::Collection::Versioning::Static
Defined in:
models/models.crInstance Method Summary
-
#clear_history : Nil
Clears the history collection.
-
#count_versions(id, **args) : Int32 | Int64
Counts the number of versions associated with a document that matches the id argument.
-
#create_version_by_id(id) : String?
Saves a copy of a document matching the id argument in the history collection and returns the id of the copy.
-
#create_version_by_id(id, &block : self -> self) : String?
Saves a copy with changes of a document matching the id argument in the history collection and returns the id of the copy.
-
#find_all_versions(id, fields = nil, skip = 0, limit = 0, **args) : Array(self)
Finds all versions for a document matching has the id argument and returns an array of
Moongoon::Collection
instances. -
#find_latest_version_by_id(id, fields = nil, **args) : self?
Finds the latest version of a model by id and returns an instance of
Moongoon::Collection
. -
#find_specific_version(id, query = BSON.new, fields = nil, skip = 0, **args) : self?
Finds a specific version of a model by id and returns an instance of
Moongoon::Collection
. -
#find_specific_version!(id, **args) : self
NOTE Similar to
self.find_specific_version
but will raise if the version is not found. -
#find_specific_versions(ids, query = BSON.new, fields = nil, skip = 0, limit = 0, **args) : Array(self)
Finds one or more versions by their ids and returns an array of
Moongoon::Collection
instances.
Instance Method Detail
Clears the history collection.
NOTE Use with caution!
Will remove all the versions in the history collection.
Counts the number of versions associated with a document that matches the id argument.
user_id = "123456"
User.count_versions user_id
Saves a copy of a document matching the id argument in the history collection and returns the id of the copy.
NOTE similar to create_version
.
Saves a copy with changes of a document matching the id argument in the history collection and returns the id of the copy.
NOTE similar to create_version
.
Finds all versions for a document matching has the id argument and returns an array of Moongoon::Collection
instances.
NOTE Versions are sorted by creation date.
user_id = "123456"
versions = User.find_all_versions user_id
Finds the latest version of a model by id and returns an instance of Moongoon::Collection
.
Same syntax as Moongoon::Collection.find_by_id
.
# "123456" is an _id in the original collection.
user_version = user.find_latest_version_by_id "123456"
Finds a specific version of a model by id and returns an instance of Moongoon::Collection
.
Same syntax as Moongoon::Collection.find_by_id
.
# "123456" is an _id in the history collection.
user_version = user.find_specific_version "123456"
NOTE Similar to self.find_specific_version
but will raise if the version is not found.
Finds one or more versions by their ids and returns an array of Moongoon::Collection
instances.
NOTE Versions are sorted by creation date in descending order.
names = ["John", "Jane"]
ids = names.map { |name|
user = User.new name: name
user.insert
user.create_version
}
# Contains one version for both models.
versions = User.find_specific_versions ids


|
|
Message box function. Gets a new message from the message box. If no message is available, the task blocks until a new message is received or the timeout has been reached. - Parameters:
-
| timeoutticks | timeout in timer ticks (see HZ define and MS macro). If this parameter is set to zero, the function immediately returns. If this parameter is set to INFINITE, the function will never time out. |
- Returns:
- pointer to the received message. Note that the message memory must be freed again with posMessageFree when POSCFG_MSG_MEMORY is defined to 1. NULL is returned when no message was received within the specified time (=timeout).
- Note:
- POSCFG_FEATURE_MSGBOXES must be defined to 1 to have message box support compiled in.
POSCFG_FEATURE_MSGWAIT must be defined to 1 to have this function compiled in.
- See also:
- posMessageFree, posMessageGet, posMessageAvailable, posMessageSend, HZ, MS
|


Production
Enter the daily production per shed:
Income Estimates
Income estimates are based on current production.
*This program currently shows the output on the console.
Enter the daily production per shed:
Income estimates are based on current production.
*This program currently shows the output on the console.


Form Design Exercise:
Email Address:
First Name:
Last Name:
Research Interest (list at least 3):
Project Title - (e.g. income vs education US Census):
Top Skills
SQL
Python programming
Matlab
D3.js and Javascript
C# VB.net
PHP
Node.JS
Web Design Tools (e.g. Wordpress)
HTML and CSS
Excel
PowerBI
Tableau
Other
Suggestions or Questions?


| Home | Trees | Indices | Help |
|
|---|
|
|
Proxy of C++ OGRFeatureShadow class.
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
Inherited from |
|
|||
thisown = property(lambda x: x.this.own(), lambda x, v: x.this
|
|||
__swig_destroy__ = _ogr.delete_Feature
|
|
|||
|
Inherited from |
|
repr(x)
|
__init__(Feature self, FeatureDefn feature_def) -> Feature
|
GetDefnRef(Feature self) -> FeatureDefn OGRFeatureDefnH OGR_F_GetDefnRef(OGRFeatureH hFeat) Fetch feature definition. This function is the same as the C++ method OGRFeature::GetDefnRef(). Parameters: ----------- hFeat: handle to the feature to get the feature definition from. a handle to the feature definition object on which feature depends. |
SetGeometry(Feature self, Geometry geom) -> OGRErr OGRErr OGR_F_SetGeometry(OGRFeatureH hFeat, OGRGeometryH hGeom) Set feature geometry. This function updates the features geometry, and operate exactly as SetGeometryDirectly(), except that this function does not assume ownership of the passed geometry, but instead makes a copy of it. This function is the same as the C++ OGRFeature::SetGeometry(). This method has only an effect on the in-memory feature object. If this object comes from a layer and the modifications must be serialized back to the datasource, OGR_L_SetFeature() must be used afterwards. Or if this is a new feature, OGR_L_CreateFeature() must be used afterwards. Parameters: ----------- hFeat: handle to the feature on which new geometry is applied to. hGeom: handle to the new geometry to apply to feature. OGRERR_NONE if successful, or OGR_UNSUPPORTED_GEOMETRY_TYPE if the geometry type is illegal for the OGRFeatureDefn (checking not yet implemented). |
SetGeometryDirectly(Feature self, Geometry geom) -> OGRErr OGRErr OGR_F_SetGeometryDirectly(OGRFeatureH hFeat, OGRGeometryH hGeom) Set feature geometry. This function updates the features geometry, and operate exactly as SetGeometry(), except that this function assumes ownership of the passed geometry (even in case of failure of that function). This function is the same as the C++ method OGRFeature::SetGeometryDirectly. This method has only an effect on the in-memory feature object. If this object comes from a layer and the modifications must be serialized back to the datasource, OGR_L_SetFeature() must be used afterwards. Or if this is a new feature, OGR_L_CreateFeature() must be used afterwards. Parameters: ----------- hFeat: handle to the feature on which to apply the geometry. hGeom: handle to the new geometry to apply to feature. OGRERR_NONE if successful, or OGR_UNSUPPORTED_GEOMETRY_TYPE if the geometry type is illegal for the OGRFeatureDefn (checking not yet implemented). |
GetGeometryRef(Feature self) -> Geometry OGRGeometryH OGR_F_GetGeometryRef(OGRFeatureH hFeat) Fetch a handle to feature geometry. This function is essentially the same as the C++ method OGRFeature::GetGeometryRef() (the only difference is that this C function honours OGRGetNonLinearGeometriesEnabledFlag()) Parameters: ----------- hFeat: handle to the feature to get geometry from. a handle to internal feature geometry. This object should not be modified. |
SetGeomField(Feature self, int iField, Geometry geom) -> OGRErr SetGeomField(Feature self, char const * field_name, Geometry geom) -> OGRErr OGRErr OGR_F_SetGeomField(OGRFeatureH hFeat, int iField, OGRGeometryH hGeom) Set feature geometry of a specified geometry field. This function updates the features geometry, and operate exactly as SetGeometryDirectly(), except that this function does not assume ownership of the passed geometry, but instead makes a copy of it. This function is the same as the C++ OGRFeature::SetGeomField(). Parameters: ----------- hFeat: handle to the feature on which new geometry is applied to. iField: geometry field to set. hGeom: handle to the new geometry to apply to feature. OGRERR_NONE if successful, or OGR_UNSUPPORTED_GEOMETRY_TYPE if the geometry type is illegal for the OGRFeatureDefn (checking not yet implemented). |
SetGeomFieldDirectly(Feature self, int iField, Geometry geom) -> OGRErr SetGeomFieldDirectly(Feature self, char const * field_name, Geometry geom) -> OGRErr OGRErr OGR_F_SetGeomFieldDirectly(OGRFeatureH hFeat, int iField, OGRGeometryH hGeom) Set feature geometry of a specified geometry field. This function updates the features geometry, and operate exactly as SetGeomField(), except that this function assumes ownership of the passed geometry (even in case of failure of that function). This function is the same as the C++ method OGRFeature::SetGeomFieldDirectly. Parameters: ----------- hFeat: handle to the feature on which to apply the geometry. iField: geometry field to set. hGeom: handle to the new geometry to apply to feature. OGRERR_NONE if successful, or OGRERR_FAILURE if the index is invalid, or OGR_UNSUPPORTED_GEOMETRY_TYPE if the geometry type is illegal for the OGRFeatureDefn (checking not yet implemented). GDAL 1.11 |
GetGeomFieldRef(Feature self, int iField) -> Geometry GetGeomFieldRef(Feature self, char const * field_name) -> Geometry OGRGeometryH OGR_F_GetGeomFieldRef(OGRFeatureH hFeat, int iField) Fetch a handle to feature geometry. This function is the same as the C++ method OGRFeature::GetGeomFieldRef(). Parameters: ----------- hFeat: handle to the feature to get geometry from. iField: geometry field to get. a handle to internal feature geometry. This object should not be modified. GDAL 1.11 |
Clone(Feature self) -> Feature OGRFeatureH OGR_F_Clone(OGRFeatureH hFeat) Duplicate feature. The newly created feature is owned by the caller, and will have its own reference to the OGRFeatureDefn. This function is the same as the C++ method OGRFeature::Clone(). Parameters: ----------- hFeat: handle to the feature to clone. a handle to the new feature, exactly matching this feature. |
Equal(Feature self, Feature feature) -> bool int OGR_F_Equal(OGRFeatureH hFeat, OGRFeatureH hOtherFeat) Test if two features are the same. Two features are considered equal if the share them (handle equality) same OGRFeatureDefn, have the same field values, and the same geometry (as tested by OGR_G_Equal()) as well as the same feature id. This function is the same as the C++ method OGRFeature::Equal(). Parameters: ----------- hFeat: handle to one of the feature. hOtherFeat: handle to the other feature to test this one against. TRUE if they are equal, otherwise FALSE. |
GetFieldCount(Feature self) -> int int OGR_F_GetFieldCount(OGRFeatureH hFeat) Fetch number of fields on this feature This will always be the same as the field count for the OGRFeatureDefn. This function is the same as the C++ method OGRFeature::GetFieldCount(). Parameters: ----------- hFeat: handle to the feature to get the fields count from. count of fields. |
GetFieldDefnRef(Feature self, int id) -> FieldDefn GetFieldDefnRef(Feature self, char const * field_name) -> FieldDefn OGRFieldDefnH OGR_F_GetFieldDefnRef(OGRFeatureH hFeat, int i) Fetch definition for this field. This function is the same as the C++ method OGRFeature::GetFieldDefnRef(). Parameters: ----------- hFeat: handle to the feature on which the field is found. i: the field to fetch, from 0 to GetFieldCount()-1. a handle to the field definition (from the OGRFeatureDefn). This is an internal reference, and should not be deleted or modified. |
GetGeomFieldCount(Feature self) -> int int OGR_F_GetGeomFieldCount(OGRFeatureH hFeat) Fetch number of geometry fields on this feature This will always be the same as the geometry field count for the OGRFeatureDefn. This function is the same as the C++ method OGRFeature::GetGeomFieldCount(). Parameters: ----------- hFeat: handle to the feature to get the geometry fields count from. count of geometry fields. GDAL 1.11 |
GetGeomFieldDefnRef(Feature self, int id) -> GeomFieldDefn GetGeomFieldDefnRef(Feature self, char const * field_name) -> GeomFieldDefn OGRGeomFieldDefnH OGR_F_GetGeomFieldDefnRef(OGRFeatureH hFeat, int i) Fetch definition for this geometry field. This function is the same as the C++ method OGRFeature::GetGeomFieldDefnRef(). Parameters: ----------- hFeat: handle to the feature on which the field is found. i: the field to fetch, from 0 to GetGeomFieldCount()-1. a handle to the field definition (from the OGRFeatureDefn). This is an internal reference, and should not be deleted or modified. GDAL 1.11 |
GetFieldAsString(Feature self, int id) -> char const GetFieldAsString(Feature self, char const * field_name) -> char const * const char* OGR_F_GetFieldAsString(OGRFeatureH hFeat, int iField) Fetch field value as a string. OFTReal and OFTInteger fields will be translated to string using sprintf(), but not necessarily using the established formatting rules. Other field types, or errors will result in a return value of zero. This function is the same as the C++ method OGRFeature::GetFieldAsString(). Parameters: ----------- hFeat: handle to the feature that owned the field. iField: the field to fetch, from 0 to GetFieldCount()-1. the field value. This string is internal, and should not be modified, or freed. Its lifetime may be very brief. |
GetFieldAsInteger(Feature self, int id) -> int GetFieldAsInteger(Feature self, char const * field_name) -> int int OGR_F_GetFieldAsInteger(OGRFeatureH hFeat, int iField) Fetch field value as integer. OFTString features will be translated using atoi(). OFTReal fields will be cast to integer. Other field types, or errors will result in a return value of zero. This function is the same as the C++ method OGRFeature::GetFieldAsInteger(). Parameters: ----------- hFeat: handle to the feature that owned the field. iField: the field to fetch, from 0 to GetFieldCount()-1. the field value. |
GetFieldAsInteger64(Feature self, int id) -> GIntBig GetFieldAsInteger64(Feature self, char const * field_name) -> GIntBig GIntBig OGR_F_GetFieldAsInteger64(OGRFeatureH hFeat, int iField) Fetch field value as integer 64 bit. OFTInteger are promoted to 64 bit. OFTString features will be translated using CPLAtoGIntBig(). OFTReal fields will be cast to integer. Other field types, or errors will result in a return value of zero. This function is the same as the C++ method OGRFeature::GetFieldAsInteger64(). Parameters: ----------- hFeat: handle to the feature that owned the field. iField: the field to fetch, from 0 to GetFieldCount()-1. the field value. GDAL 2.0 |
GetFieldAsDouble(Feature self, int id) -> double GetFieldAsDouble(Feature self, char const * field_name) -> double double OGR_F_GetFieldAsDouble(OGRFeatureH hFeat, int iField) Fetch field value as a double. OFTString features will be translated using CPLAtof(). OFTInteger fields will be cast to double. Other field types, or errors will result in a return value of zero. This function is the same as the C++ method OGRFeature::GetFieldAsDouble(). Parameters: ----------- hFeat: handle to the feature that owned the field. iField: the field to fetch, from 0 to GetFieldCount()-1. the field value. |
GetFieldAsDateTime(Feature self, int id) GetFieldAsDateTime(Feature self, char const * field_name) int OGR_F_GetFieldAsDateTime(OGRFeatureH hFeat, int iField, int *pnYear, int *pnMonth, int *pnDay, int *pnHour, int *pnMinute, int *pnSecond, int *pnTZFlag) Fetch field value as date and time. Currently this method only works for OFTDate, OFTTime and OFTDateTime fields. This function is the same as the C++ method OGRFeature::GetFieldAsDateTime(). Parameters: ----------- hFeat: handle to the feature that owned the field. iField: the field to fetch, from 0 to GetFieldCount()-1. pnYear: (including century) pnMonth: (1-12) pnDay: (1-31) pnHour: (0-23) pnMinute: (0-59) pnSecond: (0-59) pnTZFlag: (0=unknown, 1=localtime, 100=GMT, see data model for details) TRUE on success or FALSE on failure. See: Use OGR_F_GetFieldAsDateTimeEx() for second with millisecond accuracy. |
GetFieldAsIntegerList(Feature self, int id) GetFieldAsIntegerList(Feature self, char const * field_name) const int* OGR_F_GetFieldAsIntegerList(OGRFeatureH hFeat, int iField, int *pnCount) Fetch field value as a list of integers. Currently this function only works for OFTIntegerList fields. This function is the same as the C++ method OGRFeature::GetFieldAsIntegerList(). Parameters: ----------- hFeat: handle to the feature that owned the field. iField: the field to fetch, from 0 to GetFieldCount()-1. pnCount: an integer to put the list count (number of integers) into. the field value. This list is internal, and should not be modified, or freed. Its lifetime may be very brief. If *pnCount is zero on return the returned pointer may be NULL or non-NULL. |
GetFieldAsInteger64List(Feature self, int id) const GIntBig* OGR_F_GetFieldAsInteger64List(OGRFeatureH hFeat, int iField, int *pnCount) Fetch field value as a list of 64 bit integers. Currently this function only works for OFTInteger64List fields. This function is the same as the C++ method OGRFeature::GetFieldAsInteger64List(). Parameters: ----------- hFeat: handle to the feature that owned the field. iField: the field to fetch, from 0 to GetFieldCount()-1. pnCount: an integer to put the list count (number of integers) into. the field value. This list is internal, and should not be modified, or freed. Its lifetime may be very brief. If *pnCount is zero on return the returned pointer may be NULL or non-NULL. GDAL 2.0 |
GetFieldAsDoubleList(Feature self, int id) GetFieldAsDoubleList(Feature self, char const * field_name) const double* OGR_F_GetFieldAsDoubleList(OGRFeatureH hFeat, int iField, int *pnCount) Fetch field value as a list of doubles. Currently this function only works for OFTRealList fields. This function is the same as the C++ method OGRFeature::GetFieldAsDoubleList(). Parameters: ----------- hFeat: handle to the feature that owned the field. iField: the field to fetch, from 0 to GetFieldCount()-1. pnCount: an integer to put the list count (number of doubles) into. the field value. This list is internal, and should not be modified, or freed. Its lifetime may be very brief. If *pnCount is zero on return the returned pointer may be NULL or non-NULL. |
GetFieldAsStringList(Feature self, int id) -> char ** char** OGR_F_GetFieldAsStringList(OGRFeatureH hFeat, int iField) Fetch field value as a list of strings. Currently this method only works for OFTStringList fields. The returned list is terminated by a NULL pointer. The number of elements can also be calculated using CSLCount(). This function is the same as the C++ method OGRFeature::GetFieldAsStringList(). Parameters: ----------- hFeat: handle to the feature that owned the field. iField: the field to fetch, from 0 to GetFieldCount()-1. the field value. This list is internal, and should not be modified, or freed. Its lifetime may be very brief. |
GetFieldAsBinary(Feature self, int id) -> OGRErr GetFieldAsBinary(Feature self, char const * field_name) -> OGRErr GByte* OGR_F_GetFieldAsBinary(OGRFeatureH hFeat, int iField, int *pnBytes) Fetch field value as binary. This method only works for OFTBinary and OFTString fields. This function is the same as the C++ method OGRFeature::GetFieldAsBinary(). Parameters: ----------- hFeat: handle to the feature that owned the field. iField: the field to fetch, from 0 to GetFieldCount()-1. pnBytes: location to place count of bytes returned. the field value. This list is internal, and should not be modified, or freed. Its lifetime may be very brief. |
IsFieldSet(Feature self, int id) -> bool IsFieldSet(Feature self, char const * field_name) -> bool int OGR_F_IsFieldSet(OGRFeatureH hFeat, int iField) Test if a field has ever been assigned a value or not. This function is the same as the C++ method OGRFeature::IsFieldSet(). Parameters: ----------- hFeat: handle to the feature on which the field is. iField: the field to test. TRUE if the field has been set, otherwise false. |
IsFieldNull(Feature self, int id) -> bool IsFieldNull(Feature self, char const * field_name) -> bool int OGR_F_IsFieldNull(OGRFeatureH hFeat, int iField) Test if a field is null. This function is the same as the C++ method OGRFeature::IsFieldNull(). Parameters: ----------- hFeat: handle to the feature on which the field is. iField: the field to test. TRUE if the field is null, otherwise false. GDAL 2.2 |
IsFieldSetAndNotNull(Feature self, int id) -> bool IsFieldSetAndNotNull(Feature self, char const * field_name) -> bool int OGR_F_IsFieldSetAndNotNull(OGRFeatureH hFeat, int iField) Test if a field is set and not null. This function is the same as the C++ method OGRFeature::IsFieldSetAndNotNull(). Parameters: ----------- hFeat: handle to the feature on which the field is. iField: the field to test. TRUE if the field is set and not null, otherwise false. GDAL 2.2 |
GetFieldIndex(Feature self, char const * field_name) -> int int OGR_F_GetFieldIndex(OGRFeatureH hFeat, const char *pszName) Fetch the field index given field name. This is a cover for the OGRFeatureDefn::GetFieldIndex() method. This function is the same as the C++ method OGRFeature::GetFieldIndex(). Parameters: ----------- hFeat: handle to the feature on which the field is found. pszName: the name of the field to search for. the field index, or -1 if no matching field is found. |
GetGeomFieldIndex(Feature self, char const * field_name) -> int int OGR_F_GetGeomFieldIndex(OGRFeatureH hFeat, const char *pszName) Fetch the geometry field index given geometry field name. This is a cover for the OGRFeatureDefn::GetGeomFieldIndex() method. This function is the same as the C++ method OGRFeature::GetGeomFieldIndex(). Parameters: ----------- hFeat: handle to the feature on which the geometry field is found. pszName: the name of the geometry field to search for. the geometry field index, or -1 if no matching geometry field is found. GDAL 1.11 |
GetFID(Feature self) -> GIntBig GIntBig OGR_F_GetFID(OGRFeatureH hFeat) Get feature identifier. This function is the same as the C++ method OGRFeature::GetFID(). Note: since GDAL 2.0, this method returns a GIntBig (previously a long) Parameters: ----------- hFeat: handle to the feature from which to get the feature identifier. feature id or OGRNullFID if none has been assigned. |
SetFID(Feature self, GIntBig fid) -> OGRErr OGRErr OGR_F_SetFID(OGRFeatureH hFeat, GIntBig nFID) Set the feature identifier. For specific types of features this operation may fail on illegal features ids. Generally it always succeeds. Feature ids should be greater than or equal to zero, with the exception of OGRNullFID (-1) indicating that the feature id is unknown. This function is the same as the C++ method OGRFeature::SetFID(). Parameters: ----------- hFeat: handle to the feature to set the feature id to. nFID: the new feature identifier value to assign. On success OGRERR_NONE, or on failure some other value. |
DumpReadable(Feature self) void OGR_F_DumpReadable(OGRFeatureH hFeat, FILE *fpOut) Dump this feature in a human readable form. This dumps the attributes, and geometry; however, it doesn't definition information (other than field types and names), nor does it report the geometry spatial reference system. This function is the same as the C++ method OGRFeature::DumpReadable(). Parameters: ----------- hFeat: handle to the feature to dump. fpOut: the stream to write to, such as strout. |
UnsetField(Feature self, int id) UnsetField(Feature self, char const * field_name) void OGR_F_UnsetField(OGRFeatureH hFeat, int iField) Clear a field, marking it as unset. This function is the same as the C++ method OGRFeature::UnsetField(). Parameters: ----------- hFeat: handle to the feature on which the field is. iField: the field to unset. |
SetFieldNull(Feature self, int id) SetFieldNull(Feature self, char const * field_name) void OGR_F_SetFieldNull(OGRFeatureH hFeat, int iField) Clear a field, marking it as null. This function is the same as the C++ method OGRFeature::SetFieldNull(). Parameters: ----------- hFeat: handle to the feature on which the field is. iField: the field to set to null. GDAL 2.2 |
SetFieldInteger64(Feature self, int id, GIntBig value) void OGR_F_SetFieldInteger64(OGRFeatureH hFeat, int iField, GIntBig nValue) Set field to 64 bit integer value. OFTInteger, OFTInteger64 and OFTReal fields will be set directly. OFTString fields will be assigned a string representation of the value, but not necessarily taking into account formatting constraints on this field. Other field types may be unaffected. This function is the same as the C++ method OGRFeature::SetField(). This method has only an effect on the in-memory feature object. If this object comes from a layer and the modifications must be serialized back to the datasource, OGR_L_SetFeature() must be used afterwards. Or if this is a new feature, OGR_L_CreateFeature() must be used afterwards. Parameters: ----------- hFeat: handle to the feature that owned the field. iField: the field to fetch, from 0 to GetFieldCount()-1. nValue: the value to assign. GDAL 2.0 |
SetFieldIntegerList(Feature self, int id, int nList) void OGR_F_SetFieldIntegerList(OGRFeatureH hFeat, int iField, int nCount, const int *panValues) Set field to list of integers value. This function currently on has an effect of OFTIntegerList, OFTInteger64List and OFTRealList fields. This function is the same as the C++ method OGRFeature::SetField(). This method has only an effect on the in-memory feature object. If this object comes from a layer and the modifications must be serialized back to the datasource, OGR_L_SetFeature() must be used afterwards. Or if this is a new feature, OGR_L_CreateFeature() must be used afterwards. Parameters: ----------- hFeat: handle to the feature that owned the field. iField: the field to set, from 0 to GetFieldCount()-1. nCount: the number of values in the list being assigned. panValues: the values to assign. |
SetFieldInteger64List(Feature self, int id, int nList) void OGR_F_SetFieldInteger64List(OGRFeatureH hFeat, int iField, int nCount, const GIntBig *panValues) Set field to list of 64 bit integers value. This function currently on has an effect of OFTIntegerList, OFTInteger64List and OFTRealList fields. This function is the same as the C++ method OGRFeature::SetField(). This method has only an effect on the in-memory feature object. If this object comes from a layer and the modifications must be serialized back to the datasource, OGR_L_SetFeature() must be used afterwards. Or if this is a new feature, OGR_L_CreateFeature() must be used afterwards. Parameters: ----------- hFeat: handle to the feature that owned the field. iField: the field to set, from 0 to GetFieldCount()-1. nCount: the number of values in the list being assigned. panValues: the values to assign. GDAL 2.0 |
SetFieldDoubleList(Feature self, int id, int nList) void OGR_F_SetFieldDoubleList(OGRFeatureH hFeat, int iField, int nCount, const double *padfValues) Set field to list of doubles value. This function currently on has an effect of OFTIntegerList, OFTInteger64List, OFTRealList fields. This function is the same as the C++ method OGRFeature::SetField(). This method has only an effect on the in-memory feature object. If this object comes from a layer and the modifications must be serialized back to the datasource, OGR_L_SetFeature() must be used afterwards. Or if this is a new feature, OGR_L_CreateFeature() must be used afterwards. Parameters: ----------- hFeat: handle to the feature that owned the field. iField: the field to set, from 0 to GetFieldCount()-1. nCount: the number of values in the list being assigned. padfValues: the values to assign. |
SetFieldStringList(Feature self, int id, char ** pList) void OGR_F_SetFieldStringList(OGRFeatureH hFeat, int iField, CSLConstList papszValues) Set field to list of strings value. This function currently on has an effect of OFTStringList fields. This function is the same as the C++ method OGRFeature::SetField(). This method has only an effect on the in-memory feature object. If this object comes from a layer and the modifications must be serialized back to the datasource, OGR_L_SetFeature() must be used afterwards. Or if this is a new feature, OGR_L_CreateFeature() must be used afterwards. Parameters: ----------- hFeat: handle to the feature that owned the field. iField: the field to set, from 0 to GetFieldCount()-1. papszValues: the values to assign. List of NUL-terminated string, ending with a NULL pointer. |
SetFrom(Feature self, Feature other, int forgiving=1) -> OGRErr OGRErr OGR_F_SetFrom(OGRFeatureH hFeat, OGRFeatureH hOtherFeat, int bForgiving) Set one feature from another. Overwrite the contents of this feature from the geometry and attributes of another. The hOtherFeature does not need to have the same OGRFeatureDefn. Field values are copied by corresponding field names. Field types do not have to exactly match. OGR_F_SetField*() function conversion rules will be applied as needed. This function is the same as the C++ method OGRFeature::SetFrom(). Parameters: ----------- hFeat: handle to the feature to set to. hOtherFeat: handle to the feature from which geometry, and field values will be copied. bForgiving: TRUE if the operation should continue despite lacking output fields matching some of the source fields. OGRERR_NONE if the operation succeeds, even if some values are not transferred, otherwise an error code. |
SetFromWithMap(Feature self, Feature other, int forgiving, int nList) -> OGRErr OGRErr OGR_F_SetFromWithMap(OGRFeatureH hFeat, OGRFeatureH hOtherFeat, int bForgiving, const int *panMap) Set one feature from another. Overwrite the contents of this feature from the geometry and attributes of another. The hOtherFeature does not need to have the same OGRFeatureDefn. Field values are copied according to the provided indices map. Field types do not have to exactly match. OGR_F_SetField*() function conversion rules will be applied as needed. This is more efficient than OGR_F_SetFrom() in that this doesn't lookup the fields by their names. Particularly useful when the field names don't match. This function is the same as the C++ method OGRFeature::SetFrom(). Parameters: ----------- hFeat: handle to the feature to set to. hOtherFeat: handle to the feature from which geometry, and field values will be copied. panMap: Array of the indices of the destination feature's fields stored at the corresponding index of the source feature's fields. A value of -1 should be used to ignore the source's field. The array should not be NULL and be as long as the number of fields in the source feature. bForgiving: TRUE if the operation should continue despite lacking output fields matching some of the source fields. OGRERR_NONE if the operation succeeds, even if some values are not transferred, otherwise an error code. |
GetStyleString(Feature self) -> char const * const char* OGR_F_GetStyleString(OGRFeatureH hFeat) Fetch style string for this feature. Set the OGR Feature Style Specification for details on the format of this string, and ogr_featurestyle.h for services available to parse it. This function is the same as the C++ method OGRFeature::GetStyleString(). Parameters: ----------- hFeat: handle to the feature to get the style from. a reference to a representation in string format, or NULL if there isn't one. |
SetStyleString(Feature self, char const * the_string) void OGR_F_SetStyleString(OGRFeatureH hFeat, const char *pszStyle) Set feature style string. This method operate exactly as OGR_F_SetStyleStringDirectly() except that it does not assume ownership of the passed string, but instead makes a copy of it. This function is the same as the C++ method OGRFeature::SetStyleString(). Parameters: ----------- hFeat: handle to the feature to set style to. pszStyle: the style string to apply to this feature, cannot be NULL. |
Validate(Feature self, int flags=OGR_F_VAL_ALL, int bEmitError=TRUE) -> int int OGR_F_Validate(OGRFeatureH hFeat, int nValidateFlags, int bEmitError) Validate that a feature meets constraints of its schema. The scope of test is specified with the nValidateFlags parameter. Regarding OGR_F_VAL_WIDTH, the test is done assuming the string width must be interpreted as the number of UTF-8 characters. Some drivers might interpret the width as the number of bytes instead. So this test is rather conservative (if it fails, then it will fail for all interpretations). This function is the same as the C++ method OGRFeature::Validate(). Parameters: ----------- hFeat: handle to the feature to validate. nValidateFlags: OGR_F_VAL_ALL or combination of OGR_F_VAL_NULL, OGR_F_VAL_GEOM_TYPE, OGR_F_VAL_WIDTH and OGR_F_VAL_ALLOW_NULL_WHEN_DEFAULT with '|' operator bEmitError: TRUE if a CPLError() must be emitted when a check fails TRUE if all enabled validation tests pass. GDAL 2.0 |
FillUnsetWithDefault(Feature self, int bNotNullableOnly=FALSE, char ** options=None) void OGR_F_FillUnsetWithDefault(OGRFeatureH hFeat, int bNotNullableOnly, char **papszOptions) Fill unset fields with default values that might be defined. This function is the same as the C++ method OGRFeature::FillUnsetWithDefault(). Parameters: ----------- hFeat: handle to the feature. bNotNullableOnly: if we should fill only unset fields with a not-null constraint. papszOptions: unused currently. Must be set to NULL. GDAL 2.0 |
GetNativeData(Feature self) -> char const * const char* OGR_F_GetNativeData(OGRFeatureH hFeat) Returns the native data for the feature. The native data is the representation in a "natural" form that comes from the driver that created this feature, or that is aimed at an output driver. The native data may be in different format, which is indicated by OGR_F_GetNativeMediaType(). Note that most drivers do not support storing the native data in the feature object, and if they do, generally the NATIVE_DATA open option must be passed at dataset opening. The "native data" does not imply it is something more performant or powerful than what can be obtained with the rest of the API, but it may be useful in round-tripping scenarios where some characteristics of the underlying format are not captured otherwise by the OGR abstraction. This function is the same as the C++ method OGRFeature::GetNativeData(). Parameters: ----------- hFeat: handle to the feature. a string with the native data, or NULL if there is none. GDAL 2.1 See: https://trac.osgeo.org/gdal/wiki/rfc60_improved_roundtripping_in_ogr |
GetNativeMediaType(Feature self) -> char const * const char* OGR_F_GetNativeMediaType(OGRFeatureH hFeat) Returns the native media type for the feature. The native media type is the identifier for the format of the native data. It follows the IANA RFC 2045 (seehttps://en.wikipedia.org/wiki/Media_type), e.g. "application/vnd.geo+json" for JSon. This function is the same as the C function OGR_F_GetNativeMediaType(). Parameters: ----------- hFeat: handle to the feature. a string with the native media type, or NULL if there is none. GDAL 2.1 See: https://trac.osgeo.org/gdal/wiki/rfc60_improved_roundtripping_in_ogr |
SetNativeData(Feature self, char const * nativeData) void OGR_F_SetNativeData(OGRFeatureH hFeat, const char *pszNativeData) Sets the native data for the feature. The native data is the representation in a "natural" form that comes from the driver that created this feature, or that is aimed at an output driver. The native data may be in different format, which is indicated by OGR_F_GetNativeMediaType(). This function is the same as the C++ method OGRFeature::SetNativeData(). Parameters: ----------- hFeat: handle to the feature. pszNativeData: a string with the native data, or NULL if there is none. GDAL 2.1 See: https://trac.osgeo.org/gdal/wiki/rfc60_improved_roundtripping_in_ogr |
SetNativeMediaType(Feature self, char const * nativeMediaType) void OGR_F_SetNativeMediaType(OGRFeatureH hFeat, const char *pszNativeMediaType) Sets the native media type for the feature. The native media type is the identifier for the format of the native data. It follows the IANA RFC 2045 (seehttps://en.wikipedia.org/wiki/Media_type), e.g. "application/vnd.geo+json" for JSon. This function is the same as the C++ method OGRFeature::SetNativeMediaType(). Parameters: ----------- hFeat: handle to the feature. pszNativeMediaType: a string with the native media type, or NULL if there is none. GDAL 2.1 See: https://trac.osgeo.org/gdal/wiki/rfc60_improved_roundtripping_in_ogr |
SetFieldString(Feature self, int id, char const * value) void OGR_F_SetFieldString(OGRFeatureH hFeat, int iField, const char *pszValue) Set field to string value. OFTInteger fields will be set based on an atoi() conversion of the string. OFTInteger64 fields will be set based on an CPLAtoGIntBig() conversion of the string. OFTReal fields will be set based on an CPLAtof() conversion of the string. Other field types may be unaffected. This function is the same as the C++ method OGRFeature::SetField(). This method has only an effect on the in-memory feature object. If this object comes from a layer and the modifications must be serialized back to the datasource, OGR_L_SetFeature() must be used afterwards. Or if this is a new feature, OGR_L_CreateFeature() must be used afterwards. Parameters: ----------- hFeat: handle to the feature that owned the field. iField: the field to fetch, from 0 to GetFieldCount()-1. pszValue: the value to assign. |
Once called, self has effectively been destroyed. Do not access. For backwards compatibility only |
Set the values of fields by the given name
|
SetField(self, int id, char value) SetField(self, char name, char value) SetField(self, int id, int value) SetField(self, char name, int value) SetField(self, int id, double value) SetField(self, char name, double value) SetField(self, int id, int year, int month, int day, int hour, int minute, int second, int tzflag) SetField(self, char name, int year, int month, int day, int hour, int minute, int second, int tzflag) |
Exports a GeoJSON object which represents the Feature. The as_object parameter determines whether the returned value should be a Python object instead of a string. Defaults to False. The options parameter is passed to Geometry.ExportToJson() |
|
thisown
|
| Home | Trees | Indices | Help |
|
|---|
| Generated by Epydoc 3.0.1 on Mon Apr 26 14:28:38 2021 | http://epydoc.sourceforge.net |


#include <uwoptical-mpropagation.h>
Class used to represents the UWOPTICAL_MPROPAGATION.
Definition at line 58 of file uwoptical-mpropagation.h.
◆ UwOpticalMPropagation()
| UwOpticalMPropagation::UwOpticalMPropagation |
( |
| ) |
|
◆ ~UwOpticalMPropagation()
| virtual UwOpticalMPropagation::~UwOpticalMPropagation |
( |
| ) |
|
|
inlinevirtual |
◆ command()
| int UwOpticalMPropagation::command |
( |
int |
argc, |
|
|
const char *const * |
argv |
|
) |
| |
|
virtual |
TCL command interpreter.
It implements the following OTcl methods:
- Parameters
-
| argc | Number of arguments in argv. |
| argv | Array of strings which are the command parameters (Note that argv[0] is the name of the object). |
- Returns
- TCL_OK or TCL_ERROR whether the command has been dispatched successfully or not.
Definition at line 92 of file uwoptical-mpropagation.cpp.
◆ getBeta()
| double UwOpticalMPropagation::getBeta |
( |
Packet * |
p | ) |
|
Provide angle between transmitter and receiver.
- Parameters
-
| Packet* | Pointer to the packet that has to be received. |
- Returns
- the angle between transmitter and receiver.
Definition at line 191 of file uwoptical-mpropagation.cpp.
◆ getC()
| double UwOpticalMPropagation::getC |
( |
Packet * |
p = NULL | ) |
|
◆ getGain()
| double UwOpticalMPropagation::getGain |
( |
Packet * |
p | ) |
|
|
virtual |
Calculate the gain following the Lambert and Beer's law.
- Parameters
-
| Packet* | Pointer to the packet that has to be received. |
- Returns
- the gain due to the optical propagation.
Definition at line 269 of file uwoptical-mpropagation.cpp.
◆ getLambertBeerGain()
| double UwOpticalMPropagation::getLambertBeerGain |
( |
double |
d, |
|
|
double |
beta_ |
|
) |
| |
|
protectedvirtual |
Calculate the gain following the Lambert and Beer's law.
- Parameters
-
| d | Distance between transmitter and receiver. |
| beta | inclination angle between the transmitter and the receiver. |
- Returns
- the gain due to the optical propagation.
Definition at line 315 of file uwoptical-mpropagation.cpp.
◆ getLambertBeerGain_variableC()
| double UwOpticalMPropagation::getLambertBeerGain_variableC |
( |
double |
beta_, |
|
|
double |
min_depth_, |
|
|
double |
max_depth_ |
|
) |
| |
|
protected |
Calculate the gain following the Lambert and Beer's law in the case of variable c model.
- Parameters
-
| beta_ | |
| min_depth_ | the max between depth of rx and depth of tx. |
| max_depth_ | the min between depth of rx and depth of tx. |
- Returns
- the gain due to the optical propagation in the case of variable c model.
Definition at line 360 of file uwoptical-mpropagation.cpp.
◆ getTemperature()
| double UwOpticalMPropagation::getTemperature |
( |
double |
depth | ) |
|
Provide the temperature from LUT.
- Parameters
-
| depth | depth of the receiver. |
- Returns
- the temperature at certain depth.
Definition at line 430 of file uwoptical-mpropagation.cpp.
◆ getWossOrientation()
| double UwOpticalMPropagation::getWossOrientation |
( |
Position * |
src, |
|
|
Position * |
dest |
|
) |
| |
|
protected |
Calculate the inclination angle between the transmitter and the receiver.
- Parameters
-
| src | pointer to the transmitter position. |
| dest | pointer to the receiver position. |
- Returns
- the inclination angle between the transmitter and the receiver
Definition at line 174 of file uwoptical-mpropagation.cpp.
◆ initializeLUT()
| void UwOpticalMPropagation::initializeLUT |
( |
| ) |
|
|
protectedvirtual |
◆ isOmnidirectional()
| bool UwOpticalMPropagation::isOmnidirectional |
( |
| ) |
|
Provide if we are assuming omnidirectional tx and rx or not.
- Returns
- if it is omnidirectional or not.
Definition at line 214 of file uwoptical-mpropagation.cpp.
◆ linearInterpolator()
| double UwOpticalMPropagation::linearInterpolator |
( |
double |
x, |
|
|
double |
x1, |
|
|
double |
x2, |
|
|
double |
y1, |
|
|
double |
y2 |
|
) |
| |
|
protected |
Calculate the inclination angle between the transmitter and the receiver.
- Parameters
-
| src | pointer to the transmitter position. |
| dest | pointer to the receiver position. |
Definition at line 351 of file uwoptical-mpropagation.cpp.
◆ setWoss()
| void UwOpticalMPropagation::setWoss |
( |
bool |
flag | ) |
|
|
virtual |
◆ updateC()
| void UwOpticalMPropagation::updateC |
( |
double |
d | ) |
|
|
protected |
Set the attenuation coefficient from lookup table when both the nodes are alligned and at the same depth.
- Parameters
-
Definition at line 153 of file uwoptical-mpropagation.cpp.
◆ Ar_
| double UwOpticalMPropagation::Ar_ |
|
protected |
◆ At_
| double UwOpticalMPropagation::At_ |
|
protected |
◆ c_
| double UwOpticalMPropagation::c_ |
|
protected |
◆ debug_
| int UwOpticalMPropagation::debug_ |
◆ lut_c_
| LUT_c UwOpticalMPropagation::lut_c_ |
|
protected |
Lookup table map of the attenuation coefficient and the temperature versus the depth.
Definition at line 201 of file uwoptical-mpropagation.h.
◆ lut_file_name_
| string UwOpticalMPropagation::lut_file_name_ |
|
protected |
◆ lut_token_separator_
| char UwOpticalMPropagation::lut_token_separator_ |
|
protected |
◆ omnidirectional_
| bool UwOpticalMPropagation::omnidirectional_ |
|
protected |
Flag to set whether the system is omnidirectional or not.
By default it is false
Definition at line 196 of file uwoptical-mpropagation.h.
◆ theta_
| double UwOpticalMPropagation::theta_ |
|
protected |
◆ use_woss_
| bool UwOpticalMPropagation::use_woss_ |
|
protected |
◆ variable_c_
| bool UwOpticalMPropagation::variable_c_ |
|
protected |
Flag to set whether the attenuation is constant or not.
By default it is false
Definition at line 198 of file uwoptical-mpropagation.h.
The documentation for this class was generated from the following files:


FIONA CHANG
Email Me
Places I Want to Visit
- Barcelona
- London
- Berlin
- Honolulu
- Hong Kong
My Favorite Desserts
- Mocha Cheese Cake
- Macaroons
- Fruit Tart
- Pistachio Ice Cream
- Double Chocolate Chips Cookie
The Nopes
- Blue Cheese
- Kale
- Green Peas
- Cinnamon
- Black Beans


v2023.2.23¶
Update pymongo and interface for new API.
v2022.5.20¶
New module to create local MP database.
v0.7.0¶
Fix deprecation.
Ensure oxide types are handled properly in creating docs and querying for them.
v0.6.2¶
Minor bug fixes.
v0.6.1¶
Removed Materials Genomics UI. Pls use Flamyngo as an alternative.
v0.6.5¶
Proper specification of requirements.
v0.6.2¶
Update dependency versions.
v0.5.0¶
Updated scripts for new MongoClient.
v0.4.8¶
Update pymatgen vand other dependencies.
v0.4.1¶
Refactor of builders (mgbuild and matgendb.builders) to improve usability. Github issues #9 through #13.
Also for ‘builders’, added incremental building
Added modules dbgroup and dbconfig for more flexible and powerful configuration of multiple databases with a directory of configuration files.
v0.4.0¶
New mgvv diff features.
Configure from YAML file
Improved JSON output
Add JSON reports to a database
Sort numeric diffs by delta value
v0.3.9¶
mgvv diff HTML output can make they key field into a hyperlink using a user-provided prefix
Added brief introduction to mgvv in front page of Sphinx docs
v0.3.8¶
mgvv diff can perform numeric diffs. Better error handling.
v0.3.7¶
New package maintainer, Dan Gunter<EMAIL_ADDRESS>Added vv.diff package and associated mgvv diff subcommand, for taking the difference of two arbitrary MongoDB collections.
Some cleanup and simplification of config files. user and password are accepted as aliases for readonly_user and readonly_password.
v0.3.4¶
MAPI_KEY is now a db config file variable.
v0.3.3¶
Minor bug fix release.
v0.3.2¶
Add option to use the Materials API to obtain stability data during run insertion.
Materials Genomics UI now supports setting a limit on number of results returned.
Improvements to mgdb script to allow setting of hosts, etc.
v0.3.0¶
Significant update to materials genomics ui. Ability to export table data to CSV, XLS or PDF.
First vof RESTful interface implemented.


Wilma at the Jail
“Come in officers, let me introduce you to your murderer, Wilma. Let me walk you through her devious scheme.
After feigning exhaustion and excusing herself supposedly with the intention of going to bed, she returned downstairs to not only overhear Alex’s proposal to Jane but also his argument with Harry. She never was quite the same after Bahamas and I believe for years she secretly seethed with rage and jealousy directed towards Alex and Jane. I am sure what she overheard that night was the final straw that broke the camel’s back. Then and there she must have concocted her plan.
She waited until Harry returned to his room, crept into the kitchen and seized the knife, then probably approached Alex quite unassumingly in the dining room, not raising his suspicions until it was too late and the knife were already in his chest. From there she stole one of Harry’s boots and used it to make the incriminating shoeprint in the basement and made sure to mention to me hearing clomping steps in the hallway.
She preyed on poor Freddy’s low alcohol tolerance, coming into his room while he was passed out drunk and setting the time on his bedside clock back to 10:30 before waking him pretending to now be coming into his room amorously. I am sure she spiked one of the glasses of wine with one of her Ambien, making sure to set the clock back to midnight after he drifted off into a drug addled stupor rousing him momentarily enough for him to note the time as she left.”
Wilma says nothing, but the smouldering eyes speak volumes.
“She nearly would have gotten away with it, if not for a few small inconsistencies and my insomnia.”
“I want my lawyer.” She hisses through gritted teeth.


Throught the past year and half I've tried a variaty of different mind altering drugs. And one of the most eyecatching drugs was nitrous. Well last Saturday my friends( M and T ) and I wanted to try a drug that wasn't going to keep us up alnight, and thus nitrous was going to be the drug of choice. However none of us had any nor could we gain acess to any nitrous, so we decied to go to the local Wal-Mart and buy a few 16inch ballons, and a can of this inhalant that all 3 of us have been hearing about. This was a can of Duster. So we bought the Duster and went to my house for a night of fun.
We were all unsure of what the effects of the Duster would do, but the only way to find out was to do it. So T filled a ballon with the Duster and started to inhale and and exhale into the ballon, he did so for about 10 or 12 times until he let go of the ballon and fell back onto my bed while he laughed uncontrolably. After about 30 seconds he was fine again and told me that 'I had to try it!'. So T filled up a ballon for me. I inhaled the Duster which tasted nasty at first but after the first inhale I didn't notice, I held my nose while I was breathing, just to see if it would help, I did so untill I couldn't anymore, and then the fun began.
After about 30 to 45 seconds the effects faded away as quickly as they came. T then filled a ballon for M, M then took about 8 or 10 hits from the ballon untill he started to laugh and tell us about how he thought he had a small head. If you are looking for a drug that doesn't last long and is very fun while it lasts then Duster could be for you. But please BE CAREFUL. It can be VERY dangerous.
Experience Reports are the writings and opinions of the individual authors who submit them.
Some of the activities described are dangerous and/or illegal and none are recommended by Erowid.


In this event, you'll cross swords with another team in a race
to fill a crossword grid!
visibility
You can see your starting corner, plus any clue that you have a
letter in. You'll have to enter letters correctly to see more of
the grid.
navigating
Click in the grid or the list of clues to move around the grid. Type
letters to guess (the cursor will automatically advance along the
current clue).
guessing
A correct guess claims that square for your color. An incorrect guess
locks the square out for a little while. You can guess again after
that, or the other team might get it in the meantime!
hints
Click "reveal square" with a square selected to instantly claim it.
Hints regenerate after 30 seconds, so don't be afraid to use them.
victory
You can see your current score and a timer above the grid. If you
claim a majority of the grid, or have more squares than your opponent
when the timer runs out, you win!
replay
After the game ends, you can use the slider at the bottom to replay
all the moves.