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
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
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
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@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@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
participants (2)
-
Ken-ichi -
Tim Robertson