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@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@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@lists.gbif.org
http://lists.gbif.org/mailman/listinfo/api-users