[API-users] interaction for the maps api

[Tim Robertson]

Thanks Ken-ichi,

Coincidentally, I see the vector maps are picking up pace quickly with ESRI announcing support last week:
  https://www.mapbox.com/blog/vector-tile-adoption/

I expect this is going to change the way we all build mapping interfaces in the very near future.

Cheers,
Tim



On 19 Mar 2015, at 06:32, Ken-ichi <kenichi.ueda at gmail.com> wrote:

> Thanks, Tim. Obviously you guys are more reactive than I am! Patrick
> and I agree that doing API calls for every click on the map is a bit
> much, especially considering we have other clickable stuff on every
> map where we show the GBIF layer, so we'll wait until you guys put
> something together. If you go down the vector tile path, hopefully we
> can learn from what you implement!
> 
> -ken-ichi
> 
> On Tue, Mar 17, 2015 at 1:49 AM, Tim Robertson <trobertson at gbif.org> wrote:
>> Hi Ken Ichi
>> 
>> We have given it some thought, but it hasn’t yet got to the a priority where we’ve put serious effort to implement it.
>> 
>> We’d likely do one of:
>> 
>> a) a proximity search in the occurrence search API (currently there is polygon only) which is served from SOLR
>> b) a custom solution using HBase which serves the maps.  Effectively being a key value pair store, this comes with some limitation
>>  - this would serve up something like the UTFGrid or offer a custom JSON service / list by location service
>> c) taking the hit and doing mapbox vector tiles, and going for webgl
>> 
>> The way all the map work is going these days, c) is probably the correct way to do it and I have some prototypes of this.  Vector tiles all use protobuf, whereas we built using Apache Avro for our encoding format.
>> 
>> The reality is though, we are unlikely to get to working on maps for the next 6 months or so as we have a pretty heavy workload between now and the governing board.  We might be able to get a) into the API sooner and I’ll discuss that with the team here.
>> 
>> The only workaround in the meantime would be to do a small bounding box search, such as the following:
>>  http://api.gbif.org/v1/occurrence/search?GEOMETRY=POLYGON((-121.407165 35.855665,-121.407165 35.844534,-121.393432 35.844534,-121.393432 35.855665,-121.407165 35.855665))
>> 
>> By using this, you could construct a small area around where the user clicked, run a search on click, and then you have the coordinates in the response to inspect if you *really* need to match a point.
>> Is that reasonable for the time being?
>> 
>> I’m sorry we can’t be more reactive.
>> 
>> Congratulations to you and Patrick on the work - looks great.
>> 
>> Cheers,
>> Tim
>> 
>> 
>> 
>> On 16 Mar 2015, at 22:30, Ken-ichi <kenichi.ueda at gmail.com> wrote:
>> 
>>> Hi all,
>>> 
>>> We just added GBIF tiles as an optional overlay to many of our maps at
>>> iNaturalist.org, e.g.
>>> http://www.inaturalist.org/taxa/27818-Taricha-torosa/map. They're
>>> great and the API works perfectly, but the first thing people want to
>>> do when they see this data is click on those points! Has anyone at
>>> GBIF or elsewhere given some thought to how to implement that?
>>> 
>>> The easiest way to do this from our perspective would be for GBIF to
>>> implement a UTFGrid endpoint for their tiles
>>> (https://github.com/mapbox/utfgrid-spec). The corresponding JSON
>>> wouldn't have to include all the occurrences (which would probably be
>>> a lot) but it could include 1 page of occurrences, or just a bounding
>>> box clients could use to generate a link to retrieve the corresponding
>>> data on GBIF.
>>> 
>>> Another method I was thinking about was to make a custom tile overlay
>>> composed of HTML canvas elements, load the tile image onto the canvas,
>>> and use clicks to get the RGBA values of the corresponding pixel at
>>> the click coordinates to see if there was any color there. If alpha ==
>>> 1, then retrieve corresponding occurrences from the GBIF occurrences
>>> API using the bounding box implied by the pixel at that zoom level.
>>> Canvases have been used as overlays in Google Maps, at least (e.g.
>>> https://github.com/brendankenny/CanvasLayer), and I'm sure in other
>>> frontend map frameworks as well, but I'm not sure what the performance
>>> would be like.
>>> 
>>> Other ideas?
>>> 
>>> -ken-ichi
>>> _______________________________________________
>>> API-users mailing list
>>> API-users at lists.gbif.org
>>> http://lists.gbif.org/mailman/listinfo/api-users
>>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gbif.org/pipermail/api-users/attachments/20150319/fe2e6277/attachment-0001.html>