[API-users] interaction for the maps api
kenichi.ueda at gmail.com
Thu Mar 19 06:32:28 CET 2015
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!
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.
> 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?
>> API-users mailing list
>> API-users at lists.gbif.org
More information about the API-users