add GeoNames lookup/create/edit as github/npm component importable into cwrc-writer entity dialogs

[ilovan]

This is the other place specific entity lookup that we need to implement, in some ways more essential than Geo Code.

Expected Behavior

Previous version of this lookup worked on a subset of the Geonames database of populated places, as I believe there is a limit on the # of calls that can be submitted dayly to the live version of Geonames before hitting a paywall. We would be OK with doing things the same way for now. @jchartrand , if you don't have access or are unable to find the "local" Geonames or the old lookup code, please let us know.

[jchartrand]

On Feb 12, 2018, at 1:32 PM, Mihaela Ilovan notifications@github.com wrote:

This is the other place specific entity lookup that we need to implement, in some ways more essential than Geo Code.

Expected Behavior

Previous version of this lookup worked on a subset of the Geonames database of populated places, as I believe there is a limit on the # of calls that can be submitted dayly to the live version of Geonames before hitting a paywall. We would be OK with doing things the same way for now. @jchartrand https://github.com/jchartrand , if you don't have access or are unable to find the "local” Geonames

Not sure what you mean by “local” geonames? Maybe this: the old version of the cwrc-writer used this URL for the geonames search:

http://cwrc-dev-01.srv.ualberta.ca/cwrc-mtp/geonames/

(taken from https://github.com/cwrc/DEPRECATED-CWRC-Writer/blob/5618be7b83ccd643d26709cf549edd0682fbfc81/src/js/writerConfig.js#L5)

but when trying to open that url in a browser I get an error:

[Error] Failed to load resource: Could not connect to the server. http://cwrc-dev-01.srv.ualberta.ca/cwrc-mtp/geonames/ http://cwrc-dev-01.srv.ualberta.ca/cwrc-mtp/geonames/

or the old lookup code, please let us know.

The old lookup code (if this is the old code: https://github.com/cwrc/CWRC-Dialogs/blob/master/js/cD.js ) returns:

http://www.geonames.org/geonameid

where the geonameid comes back from the geonames search. Which is likely fine.

Just need a live uri to hit for the search.

james

You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/cwrc/CWRC-PublicEntityDialogs/issues/19, or mute the thread https://github.com/notifications/unsubscribe-auth/AAhZXXS05jH4Tsj551HmnyvGKseo-xDrks5tUIOngaJpZM4SCn9R.

[jchartrand]

@ilovan @SusanBrown @jefferya Does CWRC have an account with GeoNames? i.e., one that I could use to make queries against the live geonames api? Or, in other words, an account I could use to login to:

http://www.geonames.org/manageaccount

and from there enable the free web services? Even if there is a quota, it would at least let me implement our lookup, and the quota might be fine for Texas demo.

[ilovan]

I have the password, how do you want me to pass it on to you?

On Wed, Feb 14, 2018 at 10:42 AM, James Chartrand notifications@github.com wrote:

@ilovan https://github.com/ilovan @SusanBrown https://github.com/susanbrown @jefferya https://github.com/jefferya Does CWRC have an account with GeoNames? i.e., one that I could use to make queries against the live geonames api? Or, in other words, an account I could use to login to:

http://www.geonames.org/manageaccount

and from there enable the free web services? Even if there is a quota, it would at least let me implement our lookup, and the quota might be fine for Texas demo.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/cwrc/CWRC-PublicEntityDialogs/issues/19#issuecomment-365687030, or mute the thread https://github.com/notifications/unsubscribe-auth/AGS1hpVRVWcN42T5cvNvbMmxcz0dAINdks5tUxsBgaJpZM4SCn9R .

-- Mihaela Ilovan

Project Manager Canadian Writing Research Collaboratory University of Alberta 4-20 Humanities Centre Edmonton, AB Canada T6G 2E5

780-966-4507 ilovan@ualberta.ca

[jchartrand]

@ilovan @jefferya @SusanBrown

Duplicating email from last night for posterity:

I’ve mostly got the geonames lookup done, and you can see it as-is in dev:

https://dev-cwrc-writer.cwrc.ca/

But, two things:

1. Not surprisingly, we’ll need another proxy to:

http://www.geonames.org

to allow full page preview of a place. Maybe name it https://geonames.lookup.services.cwrc.ca?

2. Geonames does have a secure endpoint for the lookup (although not for full page preview) and, for whatever reason, the secure endpoint seems to allow queries without a user account. I don’t know if that’s a soon-to-be-corrected oversight or glitch on their part, but at least the lookup is up and running for you to try. I’ll also try it with the cwrc geonames account once I’ve got those credentials.

[jefferya]

Registered subdomain as per https://github.com/cwrc/geonames-entity-lookup/blob/master/README.md.

Once the DNS entry propagates throughout the internet, https://geonames.lookup.services.cwrc.ca should start working (it might already be at your locale or within 30mins or so)

[jchartrand]

I think someone might have accidentally moved this into the Review/QA pipeline. It was still ongoing, but has now been fixed. I have added a link to the geonames search result, and disabled the full page preview for geonames. The link opens the geonames page in a separate tab. here is the email exchange about this:

On Feb 15, 2018, at 4:20 PM, Susan Brown sbrown@uoguelph.ca wrote:

Thanks for all the effort going into this. If we don’t get this in place before next week that is not a tragedy, however. A link that the user could click would be fine for now. I have seen tools that used genomes that did provide dynamic map rendering in the browser (James, I believe we saw one at that OA workshop eons ago) so I think there’s some way of doing it,

It works fine with the CWRC dialogs when the original CWRC page is loaded with HTTP (rather than HTTPS), which may be how the tools you saw worked. The problem is that using HTTPS requires us to pipe calls to geonames through a proxy, which changes the referring url, which in turn breaks the Google API key requirement.

We could also effectively recreate the geonames web page ourselves (in which case we could use the CWRC Google key, which would correct the latest problem), but that would be a fair bit of work.

I’ll add a link somewhere in the geonames search result, and disable the full page preview for geonames.

james

but like I say, not essential by any means.

On Feb 15, 2018, at 4:13 PM, Jeffery Antoniuk jeffery.antoniuk@ualberta.ca wrote:

Hi James,

Tried the above but no joy. Went for lunch and have been checking to see if I missed something or if there is another way.

Cheers, ~Jeff

On Thu, Feb 15, 2018 at 12:20 PM, Jeffery Antoniuk jeffery.antoniuk@ualberta.ca wrote: Hi James,

Thanks for doing the legwork. I'll try and see what happens.

Cheers, ~jeff

On Thu, Feb 15, 2018 at 12:16 PM, James Chartrand jc.chartrand@gmail.com wrote: Thanks Jeff,

I was wrong to think that we could set the cwrc Google api key on the call to Google Maps, because the call to Maps is actually made by GeoNames (presumably with their own Google key) from their html page for a given place. And a Google key can apparently only be used when requests come from specific referring pages that have been set for the key. When we pipe all this through the CWRC proxy, the referring page now becomes the proxy url, which of course isn’t one of the referring pages set on the GeoNames Google API key:

I don’t know if we can somehow alter (presumably in the reverse proxy) the referring page, so that it is instead set as the geonames page that we are proxying? This article makes it sound like we could: https://benjaminhorn.io/code/apache-reverse-proxy/ using something like this: ServerName 10.0.0.10 # Set url to proxy ProxyPass / http://hosts.domain.dev/ ProxyPassReverse / http://hosts.domain.dev/ # Set location # Set url ProxyPass http://hosts.domain.dev/ # Ouput html from proxy filter SetOutputFilter proxy-html # Add referer hack (if the site uses referrer as security) Header add referer "http://hosts.domain.dev" RequestHeader set referer "http://hosts.domain.dev" but I defer to you Jeff. I just don’t know apache well enough to know if this is feasible. Otherwise, I can’t easily see a solution. If anyone else can suggest something I’d sure appreciate it. The best I can think of is to put a link in the geonames result that allows the user to open a new browser tab/window for the geonames url. I’ve also spent a long time trying to find some other geonames page (that does’t use Google maps or that directly uses https so we don’t have to proxy) that we could show in the preview, but have had no luck. I could also email the geonames people, but I don’t know much about them, and don’t see a whole lot of information on their web page. Do any of you know much about them? Should I just go ahead and email them? james On Feb 15, 2018, at 1:14 PM, Jeffery Antoniuk wrote: Hi James, cwrc@ualberta.ca does have an Google Developer account (it contains an API key the OAuth 2.0 client IDs). Here is the key: AIzaSyCvA_Hyyf1d7sjGWtov89mRG6OF2Wq4BrU https://console.developers.google.com/apis Cheers, ~Jeff On Thu, Feb 15, 2018 at 10:34 AM, James Chartrand wrote: Thanks Jeff, Yes, the proxy works (thank you!) and you can see it working on dev-cwrc-writer.cwrc.ca (when you try to tag a place, and then click one of the resulting geonames results). But, there is of course a new problem. The geonames page actually pulls in a Google map using the Google Maps JavaScript API, and apparently, to use that map from a proxy, we need to provide a Google API key, which is gotten from a Google Developers account. So, my question is: does CWRC have a Google Developers account? james > On Feb 15, 2018, at 12:21 PM, Jeffery Antoniuk wrote: > > Fyi, geoname.lookup.services.cwrc.ca DNS entry has propagated to the UofA. The https end-point appears to be working. Let me know if otherwise. > > Cheers, > ~Jeff > > On Wed, Feb 14, 2018 at 6:06 PM, James Chartrand wrote: > I’ve mostly got the geonames lookup done, and you can see it as-is in dev: > > https://dev-cwrc-writer.cwrc.ca/ > > But, two things: > > 1. Not surprisingly, we’ll need another proxy to: > > http://www.geonames.org > > to allow full page preview of a place. Maybe name it https://geonames.lookup.services.cwrc.ca? > > 2. Geonames does have a secure endpoint for the lookup (although not for full page preview) and, for whatever reason, the secure endpoint seems to allow queries without a user account. I don’t know if that’s a soon-to-be-corrected oversight or glitch on their part, but at least the lookup is up and running for you to try. I’ll also try it with the cwrc geonames account once I’ve got those credentials. > > james > > >

[ilovan]

confirmed in dev-06 and prod Git-Writer