I noticed that e.g. "&country=NL" limits occurrence data even within the specified country. That is, for that country, I get less occurrence data than without the "&country=NL"
Is this caused by wrong data, by data with the wrong (or no) country identifier attached ?
Anyway, I now seek another solution, which is to clip the occurrence data to the specified country on the map. However, how do I get map data tiles with country borders ? I use EPSG:3575.
Regards,
Adriaan van Os
Hi Adriaan,
Could you give an example?
Just visually, the map tile looks fine when flipping between https://api.gbif.org/v2/map/occurrence/density/6/65/13@2x.png?srs=EPSG:4326&... and https://api.gbif.org/v2/map/occurrence/density/6/65/13@2x.png?srs=EPSG:4326&...
Zooming in one step to the top right (which is only Dutch territory) and comparing the vector tiles with and without the country mask:
https://api.gbif.org/v2/map/occurrence/density/7/131/26.mvt?srs=EPSG:4326&am...
https://api.gbif.org/v2/map/occurrence/density/7/131/26.mvt?srs=EPSG:4326&am...
These are byte-for-byte identical.
I don't see a problem in EPSG:3575 either, e.g. with https://api.gbif.org/v2/map/occurrence/density/5/15/23@2x.png?srs=EPSG:3575&...
Note that close to borders, GBIF's processing assumes the source data is correct as we know our map isn't perfect. An observation in Westerwoldse Aa on the border of Netherlands and Germany could be accepted with either country=NL or country=DE, and would show accordingly if the map is clipped to NL or DE.
For the other approach, I don't have EPSG:3575-format vector tiles with country borders, but in any case it's difficult to work with vector tiles for any further processing — if you wanted a polygon, you'd need to reconstruct it from the lines which are cut off at the edges of the tiles. I recommend you use a different source of map data, e.g. from http://www.naturalearthdata.com/ . Many GIS libraries (including Javascript ones for display) should be able to work with that data, for example in GeoJSON format: https://github.com/nvkelso/natural-earth-vector/tree/master/geojson (if 10m resolution is sufficient).
Cheers,
Matt Blissett
On 08/01/2019 22:19, Adriaan van Os wrote:
I noticed that e.g. "&country=NL" limits occurrence data even within the specified country. That is, for that country, I get less occurrence data than without the "&country=NL"
Is this caused by wrong data, by data with the wrong (or no) country identifier attached ?
Anyway, I now seek another solution, which is to clip the occurrence data to the specified country on the map. However, how do I get map data tiles with country borders ? I use EPSG:3575.
Regards,
Adriaan van Os _______________________________________________ API-users mailing list API-users@lists.gbif.org https://lists.gbif.org/mailman/listinfo/api-users
Matthew Blissett wrote:
For the other approach, I don't have EPSG:3575-format vector tiles with country borders, but in any case it's difficult to work with vector tiles for any further processing — if you wanted a polygon, you'd need to reconstruct it from the lines which are cut off at the edges of the tiles. I recommend you use a different source of map data, e.g. from http://www.naturalearthdata.com/ . Many GIS libraries (including Javascript ones for display) should be able to work with that data, for example in GeoJSON format:
With some programming, the poly-edge cutting problem can be solved. Besides, on large-scale maps with small polys, I find cutting the poly edges really improves the looks of the map. Also, one could use the country borders to highlight (e.g.) a specific country on the background-map before overlaying the occurrence polys. So, I do suggest adding "&country=" to the GBIF background-map tile API.
https://github.com/nvkelso/natural-earth-vector/tree/master/geojson (if 10m resolution is sufficient).
Thanks !
The Natural Earth Admin0 data sets https://www.naturalearthdata.com/downloads/50m-cultural-vectors/ are what I need. Best of all, it can be loaded into QGiS and converts perfectly well to EGCS:3575. There is not much on the internet (that I could find) for converting to EGCS:3575. I have only located QGiS, OpenLayers (apparently) and Leaflet (Proj4Leaflet c.s.). And GBIF, of course.
The advantage of EGCS:3575 is that it is an equal area projection https://en.wikipedia.org/wiki/Lambert_azimuthal_equal-area_projection, unlike EPSG:3857 Web Mercator. I don't like Web Mercator distortions. I guess EPSG:3857 became polular when Google started to use it, thinking that people will be confused when the line pointing North isn't vertical. God should have made the earth a cube for that purpose ? Well, that causes some problems at the edges when travelling ....
I will investigate the &country=NL issue further and reply seperately.
Regards,
Adriaan van Os
Matthew Blissett wrote:
Hi Adriaan,
Could you give an example?
Well, I just started with the A, doing my iteration with "&country=NL" added to the http request and "-nl" addded to the filename. As you can see below, they all compare negative.
http://lepidoptera.online/gbif/abraxas-grossulariata-occur-nl.png http://lepidoptera.online/gbif/abraxas-grossulariata-occur.png
http://lepidoptera.online/gbif/abraxas-sylvata-occur-nl.png http://lepidoptera.online/gbif/abraxas-sylvata-occur.png
http://lepidoptera.online/gbif/abrostola-tripartita-occur-nl.png http://lepidoptera.online/gbif/abrostola-tripartita-occur.png
http://lepidoptera.online/gbif/abrostola-triplasia-occur-nl.png http://lepidoptera.online/gbif/abrostola-triplasia-occur.png
http://lepidoptera.online/gbif/acasis-viretata-occur-nl.png http://lepidoptera.online/gbif/acasis-viretata-occur.png
http://lepidoptera.online/gbif/acherontia-atropos-occur-nl.png http://lepidoptera.online/gbif/acherontia-atropos-occur.png
http://lepidoptera.online/gbif/achlya-flavicornis-occur-nl.png http://lepidoptera.online/gbif/achlya-flavicornis-occur.png
http://lepidoptera.online/gbif/acronicta-aceris-occur-nl.png http://lepidoptera.online/gbif/acronicta-aceris-occur.png
I stopped there, but could list a few hundred more ....
I iterate prcedurally
$tURL:="https://api.gbif.org/v2/map/occurrence/density/%22+String($nz)+%22/%22+Strin... $nHttpResponse:=HTTP Get($tURL;$uTile;$atHeaderNames;$atHeaderValues)
where $nz=7 $nx=65..65 $ny=41..43 $sStyle:="&style=classic.poly&bin=hex&hexPerTile=30" $sCountry:="&country=NL" (or an empty string) $sSuffix:="-nl" (or an empty string) $sProjection:="srs=EPSG:3857" $nTaxonKey comes from a database table, imported from the GBIF backbone
Regards,
Adriaan van Os
On 10/01/2019 14:37, Adriaan van Os wrote:
Matthew Blissett wrote:
Hi Adriaan,
Could you give an example?
Well, I just started with the A, doing my iteration with "&country=NL" added to the http request and "-nl" addded to the filename. As you can see below, they all compare negative.
http://lepidoptera.online/gbif/abraxas-grossulariata-occur-nl.png http://lepidoptera.online/gbif/abraxas-grossulariata-occur.png
Thanks, that's not something I'd seen in development or testing.
I've made an issue and a live demo: https://github.com/gbif/maps/issues/29 (using vector tile points, as the polygon maps are generate from the point sources, and the raster tiles from the vector ones).
I should have time to investigate it next week,
Thanks for reporting the problem,
Matt
Matthew Blissett wrote:
I've made an issue and a live demo: https://github.com/gbif/maps/issues/29 (using vector tile points, as the polygon maps are generate from the point sources, and the raster tiles from the vector ones).
The Dutch data are peculiar in that a system is used in the Netherlands that counts (not just moths) in each 5x5 km square. That has some interesting effects on GBIF maps:
1. The GBIF polygon maps from such data show a Moiré pattern, caused by two rasters interfering (GBIF polygons and the Dutch 5x5 squares) unless the polygon size is carefully choosen.
2. The point maps don't show a "natural distribution" in the Netherlands as can be seen in this example http://lepidoptera.online/gbif/aglais-io-hokjesmentaliteit.png
3. Apparently, the Dutch data have an offset and must be shifted to the North-East to align. I don't know if this is a GBIF or Dutch data problem. Nor do I know if it is the center of the 5x5km squares that is entered as GBIF map position.
Regards,
Adriaan van Os
participants (2)
-
Adriaan van Os -
Matthew Blissett