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>
