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

[jchartrand]

https://developers.google.com/maps/documentation/geocoding/intro

[jchartrand]

So, as far as I can tell, looking at this today, the Google Geocoding Service is meant to be used with Google Maps.

From https://developers.google.com/maps/documentation/geocoding/start :

"Geocoding is the process of converting addresses (like "1600 Amphitheatre Parkway, Mountain View, CA") into geographic coordinates (like latitude 37.423021 and longitude -122.083739), which you can use to place markers or position the map."

The Geocoding also returns a Google ‘place id’ (https://developers.google.com/places/place-id), which is not, however, a URI.

Form that site, "Place IDs uniquely identify a place in the Google Places database and on Google Maps”

A place id looks like: ChIJPar2cpiILIgR3Nn4G5_bzDo.

I’m happy for someone else to tell me if I’m looking at the wrong site, or have overlooked something.

[ilovan]

I believe the version of GeoCode installed in the old CWRC-Writer lookups was searching for the address (it had search suggestion / autocomplete) enabled and no disambiguation box. Can we go with that set up here?

[jchartrand]

I don’t know how that geocode lookup was being used by the old lookups, because the result that comes back from geocode doesn’t have a uri. It’s got lat/long and a google place id. My best guess is that the google place id was being used. But, again, that is an id like this:

ChIJF5T6z--FLIgRZ267H-MlPUU

We can’t simply stick that into the ref attribute of an entity tag, because it would a be meaningless string. We would have to say that it is a google id. But that would take a lot of change to the tagging code, and to the entity lookups.

We could alternatively turn that id into a url, as described here:

https://developers.google.com/places/web-service/details

So, like:

https://maps.googleapis.com/maps/api/place/details/json?placeid=ChIJN1t_tDeuEmsRUsoyG83frY4&key=YOUR_API_KEY

which returns info about the place. But, as you can see, an api key is needed, so again using that url doesn’t seem all that useful.

Can we talk to whoever created that geocode lookup for CWRC?

For reference, here is what is returned from geocode (using the uri from the old CWRC dialogs code) for a query on ‘guelph’:

http://maps.googleapis.com/maps/api/geocode/xml?address=guelph

OK locality political Guelph, ON, Canada Guelph Guelph locality political Wellington County Wellington County administrative_area_level_2 political Ontario ON administrative_area_level_1 political Canada CA country political 43.5448048 -80.2481666 APPROXIMATE 43.4738450 -80.3269451 43.5950210 -80.1533910 43.4738450 -80.3269451 43.5950210 -80.1533910 ChIJa_upw9CaK4gRYBsjxyh7AwU

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

I believe the version of GeoCode installed in the old CWRC-Writer lookups was searching for the address (it had search suggestion / autocomplete) enabled and no disambiguation box. Can we go with that set up here?

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub, or mute the thread.

[jchartrand]

With more digging into the old code, I see that it was taking the ‘formatted_address’ and sticking it onto the end of:

https://www.google.ca/maps/place/

So, for the guelph example, the entity lookup would return a URI like this:

https://www.google.ca/maps/place/Guelph,ON,Canada

If you go to that url you will see that it opens a google maps page for Guelph.

This seems a bit brittle. If Google ever changes what they resolve for the given formatted address (which they might well - I can’t imagine that they guarantee in perpetuity what’s returned for a formatted address string, whereas they might for their placeId) then the URI breaks.

james

On Feb 12, 2018, at 1:38 PM, James Chartrand jc.chartrand@gmail.com wrote:

I don’t know how that geocode lookup was being used by the old lookups, because the result that comes back from geocode doesn’t have a uri. It’s got lat/long and a google place id. My best guess is that the google place id was being used. But, again, that is an id like this:

ChIJF5T6z--FLIgRZ267H-MlPUU

We can’t simply stick that into the ref attribute of an entity tag, because it would a be meaningless string. We would have to say that it is a google id. But that would take a lot of change to the tagging code, and to the entity lookups.

We could alternatively turn that id into a url, as described here:

https://developers.google.com/places/web-service/details

So, like:

https://maps.googleapis.com/maps/api/place/details/json?placeid=ChIJN1t_tDeuEmsRUsoyG83frY4&key=YOUR_API_KEY

which returns info about the place. But, as you can see, an api key is needed, so again using that url doesn’t seem all that useful.

Can we talk to whoever created that geocode lookup for CWRC?

For reference, here is what is returned from geocode (using the uri from the old CWRC dialogs code) for a query on ‘guelph’:

http://maps.googleapis.com/maps/api/geocode/xml?address=guelph

OK locality political Guelph, ON, Canada Guelph Guelph locality political Wellington County Wellington County administrative_area_level_2 political Ontario ON administrative_area_level_1 political Canada CA country political 43.5448048 -80.2481666 APPROXIMATE 43.4738450 -80.3269451 43.5950210 -80.1533910 43.4738450 -80.3269451 43.5950210 -80.1533910 ChIJa_upw9CaK4gRYBsjxyh7AwU

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

I believe the version of GeoCode installed in the old CWRC-Writer lookups was searching for the address (it had search suggestion / autocomplete) enabled and no disambiguation box. Can we go with that set up here?

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub, or mute the thread.

[ilovan]

It looks like the option described by them is more likely to stay consistent:

So, like:

https://maps.googleapis.com/maps/api/place/details/json?placeid=ChIJN1t_tDeuEmsRUsoyG83frY4&key=YOUR_API_KEY

which returns info about the place. But, as you can see, an api key is needed, so again using that url doesn’t seem all that useful.

So if I get this straight, we should be able to use that URL within CWRC, but if someone else wanted to use it in a different context, they would need to provide their own API key? (apologies if I am being dense here)

[jchartrand]

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

It looks like the option described by them is more likely to stay consistent:

So, like:

https://maps.googleapis.com/maps/api/place/details/json?placeid=ChIJN1t_tDeuEmsRUsoyG83frY4&key=YOUR_API_KEY https://maps.googleapis.com/maps/api/place/details/json?placeid=ChIJN1t_tDeuEmsRUsoyG83frY4&key=YOUR_API_KEY which returns info about the place. But, as you can see, an api key is needed, so again using that url doesn’t seem all that useful.

So if I get this straight, we should be able to use that URL within CWRC, but if someone else wanted to use it in a different context, they would need to provide their own API key? (apologies if I am being dense here)

Yes, they would have to provide their own key, which would be totally confusing for someone coming along later and seeing this URI out of the CWRC context, in a TEI doc that might have at some point been edited with the CWRC-Writer, but is now being viewed in something like Oxygen.

More importantly, if the point of someone using these place lookups is to add a URI to the ref attribute of a place entity - to uniquely identity that place using a shared identifier - this doesn’t do it. This URI doesn’t uniquely identify the place using an identifier that can be shared with others. It’s not an identifier. It’s a browser link.

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

[ilovan]

Hm, I get it now why Michael and Jeff decided in the past to go with https://www.google.ca/maps/place/Guelph,ON,Canada, even if this is also not-technically-an -identifiers, also.

I think @SusanBrown should probably weigh in here as well.

[jchartrand]

I’m not sure this was Michael and Jeff. I thought this code was developed by someone else.

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

Hm, I get it now why Michael and Jeff decided in the past to go with https://www.google.ca/maps/place/Guelph,ON,Canada https://www.google.ca/maps/place/Guelph,ON,Canada, even if this is also not-technically-an -identifiers, also.

I think @SusanBrown https://github.com/susanbrown should probably weigh in here as well.

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

[ilovan]

It was initially developed by the Arts Resource Centre here at the UofA, but after that Michael and Jeff spent some time on it as well.

On Mon, Feb 12, 2018 at 12:31 PM, James Chartrand notifications@github.com wrote:

I’m not sure this was Michael and Jeff. I thought this code was developed by someone else.

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

Hm, I get it now why Michael and Jeff decided in the past to go with https://www.google.ca/maps/place/Guelph,ON,Canada < https://www.google.ca/maps/place/Guelph,ON,Canada>, even if this is also not-technically-an -identifiers, also.

I think @SusanBrown https://github.com/susanbrown should probably weigh in here as well.

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub < https://github.com/cwrc/CWRC-PublicEntityDialogs/issues/11# issuecomment-365033534>, or mute the thread https://github.com/ notifications/unsubscribe-auth/AAhZXWphS7i7KHA0JvR2zyJgOamJKY 8lks5tUI_sgaJpZM4PBjcM.

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

-- 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