Quantcast

Google Geocoder

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Google Geocoder

Dan Little-2
Hey Folks,

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

Cheers,

-Duck

Reference tickets:
- https://github.com/geomoose/geomoose/issues/150
- https://github.com/geomoose/geomoose/issues/152
_______________________________________________
geomoose-psc mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/geomoose-psc
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Google Geocoder

James Klassen-2

Do we know who was running geocoder.us?  Maybe we could get it fixed.


On Jul 1, 2016 05:03, "Dan Little" <[hidden email]> wrote:
Hey Folks,

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

Cheers,

-Duck

Reference tickets:
- https://github.com/geomoose/geomoose/issues/150
- https://github.com/geomoose/geomoose/issues/152
_______________________________________________
geomoose-psc mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/geomoose-psc

_______________________________________________
geomoose-psc mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/geomoose-psc
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Google Geocoder

Dan Little-2
Schuyler Earl. Good luck.  It's like 12 projects ago for him.

On Fri, Jul 1, 2016 at 9:35 AM, James Klassen <[hidden email]> wrote:

> Do we know who was running geocoder.us?  Maybe we could get it fixed.
>
>
> On Jul 1, 2016 05:03, "Dan Little" <[hidden email]> wrote:
>>
>> Hey Folks,
>>
>> 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.
>> 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.
>>
>> Cheers,
>>
>> -Duck
>>
>> Reference tickets:
>> - https://github.com/geomoose/geomoose/issues/150
>> - https://github.com/geomoose/geomoose/issues/152
>> _______________________________________________
>> geomoose-psc mailing list
>> [hidden email]
>> http://lists.osgeo.org/mailman/listinfo/geomoose-psc
_______________________________________________
geomoose-psc mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/geomoose-psc
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Google Geocoder

James Klassen-2

I think an email saying we noticed it was down and offering to help maintain it might be worthwhile.

I guess my real question is if 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" <[hidden email]> wrote:
Schuyler Earl. Good luck.  It's like 12 projects ago for him.

On Fri, Jul 1, 2016 at 9:35 AM, James Klassen <[hidden email]> wrote:
> Do we know who was running geocoder.us?  Maybe we could get it fixed.
>
>
> On Jul 1, 2016 05:03, "Dan Little" <[hidden email]> wrote:
>>
>> Hey Folks,
>>
>> 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.
>> 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.
>>
>> Cheers,
>>
>> -Duck
>>
>> Reference tickets:
>> - https://github.com/geomoose/geomoose/issues/150
>> - https://github.com/geomoose/geomoose/issues/152
>> _______________________________________________
>> geomoose-psc mailing list
>> [hidden email]
>> http://lists.osgeo.org/mailman/listinfo/geomoose-psc

_______________________________________________
geomoose-psc mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/geomoose-psc
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Google Geocoder

Dan Little-2
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 <[hidden email]> wrote:

> I think an email saying we noticed it was down and offering to help maintain
> it might be worthwhile.
>
> I guess my real question is if 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" <[hidden email]> wrote:
>>
>> Schuyler Earl. Good luck.  It's like 12 projects ago for him.
>>
>> On Fri, Jul 1, 2016 at 9:35 AM, James Klassen <[hidden email]>
>> wrote:
>> > Do we know who was running geocoder.us?  Maybe we could get it fixed.
>> >
>> >
>> > On Jul 1, 2016 05:03, "Dan Little" <[hidden email]> wrote:
>> >>
>> >> Hey Folks,
>> >>
>> >> 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.
>> >> 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.
>> >>
>> >> Cheers,
>> >>
>> >> -Duck
>> >>
>> >> Reference tickets:
>> >> - https://github.com/geomoose/geomoose/issues/150
>> >> - https://github.com/geomoose/geomoose/issues/152
>> >> _______________________________________________
>> >> geomoose-psc mailing list
>> >> [hidden email]
>> >> http://lists.osgeo.org/mailman/listinfo/geomoose-psc
_______________________________________________
geomoose-psc mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/geomoose-psc
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Google Geocoder

James Klassen-2

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" <[hidden email]> wrote:
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 <[hidden email]> wrote:
> I think an email saying we noticed it was down and offering to help maintain
> it might be worthwhile.
>
> I guess my real question is if 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" <[hidden email]> wrote:
>>
>> Schuyler Earl. Good luck.  It's like 12 projects ago for him.
>>
>> On Fri, Jul 1, 2016 at 9:35 AM, James Klassen <[hidden email]>
>> wrote:
>> > Do we know who was running geocoder.us?  Maybe we could get it fixed.
>> >
>> >
>> > On Jul 1, 2016 05:03, "Dan Little" <[hidden email]> wrote:
>> >>
>> >> Hey Folks,
>> >>
>> >> 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.
>> >> 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.
>> >>
>> >> Cheers,
>> >>
>> >> -Duck
>> >>
>> >> Reference tickets:
>> >> - https://github.com/geomoose/geomoose/issues/150
>> >> - https://github.com/geomoose/geomoose/issues/152
>> >> _______________________________________________
>> >> geomoose-psc mailing list
>> >> [hidden email]
>> >> http://lists.osgeo.org/mailman/listinfo/geomoose-psc

_______________________________________________
geomoose-psc mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/geomoose-psc
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Google Geocoder

Brian Fischer
In reply to this post by Dan Little-2
Could we switch it to this?  https://open.mapquestapi.com/geocoding/ or https://www.mapbox.com/geocoding/    Still requires a key but maybe a little bit more flexible on licensing than Google or others.  Also uses OpenStreetMap data.

Brian Fischer
Vice President, GIS Project Manager
Houston Engineering, Inc.
O 763.493.4522 | D 763.493.6664 | M 763.229.2734


-----Original Message-----
From: geomoose-psc [mailto:[hidden email]] On Behalf Of Dan Little
Sent: Friday, July 01, 2016 9:38 AM
To: James Klassen <[hidden email]>
Cc: GeoMOOSE PSC <[hidden email]>
Subject: Re: [geomoose-psc] Google Geocoder

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

On Fri, Jul 1, 2016 at 9:35 AM, James Klassen <[hidden email]> wrote:

> Do we know who was running geocoder.us?  Maybe we could get it fixed.
>
>
> On Jul 1, 2016 05:03, "Dan Little" <[hidden email]> wrote:
>>
>> Hey Folks,
>>
>> 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.
>> 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.
>>
>> Cheers,
>>
>> -Duck
>>
>> Reference tickets:
>> - https://github.com/geomoose/geomoose/issues/150
>> - https://github.com/geomoose/geomoose/issues/152
>> _______________________________________________
>> geomoose-psc mailing list
>> [hidden email]
>> http://lists.osgeo.org/mailman/listinfo/geomoose-psc
_______________________________________________
geomoose-psc mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/geomoose-psc
_______________________________________________
geomoose-psc mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/geomoose-psc
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Google Geocoder

Dan Little-2
Not Mapbox -- Licensing problems
MapQuest -  Requires us to ship an API key in the demo in order for it
to function.

On Fri, Jul 1, 2016 at 9:49 AM, Brian Fischer <[hidden email]> wrote:

> Could we switch it to this?  https://open.mapquestapi.com/geocoding/ or https://www.mapbox.com/geocoding/    Still requires a key but maybe a little bit more flexible on licensing than Google or others.  Also uses OpenStreetMap data.
>
> Brian Fischer
> Vice President, GIS Project Manager
> Houston Engineering, Inc.
> O 763.493.4522 | D 763.493.6664 | M 763.229.2734
>
>
> -----Original Message-----
> From: geomoose-psc [mailto:[hidden email]] On Behalf Of Dan Little
> Sent: Friday, July 01, 2016 9:38 AM
> To: James Klassen <[hidden email]>
> Cc: GeoMOOSE PSC <[hidden email]>
> Subject: Re: [geomoose-psc] Google Geocoder
>
> Schuyler Earl. Good luck.  It's like 12 projects ago for him.
>
> On Fri, Jul 1, 2016 at 9:35 AM, James Klassen <[hidden email]> wrote:
>> Do we know who was running geocoder.us?  Maybe we could get it fixed.
>>
>>
>> On Jul 1, 2016 05:03, "Dan Little" <[hidden email]> wrote:
>>>
>>> Hey Folks,
>>>
>>> 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.
>>> 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.
>>>
>>> Cheers,
>>>
>>> -Duck
>>>
>>> Reference tickets:
>>> - https://github.com/geomoose/geomoose/issues/150
>>> - https://github.com/geomoose/geomoose/issues/152
>>> _______________________________________________
>>> geomoose-psc mailing list
>>> [hidden email]
>>> http://lists.osgeo.org/mailman/listinfo/geomoose-psc
> _______________________________________________
> geomoose-psc mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/geomoose-psc
_______________________________________________
geomoose-psc mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/geomoose-psc
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Google Geocoder

Dan Little-2
In reply to this post by James Klassen-2
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 <[hidden email]> 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" <[hidden email]> wrote:
>>
>> 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 <[hidden email]>
>> wrote:
>> > I think an email saying we noticed it was down and offering to help
>> > maintain
>> > it might be worthwhile.
>> >
>> > I guess my real question is if 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" <[hidden email]> wrote:
>> >>
>> >> Schuyler Earl. Good luck.  It's like 12 projects ago for him.
>> >>
>> >> On Fri, Jul 1, 2016 at 9:35 AM, James Klassen <[hidden email]>
>> >> wrote:
>> >> > Do we know who was running geocoder.us?  Maybe we could get it fixed.
>> >> >
>> >> >
>> >> > On Jul 1, 2016 05:03, "Dan Little" <[hidden email]> wrote:
>> >> >>
>> >> >> Hey Folks,
>> >> >>
>> >> >> 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.
>> >> >> 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.
>> >> >>
>> >> >> Cheers,
>> >> >>
>> >> >> -Duck
>> >> >>
>> >> >> Reference tickets:
>> >> >> - https://github.com/geomoose/geomoose/issues/150
>> >> >> - https://github.com/geomoose/geomoose/issues/152
>> >> >> _______________________________________________
>> >> >> geomoose-psc mailing list
>> >> >> [hidden email]
>> >> >> http://lists.osgeo.org/mailman/listinfo/geomoose-psc
_______________________________________________
geomoose-psc mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/geomoose-psc
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Google Geocoder

Eli Adam
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 <[hidden email]> 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 <[hidden email]> 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" <[hidden email]> wrote:
>>>
>>> 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 <[hidden email]>
>>> 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 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" <[hidden email]> wrote:
>>> >>
>>> >> Schuyler Earl. Good luck.  It's like 12 projects ago for him.
>>> >>
>>> >> On Fri, Jul 1, 2016 at 9:35 AM, James Klassen <[hidden email]>
>>> >> wrote:
>>> >> > Do we know who was running geocoder.us?  Maybe we could get it fixed.
>>> >> >
>>> >> >
>>> >> > On Jul 1, 2016 05:03, "Dan Little" <[hidden email]> wrote:
>>> >> >>
>>> >> >> Hey Folks,
>>> >> >>
>>> >> >> 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
>>> >> >> [hidden email]
>>> >> >> http://lists.osgeo.org/mailman/listinfo/geomoose-psc
> _______________________________________________
> geomoose-psc mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/geomoose-psc
_______________________________________________
geomoose-psc mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/geomoose-psc
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Google Geocoder

Dan Little-2
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
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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" <[hidden email]> wrote:
>>>>
>>>> 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 <[hidden email]>
>>>> 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 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" <[hidden email]> wrote:
>>>> >>
>>>> >> Schuyler Earl. Good luck.  It's like 12 projects ago for him.
>>>> >>
>>>> >> On Fri, Jul 1, 2016 at 9:35 AM, James Klassen <[hidden email]>
>>>> >> wrote:
>>>> >> > Do we know who was running geocoder.us?  Maybe we could get it fixed.
>>>> >> >
>>>> >> >
>>>> >> > On Jul 1, 2016 05:03, "Dan Little" <[hidden email]> wrote:
>>>> >> >>
>>>> >> >> Hey Folks,
>>>> >> >>
>>>> >> >> 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
>>>> >> >> [hidden email]
>>>> >> >> http://lists.osgeo.org/mailman/listinfo/geomoose-psc
>> _______________________________________________
>> geomoose-psc mailing list
>> [hidden email]
>> http://lists.osgeo.org/mailman/listinfo/geomoose-psc
_______________________________________________
geomoose-psc mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/geomoose-psc
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Google Geocoder

blammo
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 <[hidden email]> 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
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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" <[hidden email]> wrote:

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 <[hidden email]>
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 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" <[hidden email]> wrote:

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

On Fri, Jul 1, 2016 at 9:35 AM, James Klassen <[hidden email]>
wrote:
Do we know who was running geocoder.us?  Maybe we could get it fixed.


On Jul 1, 2016 05:03, "Dan Little" <[hidden email]> wrote:

Hey Folks,

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
[hidden email]
http://lists.osgeo.org/mailman/listinfo/geomoose-psc
_______________________________________________
geomoose-psc mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/geomoose-psc
_______________________________________________
geomoose-psc mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/geomoose-psc


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





_______________________________________________
geomoose-psc mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/geomoose-psc
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Google Geocoder

Eli Adam
Good point Bob, I think we need two discussions: What to do past
2.9.1? and What to do for 2.9.1?

For beyond 2.9.1, I favor c, especially if Mapzen or something else is
a viable option.  If there aren't viable options, then b sounds good
for long term.

For 2.9.1, I think any options will work except we might want to
decide based on the long term.  i.e. if the long term route is b, we
should do that now for 2.9.1 too.

Eli

On Fri, Jul 1, 2016 at 9:16 AM, Basques, Bob (CI-StPaul)
<[hidden email]> wrote:

> 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 <[hidden email]> 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
> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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" <[hidden email]> wrote:
>
>
> 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 <[hidden email]>
> 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 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" <[hidden email]> wrote:
>
>
> Schuyler Earl. Good luck.  It's like 12 projects ago for him.
>
> On Fri, Jul 1, 2016 at 9:35 AM, James Klassen <[hidden email]>
> wrote:
>
> Do we know who was running geocoder.us?  Maybe we could get it fixed.
>
>
> On Jul 1, 2016 05:03, "Dan Little" <[hidden email]> wrote:
>
>
> Hey Folks,
>
> 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
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/geomoose-psc
>
> _______________________________________________
> geomoose-psc mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/geomoose-psc
>
> _______________________________________________
> geomoose-psc mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/geomoose-psc
>
>
>
> "I'm not interested in preserving the status quo; I want to overthrow it.”
> -  Niccolo Machiavelli
>
>
>
>
_______________________________________________
geomoose-psc mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/geomoose-psc
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Google Geocoder

Dan Little-2
In terms of level of effort:
a. This is already done in master.
b. This would be 30-45 minutes worth of work.
c. Probably an hour, maybe two hours with testing.

I'm willing to do "b" if folks think that dropping the geocoder from
the demo is a viable move.

On Fri, Jul 1, 2016 at 11:22 AM, Eli Adam <[hidden email]> wrote:

> Good point Bob, I think we need two discussions: What to do past
> 2.9.1? and What to do for 2.9.1?
>
> For beyond 2.9.1, I favor c, especially if Mapzen or something else is
> a viable option.  If there aren't viable options, then b sounds good
> for long term.
>
> For 2.9.1, I think any options will work except we might want to
> decide based on the long term.  i.e. if the long term route is b, we
> should do that now for 2.9.1 too.
>
> Eli
>
> On Fri, Jul 1, 2016 at 9:16 AM, Basques, Bob (CI-StPaul)
> <[hidden email]> wrote:
>> 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 <[hidden email]> 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
>> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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" <[hidden email]> wrote:
>>
>>
>> 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 <[hidden email]>
>> 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 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" <[hidden email]> wrote:
>>
>>
>> Schuyler Earl. Good luck.  It's like 12 projects ago for him.
>>
>> On Fri, Jul 1, 2016 at 9:35 AM, James Klassen <[hidden email]>
>> wrote:
>>
>> Do we know who was running geocoder.us?  Maybe we could get it fixed.
>>
>>
>> On Jul 1, 2016 05:03, "Dan Little" <[hidden email]> wrote:
>>
>>
>> Hey Folks,
>>
>> 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
>> [hidden email]
>> http://lists.osgeo.org/mailman/listinfo/geomoose-psc
>>
>> _______________________________________________
>> geomoose-psc mailing list
>> [hidden email]
>> http://lists.osgeo.org/mailman/listinfo/geomoose-psc
>>
>> _______________________________________________
>> geomoose-psc mailing list
>> [hidden email]
>> http://lists.osgeo.org/mailman/listinfo/geomoose-psc
>>
>>
>>
>> "I'm not interested in preserving the status quo; I want to overthrow it.”
>> -  Niccolo Machiavelli
>>
>>
>>
>>
_______________________________________________
geomoose-psc mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/geomoose-psc
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Google Geocoder

blammo
More discussion needed for anything other than “a”.

We have some options we’ve been using locally that might work as a replacement, but need to talk more about it first.  Hence my, release now, and move to change later.

bobb



On Jul 1, 2016, at 11:24 AM, Dan Little <[hidden email]> wrote:

In terms of level of effort:
a. This is already done in master.
b. This would be 30-45 minutes worth of work.
c. Probably an hour, maybe two hours with testing.

I'm willing to do "b" if folks think that dropping the geocoder from
the demo is a viable move.

On Fri, Jul 1, 2016 at 11:22 AM, Eli Adam <[hidden email]> wrote:
Good point Bob, I think we need two discussions: What to do past
2.9.1? and What to do for 2.9.1?

For beyond 2.9.1, I favor c, especially if Mapzen or something else is
a viable option.  If there aren't viable options, then b sounds good
for long term.

For 2.9.1, I think any options will work except we might want to
decide based on the long term.  i.e. if the long term route is b, we
should do that now for 2.9.1 too.

Eli

On Fri, Jul 1, 2016 at 9:16 AM, Basques, Bob (CI-StPaul)
<[hidden email]> wrote:
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 <[hidden email]> 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
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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" <[hidden email]> wrote:


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 <[hidden email]>
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 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" <[hidden email]> wrote:


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

On Fri, Jul 1, 2016 at 9:35 AM, James Klassen <[hidden email]>
wrote:

Do we know who was running geocoder.us?  Maybe we could get it fixed.


On Jul 1, 2016 05:03, "Dan Little" <[hidden email]> wrote:


Hey Folks,

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
[hidden email]
http://lists.osgeo.org/mailman/listinfo/geomoose-psc

_______________________________________________
geomoose-psc mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/geomoose-psc

_______________________________________________
geomoose-psc mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/geomoose-psc



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






"I like nonsense; it wakes up the brain cells."
- Dr. Seuss







_______________________________________________
geomoose-psc mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/geomoose-psc
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Google Geocoder

Eli Adam
On Fri, Jul 1, 2016 at 9:31 AM, Basques, Bob (CI-StPaul)
<[hidden email]> wrote:
> More discussion needed for anything other than “a”.
>
> We have some options we’ve been using locally that might work as a
> replacement, but need to talk more about it first.  Hence my, release now,
> and move to change later.

If we have no plans for "c" to come about in the near- or mid- term,
then "b" would be the immediate and mid-term option.  "a" to just
delay "b" is not a good option.  If we're going with "b" in the
mid-term, let's go with "b" now.

Those are my thoughts, Eli

>
> bobb
>
>
>
> On Jul 1, 2016, at 11:24 AM, Dan Little <[hidden email]> wrote:
>
> In terms of level of effort:
> a. This is already done in master.
> b. This would be 30-45 minutes worth of work.
> c. Probably an hour, maybe two hours with testing.
>
> I'm willing to do "b" if folks think that dropping the geocoder from
> the demo is a viable move.
>
> On Fri, Jul 1, 2016 at 11:22 AM, Eli Adam <[hidden email]> wrote:
>
> Good point Bob, I think we need two discussions: What to do past
> 2.9.1? and What to do for 2.9.1?
>
> For beyond 2.9.1, I favor c, especially if Mapzen or something else is
> a viable option.  If there aren't viable options, then b sounds good
> for long term.
>
> For 2.9.1, I think any options will work except we might want to
> decide based on the long term.  i.e. if the long term route is b, we
> should do that now for 2.9.1 too.
>
> Eli
>
> On Fri, Jul 1, 2016 at 9:16 AM, Basques, Bob (CI-StPaul)
> <[hidden email]> wrote:
>
> 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 <[hidden email]> 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
> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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" <[hidden email]> wrote:
>
>
> 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 <[hidden email]>
> 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 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" <[hidden email]> wrote:
>
>
> Schuyler Earl. Good luck.  It's like 12 projects ago for him.
>
> On Fri, Jul 1, 2016 at 9:35 AM, James Klassen <[hidden email]>
> wrote:
>
> Do we know who was running geocoder.us?  Maybe we could get it fixed.
>
>
> On Jul 1, 2016 05:03, "Dan Little" <[hidden email]> wrote:
>
>
> Hey Folks,
>
> 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
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/geomoose-psc
>
> _______________________________________________
> geomoose-psc mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/geomoose-psc
>
> _______________________________________________
> geomoose-psc mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/geomoose-psc
>
>
>
> "I'm not interested in preserving the status quo; I want to overthrow it.”
> -  Niccolo Machiavelli
>
>
>
>
>
>
> "I like nonsense; it wakes up the brain cells."
> - Dr. Seuss
>
>
>
>
>
>
_______________________________________________
geomoose-psc mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/geomoose-psc
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Google Geocoder

James Klassen-2

What about d) figure out what happened to geocoder.us?


On Jul 1, 2016 14:07, "Eli Adam" <[hidden email]> wrote:
On Fri, Jul 1, 2016 at 9:31 AM, Basques, Bob (CI-StPaul)
<[hidden email]> wrote:
> More discussion needed for anything other than “a”.
>
> We have some options we’ve been using locally that might work as a
> replacement, but need to talk more about it first.  Hence my, release now,
> and move to change later.

If we have no plans for "c" to come about in the near- or mid- term,
then "b" would be the immediate and mid-term option.  "a" to just
delay "b" is not a good option.  If we're going with "b" in the
mid-term, let's go with "b" now.

Those are my thoughts, Eli

>
> bobb
>
>
>
> On Jul 1, 2016, at 11:24 AM, Dan Little <[hidden email]> wrote:
>
> In terms of level of effort:
> a. This is already done in master.
> b. This would be 30-45 minutes worth of work.
> c. Probably an hour, maybe two hours with testing.
>
> I'm willing to do "b" if folks think that dropping the geocoder from
> the demo is a viable move.
>
> On Fri, Jul 1, 2016 at 11:22 AM, Eli Adam <[hidden email]> wrote:
>
> Good point Bob, I think we need two discussions: What to do past
> 2.9.1? and What to do for 2.9.1?
>
> For beyond 2.9.1, I favor c, especially if Mapzen or something else is
> a viable option.  If there aren't viable options, then b sounds good
> for long term.
>
> For 2.9.1, I think any options will work except we might want to
> decide based on the long term.  i.e. if the long term route is b, we
> should do that now for 2.9.1 too.
>
> Eli
>
> On Fri, Jul 1, 2016 at 9:16 AM, Basques, Bob (CI-StPaul)
> <[hidden email]> wrote:
>
> 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 <[hidden email]> 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
> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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" <[hidden email]> wrote:
>
>
> 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 <[hidden email]>
> 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 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" <[hidden email]> wrote:
>
>
> Schuyler Earl. Good luck.  It's like 12 projects ago for him.
>
> On Fri, Jul 1, 2016 at 9:35 AM, James Klassen <[hidden email]>
> wrote:
>
> Do we know who was running geocoder.us?  Maybe we could get it fixed.
>
>
> On Jul 1, 2016 05:03, "Dan Little" <[hidden email]> wrote:
>
>
> Hey Folks,
>
> 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
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/geomoose-psc
>
> _______________________________________________
> geomoose-psc mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/geomoose-psc
>
> _______________________________________________
> geomoose-psc mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/geomoose-psc
>
>
>
> "I'm not interested in preserving the status quo; I want to overthrow it.”
> -  Niccolo Machiavelli
>
>
>
>
>
>
> "I like nonsense; it wakes up the brain cells."
> - Dr. Seuss
>
>
>
>
>
>
_______________________________________________
geomoose-psc mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/geomoose-psc

_______________________________________________
geomoose-psc mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/geomoose-psc
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Google Geocoder

Dan Little-2

A pile of effort for minimal gain to our application.

If we want to release our stuff then. we can't be dependent on a service we were grifting.

On Jul 1, 2016 21:14, "James Klassen" <[hidden email]> wrote:

What about d) figure out what happened to geocoder.us?


On Jul 1, 2016 14:07, "Eli Adam" <[hidden email]> wrote:
On Fri, Jul 1, 2016 at 9:31 AM, Basques, Bob (CI-StPaul)
<[hidden email]> wrote:
> More discussion needed for anything other than “a”.
>
> We have some options we’ve been using locally that might work as a
> replacement, but need to talk more about it first.  Hence my, release now,
> and move to change later.

If we have no plans for "c" to come about in the near- or mid- term,
then "b" would be the immediate and mid-term option.  "a" to just
delay "b" is not a good option.  If we're going with "b" in the
mid-term, let's go with "b" now.

Those are my thoughts, Eli

>
> bobb
>
>
>
> On Jul 1, 2016, at 11:24 AM, Dan Little <[hidden email]> wrote:
>
> In terms of level of effort:
> a. This is already done in master.
> b. This would be 30-45 minutes worth of work.
> c. Probably an hour, maybe two hours with testing.
>
> I'm willing to do "b" if folks think that dropping the geocoder from
> the demo is a viable move.
>
> On Fri, Jul 1, 2016 at 11:22 AM, Eli Adam <[hidden email]> wrote:
>
> Good point Bob, I think we need two discussions: What to do past
> 2.9.1? and What to do for 2.9.1?
>
> For beyond 2.9.1, I favor c, especially if Mapzen or something else is
> a viable option.  If there aren't viable options, then b sounds good
> for long term.
>
> For 2.9.1, I think any options will work except we might want to
> decide based on the long term.  i.e. if the long term route is b, we
> should do that now for 2.9.1 too.
>
> Eli
>
> On Fri, Jul 1, 2016 at 9:16 AM, Basques, Bob (CI-StPaul)
> <[hidden email]> wrote:
>
> 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 <[hidden email]> 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
> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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" <[hidden email]> wrote:
>
>
> 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 <[hidden email]>
> 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 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" <[hidden email]> wrote:
>
>
> Schuyler Earl. Good luck.  It's like 12 projects ago for him.
>
> On Fri, Jul 1, 2016 at 9:35 AM, James Klassen <[hidden email]>
> wrote:
>
> Do we know who was running geocoder.us?  Maybe we could get it fixed.
>
>
> On Jul 1, 2016 05:03, "Dan Little" <[hidden email]> wrote:
>
>
> Hey Folks,
>
> 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
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/geomoose-psc
>
> _______________________________________________
> geomoose-psc mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/geomoose-psc
>
> _______________________________________________
> geomoose-psc mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/geomoose-psc
>
>
>
> "I'm not interested in preserving the status quo; I want to overthrow it.”
> -  Niccolo Machiavelli
>
>
>
>
>
>
> "I like nonsense; it wakes up the brain cells."
> - Dr. Seuss
>
>
>
>
>
>
_______________________________________________
geomoose-psc mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/geomoose-psc

_______________________________________________
geomoose-psc mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/geomoose-psc
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Google Geocoder

Brian Fischer

I don’t have a big preference on options.  Dan since you are providing the resources I would lean on your recommendation.

 

Brian Fischer

Vice President, GIS Project Manager

Houston Engineering, Inc.

O 763.493.4522 | D 763.493.6664 | M 763.229.2734

 

From: geomoose-psc [mailto:[hidden email]] On Behalf Of Dan Little
Sent: Friday, July 01, 2016 2:16 PM
To: Jim Klassen <[hidden email]>
Cc: GeoMOOSE PSC <[hidden email]>
Subject: Re: [geomoose-psc] Google Geocoder

 

A pile of effort for minimal gain to our application.

If we want to release our stuff then. we can't be dependent on a service we were grifting.

On Jul 1, 2016 21:14, "James Klassen" <[hidden email]> wrote:

What about d) figure out what happened to geocoder.us?

 

On Jul 1, 2016 14:07, "Eli Adam" <[hidden email]> wrote:

On Fri, Jul 1, 2016 at 9:31 AM, Basques, Bob (CI-StPaul)
<[hidden email]> wrote:
> More discussion needed for anything other than “a”.
>
> We have some options we’ve been using locally that might work as a
> replacement, but need to talk more about it first.  Hence my, release now,
> and move to change later.

If we have no plans for "c" to come about in the near- or mid- term,
then "b" would be the immediate and mid-term option.  "a" to just
delay "b" is not a good option.  If we're going with "b" in the
mid-term, let's go with "b" now.

Those are my thoughts, Eli

>
> bobb
>
>
>
> On Jul 1, 2016, at 11:24 AM, Dan Little <[hidden email]> wrote:
>
> In terms of level of effort:
> a. This is already done in master.
> b. This would be 30-45 minutes worth of work.
> c. Probably an hour, maybe two hours with testing.
>
> I'm willing to do "b" if folks think that dropping the geocoder from
> the demo is a viable move.
>
> On Fri, Jul 1, 2016 at 11:22 AM, Eli Adam <[hidden email]> wrote:
>
> Good point Bob, I think we need two discussions: What to do past
> 2.9.1? and What to do for 2.9.1?
>
> For beyond 2.9.1, I favor c, especially if Mapzen or something else is
> a viable option.  If there aren't viable options, then b sounds good
> for long term.
>
> For 2.9.1, I think any options will work except we might want to
> decide based on the long term.  i.e. if the long term route is b, we
> should do that now for 2.9.1 too.
>
> Eli
>
> On Fri, Jul 1, 2016 at 9:16 AM, Basques, Bob (CI-StPaul)
> <[hidden email]> wrote:
>
> 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 <[hidden email]> 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
> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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" <[hidden email]> wrote:
>
>
> 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 <[hidden email]>
> 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 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" <[hidden email]> wrote:
>
>
> Schuyler Earl. Good luck.  It's like 12 projects ago for him.
>
> On Fri, Jul 1, 2016 at 9:35 AM, James Klassen <[hidden email]>
> wrote:
>
> Do we know who was running geocoder.us?  Maybe we could get it fixed.
>
>
> On Jul 1, 2016 05:03, "Dan Little" <[hidden email]> wrote:
>
>
> Hey Folks,
>
> 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
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/geomoose-psc
>
> _______________________________________________
> geomoose-psc mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/geomoose-psc
>
> _______________________________________________
> geomoose-psc mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/geomoose-psc
>
>
>
> "I'm not interested in preserving the status quo; I want to overthrow it.”
> -  Niccolo Machiavelli
>
>
>
>
>
>
> "I like nonsense; it wakes up the brain cells."
> - Dr. Seuss
>
>
>
>
>
>
_______________________________________________
geomoose-psc mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/geomoose-psc


_______________________________________________
geomoose-psc mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/geomoose-psc
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Google Geocoder

James Klassen-2
In reply to this post by Dan Little-2

Fixing geocoder.us might be good overall though and if we help we aren't grifting.

The grifting argument applies to not using Google or others either which leaves us with nothing.


On Jul 1, 2016 14:15, "Dan Little" <[hidden email]> wrote:

A pile of effort for minimal gain to our application.

If we want to release our stuff then. we can't be dependent on a service we were grifting.

On Jul 1, 2016 21:14, "James Klassen" <[hidden email]> wrote:

What about d) figure out what happened to geocoder.us?


On Jul 1, 2016 14:07, "Eli Adam" <[hidden email]> wrote:
On Fri, Jul 1, 2016 at 9:31 AM, Basques, Bob (CI-StPaul)
<[hidden email]> wrote:
> More discussion needed for anything other than “a”.
>
> We have some options we’ve been using locally that might work as a
> replacement, but need to talk more about it first.  Hence my, release now,
> and move to change later.

If we have no plans for "c" to come about in the near- or mid- term,
then "b" would be the immediate and mid-term option.  "a" to just
delay "b" is not a good option.  If we're going with "b" in the
mid-term, let's go with "b" now.

Those are my thoughts, Eli

>
> bobb
>
>
>
> On Jul 1, 2016, at 11:24 AM, Dan Little <[hidden email]> wrote:
>
> In terms of level of effort:
> a. This is already done in master.
> b. This would be 30-45 minutes worth of work.
> c. Probably an hour, maybe two hours with testing.
>
> I'm willing to do "b" if folks think that dropping the geocoder from
> the demo is a viable move.
>
> On Fri, Jul 1, 2016 at 11:22 AM, Eli Adam <[hidden email]> wrote:
>
> Good point Bob, I think we need two discussions: What to do past
> 2.9.1? and What to do for 2.9.1?
>
> For beyond 2.9.1, I favor c, especially if Mapzen or something else is
> a viable option.  If there aren't viable options, then b sounds good
> for long term.
>
> For 2.9.1, I think any options will work except we might want to
> decide based on the long term.  i.e. if the long term route is b, we
> should do that now for 2.9.1 too.
>
> Eli
>
> On Fri, Jul 1, 2016 at 9:16 AM, Basques, Bob (CI-StPaul)
> <[hidden email]> wrote:
>
> 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 <[hidden email]> 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
> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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" <[hidden email]> wrote:
>
>
> 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 <[hidden email]>
> 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 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" <[hidden email]> wrote:
>
>
> Schuyler Earl. Good luck.  It's like 12 projects ago for him.
>
> On Fri, Jul 1, 2016 at 9:35 AM, James Klassen <[hidden email]>
> wrote:
>
> Do we know who was running geocoder.us?  Maybe we could get it fixed.
>
>
> On Jul 1, 2016 05:03, "Dan Little" <[hidden email]> wrote:
>
>
> Hey Folks,
>
> 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
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/geomoose-psc
>
> _______________________________________________
> geomoose-psc mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/geomoose-psc
>
> _______________________________________________
> geomoose-psc mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/geomoose-psc
>
>
>
> "I'm not interested in preserving the status quo; I want to overthrow it.”
> -  Niccolo Machiavelli
>
>
>
>
>
>
> "I like nonsense; it wakes up the brain cells."
> - Dr. Seuss
>
>
>
>
>
>
_______________________________________________
geomoose-psc mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/geomoose-psc

_______________________________________________
geomoose-psc mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/geomoose-psc
12
Loading...