[geomoose-psc] Google Geocoder

Fri Jul 1 09:16:03 PDT 2016

My vote would be for “a”, with a Note about probable deprecation of service in the demo.  Then figure out what the next version will look like.

bobb

On Jul 1, 2016, at 11:08 AM, Dan Little <theduckylittle at gmail.com<mailto:theduckylittle at gmail.com>> wrote:

Should we:
a. Deliver 2.9.1 with Google.
b. Deliver 2.9.1 without any 'enabled' Geocoder (comment out the entry
in the mapbook) and write a quick "How To Enable The Googs".
c. Deliver 2.9.1 with an alternative geocoder to replace geocoder.us<http://geocoder.us>
and leave the google code dormant as it was in 2.9.

Aside:
I'm not sure which of a-c would necessitate switching to 2.10 but
these are all methods for addressing the same 'bug.'

On Fri, Jul 1, 2016 at 10:41 AM, Eli Adam <eadam at co.lincoln.or.us<mailto:eadam at co.lincoln.or.us>> wrote:
There is this, https://mapzen.com/products/search/?lng=-124.01556&lat=44.66743&zoom=12
not certain on licensing but seems very unrestricted.

On Fri, Jul 1, 2016 at 8:03 AM, Dan Little <theduckylittle at gmail.com<mailto:theduckylittle at gmail.com>> wrote:
We could ship 2.9.1 with Google and do a next-step.  2.9.1, I think,
is basically ready for testing.

On Fri, Jul 1, 2016 at 9:58 AM, James Klassen <klassen.js at gmail.com<mailto:klassen.js at gmail.com>> wrote:
It may be old school, but I didn't see any good alternatives mentioned
though.

1. Violate Google TOS

2. Cripple the Demo, but let people add it back.  Also, removes it from
regular testing.

3. Who needs geocoders anyway?  This might be OK for the parcel app users
because they probably already have better local data anyway.  But it doesn't
help anyone else.

Also, this means the 2.9.0 on OSGeo Live should be fixed.

On Jul 1, 2016 09:49, "Dan Little" <theduckylittle at gmail.com<mailto:theduckylittle at gmail.com>> wrote:

geocoder.us<http://geocoder.us> was useful but the momentum for geocoding TIGER files in
Berkeley databases is not considered particularly modern.

On Fri, Jul 1, 2016 at 9:48 AM, James Klassen <klassen.js at gmail.com<mailto:klassen.js at gmail.com>>
wrote:
I think an email saying we noticed it was down and offering to help
maintain
it might be worthwhile.

Yes, a nice courtesy.

I guess my real question is if geocoder.us<http://geocoder.us> is still useful to the
community
or has the world moved on to something else (OSM)?  If it is useful to
us
and to others, we should look into helping maintain/support it.

On Jul 1, 2016 09:37, "Dan Little" <theduckylittle at gmail.com<mailto:theduckylittle at gmail.com>> wrote:

Schuyler Earl. Good luck.  It's like 12 projects ago for him.

On Fri, Jul 1, 2016 at 9:35 AM, James Klassen <klassen.js at gmail.com<mailto:klassen.js at gmail.com>>
wrote:
Do we know who was running geocoder.us<http://geocoder.us>?  Maybe we could get it fixed.

On Jul 1, 2016 05:03, "Dan Little" <theduckylittle at gmail.com<mailto:theduckylittle at gmail.com>> wrote:

Hey Folks,

geocoder.us<http://geocoder.us> appears to be defunct. The website doesn't load and
there
certainly does not appear to be any geocodes being returned.  This
was
our default geocoder.

The other geocoder with which we have code is the Google Geocoder.
I'm fixing it up right now to work (it wasn't) and to also include
an
appropriate credit/disclaimer.  However, I'm a bit worried as we are
probably running afoul the Google TOS.  I see a few options:

1. Run with it. We're a very small fish in a very large pond.
2. Do not include a Geocoder by default but provide instructions for
adding back in the Google geocoder (including setting an API key).
This runs ... "less" afoul the TOS depending on how you read them.

Running a demo of geocoding in GeoMoose seems fine as a demonstration.
We probably shouldn't distribute a working demo with an API key.
Right now, it would take work to run a different demo than what we
distribute as the demo.  So that makes a case for remove it from the
demo.

With something like this, it seems providing directions and maybe an
example (but not working with an API key) is the correct path.  That
allows the user to evaluate the TOS and whether they are appropriate
for them.

3. Remove all the geocoders.  They're all broken.  Folks may not
like
to see the code disappear.

Long term (and I will file a ticket to this regard) we should
probably
write our own Geocoder instructions or write a crappy
DIY/off-the-shelf-libs geocoder that works with the default parcel
data.

Let's avoid writing geocoders, even lame parcel ones.

Best regards, Eli

Cheers,

-Duck

Reference tickets:
- https://github.com/geomoose/geomoose/issues/150
- https://github.com/geomoose/geomoose/issues/152
_______________________________________________
geomoose-psc mailing list
geomoose-psc at lists.osgeo.org<mailto:geomoose-psc at lists.osgeo.org>
http://lists.osgeo.org/mailman/listinfo/geomoose-psc
_______________________________________________
geomoose-psc mailing list
geomoose-psc at lists.osgeo.org<mailto:geomoose-psc at lists.osgeo.org>
http://lists.osgeo.org/mailman/listinfo/geomoose-psc
_______________________________________________
geomoose-psc mailing list
geomoose-psc at lists.osgeo.org<mailto:geomoose-psc at lists.osgeo.org>
http://lists.osgeo.org/mailman/listinfo/geomoose-psc

"I'm not interested in preserving the status quo; I want to overthrow it.”
-  Niccolo Machiavelli

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/geomoose-psc/attachments/20160701/ec921d87/attachment-0001.html>