I have installed nominatim 4.1.0 (tokenizer= ICU) via following instructions on nominatim documentation, added wikipedia data during the installation, and imported an updated pbf file from geofabrik.de.
All works but when I sent some kind of request (e.g. Cagliari via Roma) the answer I get from Nominatim Website (https://nominatim.openstreetmap.org/) and my local installation are very different. The right results are on nominatim website of course.
The problems seems to be with the search candidate algorithm or the attribuition/calc of AdressImportance parameter.
The very strange thing is that I get these wrong results only for some requests.
There is any particular parameter to set or anything else to verify?
I hope it is clear for you and even small advice or comment would be very helpful for me
Thanks
Michele
After a discussion with the maintainers (https://github.com/osm-search/Nominatim/discussions/2839), I found an acceptable solution by editing the Geocode.php file line as follows:
$this->iLimit = $iLimit + max($iLimit, 150)
the result is not exactly the same as that of the online version but it works fine for me
Consider this module App::TimeTracker. If you click on the tracker link in the SYNOPSIS section you end up here whereas you should have ended up here. The Pod source code responsible for the behavior is given here, which shows that the following Pod formatting code was used:
L<tracker>
I can fix the problem by providing an absolute link instead:
L<tracker|https://metacpan.org/pod/release/DOMM/App-TimeTracker-3.000/bin/tracker>
but this fixes the link to version 3.000 which may change in the future.
So how should this be done in general?
Use the full path without the version number: https://metacpan.org/pod/distribution/App-TimeTracker/bin/tracker.
The problem is that tracker_bash_autocomplete is not being indexed correctly as documentation by MetaCPAN. The NAME section has a very specific format based on manpages which must be adhered to for MetaCPAN to know how to link to your documentation. Putting tracker bash autocomplete before the hyphen makes MetaCPAN index it as tracker.
=head1 NAME
tracker_bash_autocomplete - whatever
Some of my doxygen documentation need to refer to pages in the
company's wiki. I would prefer if these references resulted in working
hypertext links in the generated documentation. I could of course
achieve this by writing:
/// Name of page
or alternatively using Markdown syntax:
/// [Name of wiki page](http://long-URL.com/wiki/index.php?Name-of-page)
Unfortunately I have to give the full URL at every link in both cases,
and when (as has already happened) the base URL of our company/wiki
changes, all the URLs needs updating.
I therefore wonder if Doxygen has some support to avoid having to
hardcode the entire URL at every link?
For comparison, wikis use "InterMap" or "InterWiki", to define
prefixes that allow a shorthand notation for quickly referring to pages
on another web site. Example:
See WikiPedia:InterWiki_Links for more details.
So if possible I would like to let the Doxygen documentation contain
something like:
// See CompanyWiki:Name_of_wiki_page for bla bla
Some references:
Automatic link generation - http://www.doxygen.nl/manual/autolink.html
InterWiki - https://www.mediawiki.org/wiki/Manual:Interwiki
PmWiki/InterMap - http://www.pmwiki.org/wiki/PmWiki/InterMap
You could define an alias in the config file:
ALIASES += WikiPedia{2}="\2"
and then use it in your comments like so
See \WikiPedia{InterWiki_Links,Interwiki Links} for more details.
See also http://www.doxygen.org/manual/custcmd.html for more info.
This is my 1st question on this forum... So, please, be indulgent !
I'm using TYPO3 4.7.11 (PHP 5.3.3) with extension direct_mail 3.1.1 for the intranet site of a non-profit firm.
My problem (maybe connected to Bug #51583 : http://forge.typo3.org/issues/51583) is that, after numerous tests and attempts, it seems impossible to have an updated version of a page saved as draft for newsletter in an automatic scheduler driven way : the same newsletter is produced with the same informations that were already there on the day it was first created and saved.
The specific page used for newsletter includes a content element 'Menu/Sitemap' with 'Recently updated pages' as 'Menu type'. It has been saved as 'draft (for recurring sendings)' in Direct Mail.
The scheduler contains these 2 tasks with recurring type :
- Direct Mail: Create Mail from Draft (direct_mail)
- Direct Mail: Mailing Queue (direct_mail)
Note : the manual way is fully functional and the newsletter produced is really updated. Same with option "Testmail - Simple" !
So, my problem seems to be linked to the automatic scheduled mailing ! It looks as if the newsletter draft has turned into a freezed snapshot of a specific moment and that Typo3 is unable to update/recalculate this page when invoked in scheduler mode.
On the web, I saw reported problems that could be related like "When mails get sent via the scheduler the same subject is used for all sendings ( https://review.typo3.org/21313 )" and "Adding hooks when sending direct mails via scheduler ( forge.typo3.org/issues/48994 )", but these issues seem to be fixed with direct_mail 3.1.1 version.
I made these observations and, in my opinion, there is some relevancy :
1.There is no domain proposed in the 'Domain of internal links' drop-down list in 'Set default values for mail content fetching options' in Direct Mailer, and yet I have a single record in sys_domain table with a domain name (with no protocol and no final slash). Is there a reason why this record is not considered good, or isn't it the right table ? (uid=3, pid, tstamp, crdate, cruser_id, hidden, sorting, prepend_params and forced=0, redirectHttpStatusCode=301, domain_name=site.subdomain.domain, redirectTo=)
2.In the Typo 3 Log, I get this systematic error message for user _cli_scheduler#LIVE :
Core: Error handler (BE): PHP Warning: Invalid argument supplied for
foreach() in
...typo3conf/ext/direct_mail/Classes/Scheduler/MailFromDraft.php line
125.
The concerned part of MailFromDraft.php is this function : initializeHookObjects
...
/*
* Initializes hook objects for this class
*
* #return void
*/
function initializeHookObjects() {
foreach ($GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['direct_mail']['mailFromDraft'] as $hookObj) {
$hookObjectInstance = t3lib_div::getUserObj($hookObj);
if (is_object($hookObjectInstance) && ($hookObjectInstance instanceof x_directmail_Scheduler_MailFromDraftHook)) {
$this->hookObjects[] = $hookObjectInstance;
}
}
}
...
I'm not sure of understanding very clearly the origin and the use of the hook Object... (in spite of this interesting article by Robert Lemke : typo3.org/documentation/article/how-to-use-existing-hooks-in-your-own-extension/ )
3.Nothing like the apparently requested GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['direct_mail']['mailFromDraft'] seems to exist in TYPO3_CONF_VARS (Global configuration).
Can anybody give me an advice or a clue about what's going on and why I can't get a weekly updated newsletter with the scheduler ? I feel a bit confused !
Thanks in advance for any suggestion or solution (if a miracle is possible).
Greetings.
P-H SILLIAU
I've read about this issue before, but couldn't remember where.
Googling "direct_mail draft (for recurring sendings)" helped.
Try this bug: http://forge.typo3.org/issues/4421
User Markus says:
Things work fine, when you set a domain-record in your system and
select it in the direct_mail settings!
If you don't have a domain-record and specify it in the direct_mail
setup you're able to send normal newsletters, but if you try the
draft-functionality it won't work because the getUrlBase function in
class.tx_directmail_static.php returns an unsuable URL to the System
so it can't use the fetchHTML($file) and quits - therefore not
replacing the old draft contents created when starting the first time.
I don't really get why this works the first time you set up the draft
though....
So setting up the domain-record is a work-around that works.
I hope it does!
Probably, you will find more related topics.
Else, workarounds would be
re-considering the task. As it's a NPO intranet, maybe requirements are not that required suddenly, if asked again :-)
setting up a custom notification tool that only does that precise job.
To put an end to this problem, after many attempts (and informations gleaned from the internet), here is the solution we finally used in our specific case to make the newsletter work :
1st. We created a record in table sys_domain. This was a recurrent instruction in the manual and the forums, and it was IMHO legitimate.
Important : note that the redirectTo field had to remain empty, due to global malfunction of the site if filled (whatever we put in it like /, /var/www/sitename, ...)
2nd. All images, CSS, JS included in template had to be hardcoded (i.e. http ://site/fileamin/images/xxx.png for instance). If we didn't do that, the result would have been an abort in the production of the newletter : Not Found... Maybe, by digging a bit deeper, should we be able to find a parameter we forgot or neglected in some way to solve this issue...
3rd. In the newsletter template TS setup, we added these 2 parameters :
mod.web_modules.dmail.use_domain=[uid of sys-domain]
config.absRefPrefix = / (in order to get rid of PHP DOCUMENT_ROOT (or TYPO3_DOCUMENT_ROOT ?) otherwise wrongly present in all generated links.)
The result is now a well dynamically-generated newsletter, the date is OK, all links are correct and realUrl-compliant (no ../index.php?id=nnn) .... and you know what ?... We're happy ! :-)
Hope it will help !
Many thanks to everybody who answered (Markus, Urs...) or even thought of a possible solution...
P-H Silliau
What would be best way to conditionalize text (not code).
There are 3 levels of documentation that I want conditionalized and tagged as:
Developer – This would be documentation that I don’t want doxygen to output at all. Such as notes to developers.
Internal – Information visible only for internal versions of documentation.
NDA - Information for customers plus anything not tagged as Developer or Internal; a subset of the Internal docs and would filter out internal websites for example.
There are a number of doxygen commands and configuration options which will help you achieve this. These include \internal and \endinternal. From the doxygen manual:
\internal This command starts a documentation fragment that is meant for internal use only.
You can use INTERNAL_DOCS in the config file to show (YES) or hide (NO) the internal documentation.
To address the three versions of documentation you want:
Developer: Use standard C/C++ comments, /* ... */. These won't be touched by doxygen.
Internal: For documentation only for internal use, use doxygen comments, /** ... */, and wrap these parts of the documentation with the \internal and \endinternal commands. When distributing the documentation internally set the configuration file option INTERNAL_DOCS to YES when building the documentation.
NDA: For documentation visable to the customer simply use doxygen comments /** ... */ and set the configuration optionINTERNAL_DOCS to NO in the configuration file when building the documentation.