The issue is not that we did not test this (we did if you were wondering), we followed the specification exactly as written in the original documentation, which in this case relates to your website missing the h (height) parameter in your calls.

It is actually written in the original documentation that this defaults to 350 when no parameter is supplied, which we have faithfully recreated in this case. Obviously this is not what actually happens and I am trying to get in contact with the person who originally developed this so we can figure out exactly what they did.

In the mean time I am working to resolve this and I can understand how annoying this is but we cannot test for a feature or requirement that we did not know existed and was never documented.

Thank you for bring this to my attention,
Matt

Hi Teresa, I have just released a fix for something else, so you might have just caught the service at a bad time in this case, the site appears to be working fine now however.

The NMRS dataset is on the gateway, however this system works on the same permissions as the rest of the gateway (you will see whatever level of access you have as a user, or public access if you are not logged in). In the case of the NMRS dataset (https://data.nbn.org.uk/Datasets/GA000591 I think) there is no public access to any data from the gateway, so the EasyMap Service itself wouldn't be useful in this case.

However you can get around this by having some sort of intermediary service that logs into the gateway (as a user with the correct level of access to this dataset) and requests the maps (these could be cached for use by your website).

The calls to this service aren't logged as no actual record data is taken from the gateway only a map in this case (we log downloads from the downloads wizard and any request that returns complete records from the API), I assume this is what you mean by data providers stats, but please correct me if I am wrong. In all respects every part of the gateway runs off of the web services so all services including this one are running off of the core web services including the web site itself.

Hope that makes some level of sense, please let me know if something needs further clarification.

Matt

Hi Mark,

With regards to the public only access, I did offer a work around, using an intermediary service logging into the gateway and caching the maps locally, but I understand this is still a very technical task and not simple and may require some negotiation with the dataset owners to make sure this use case is all above board.

The tr/bl feature has been carried over to the new service, the issue that you are having here is that not all grid references are currently in our databases. Early on in the design of Gateway V it was decided that we would not store grid references that have no records associated with them (they are created on record ingestion currently). In this case you have unfortunately chosen one such 10km square which was not imported, NW71, however NW72 is in the database as a quick fix in this case.

I apologise for this as this particular instance, it is a bit of an edge case however I agree it should work correctly. I will try and see if I can get the system to import at least all 10km OSGB squares today, but I can't guarantee if it will be resolved today, at best it will be fixed tomorrow when the data is replicated to the warehouses, I will try and keep you updated with my progress.

This issue however will continue to affect people using 2km and 1km grid references as bounding boxes as they are more likely to not exist (we create a tree upwards from a record so if a record is at 2km then we wont create the 1km or 100m squares but will create the 10km square for example). I haven't seen much use of this feature so I can't say with confidence what is most used here, however I would assume 10km would be the most prevalent use of this feature.

Once again I apologise for these issues and I am endeavouring to fix them as soon as possible, if you encounter new issues in the mean time please let me know.

Matt

Thanks for tracking down the issue Matt. Doesn't matter if our moth maps are down for a few days, so long as the issue behind them will be fixed fairly soon.

I think that anyone that uses this feature is likely to use a hectad reference (in fact this could be specified in the Easymaps instructions) so that it should work for everyone in future once you get the 10km squares sorted on your database.

With regards to the other issue of changed access permissions, then whatever solution we look at is likely to mean quite a bit of work as the moth website is a series of static pages and each will need  the coding tweaked unless the dataset is granted public access on the V5 gateway, which seems unlikely at least in the short term. We'll find a way around this, but it won't be too technical as my skills and that of the county recorder don't run to that!

Cheers

MARK

Presumbly the missing parameter was calculated to retain the correct aspect ratio?

Hi Mark, I imported all OSGB 10km squares covering any landmass in the UK (excluding Ireland for now), these have been live for about a week now, so they should be working.

The example you gave above now works from here and as far as I can see the maps on the dgmoths seem to be working at least for me, if you are still having issues I will have a closer look into this, but as far as I can see its working.

Matt

Hi Mark, I am viewing the maps in Chrome without issue, the iframe is grabbing data from a https source which shouldn't be an issue, this is due to the fact that we no longer support http connections to the gateway. However grabbing https sources from a http page should not cause any issue with any browser.

The terms argument was not described in the specification that we were given so as such was never implemented, what exactly did it do in this case? Did it just remove the terms and conditions link? or all text above the map?

I will look into the aspect ratio in this case and try to figure out what is going wrong here.

Thanks for letting us know,

Matt

Edit: It actually looks like the terms argument was implemented, but its not working, I will try and figure out why, it looks like it just removes the text between the title and map, if that is what is expected in this case.

I have just pushed up a fix for this;

"terms" option should now work correctly and remove the text for terms and conditions as before, leaving the title intact

The aspect ratio should now be worked out when only a W or H parameter is provided, this comes from the bounding box being used so should always provide an undistorted map in these cases.

Hope that helps,
Matt

One quick query Matt

Look at these two links - one returns a blank map and one returns an error. Both are macro moths so there is no data available to display in our region. Could you explain reason for the difference?

https://data.nbn.org.uk/EasyMap?w=300&a … 0000005994

https://data.nbn.org.uk/EasyMap?w=300&a … 0000005867

MARK