OS OpenSpace [logo]

OS OpenSpace Forum » OS OpenSpace » OpenSpace Forum

Thread: openspace.js massive and uncacheable?

Reply to this Thread Reply to this Thread Search Forum Search Forum Back to Thread List Back to Thread List

Permlink Replies: 15 - Pages: 2 [ 1 2 | Next ] - Last Post: 10-Nov-2011 16:06 by: CharlesHarrison
cparker

Posts: 2
Registered: 31/10/11
openspace.js massive and uncacheable?
Posted: 01-Nov-2011 22:18
  Click to reply to this thread Reply

Hi,

Looking at current mapping products for a website and amazed that the openspace.js file is so massive! Approx 220kb compared to Google Maps; 42kb

Plus because of the API key requirement it doesnt look like the .js file can be cached by the browser, so every page refresh is another 220kb pull.

Are there any plans in the pipeline to reduce this size or enable it to be cached locally?

If you scale this up its a major constraint or have I missed something?

Thanks in advance

bigmentor

Posts: 176
Registered: 13/06/09
Re: openspace.js massive and uncacheable?
Posted: 02-Nov-2011 05:54   in response to: cparker
  Click to reply to this thread Reply

Maybe have two .JS files

openspace.js
and
APIkey.JS

then openspace will be cached

APIkey will only be one line and not cached

Maybe this is too simple and not possibe !!

Just a thought

Pete (Northolt UK)

OS OpenSpace Team

Posts: 1,117
Registered: 31/01/08
Re: openspace.js massive and uncacheable?
Posted: 04-Nov-2011 08:34   in response to: bigmentor
  Click to reply to this thread Reply

Hi

Thank you for your posts. When OS OpenSpace was first developed, everything (OpenLayers etc) was placed into the JS library and not thinned out but this is something we have now added this to our roadmap and will look at improving for the future.

Unfortunately an API request is not able to be cached beyond a single session. Tiles however, can be cached up to 24 hrs if the browser recognises the expiry tag.

Kind regards
Tamsyn
OS OpenSpace Team

CharlesHarrison

Posts: 488
Registered: 28/08/08
Re: openspace.js massive and uncacheable?
Posted: 04-Nov-2011 14:57   in response to: cparker
  Click to reply to this thread Reply

> Looking at current mapping products for a website and
> amazed that the openspace.js file is so massive!
> Approx 220kb compared to Google Maps; 42kb

I think you are possibly being confused by the use of compression during the transfer. When I compare the file sizes in Firebug and what I get if I save the response contents to disk, there is a marked difference:

Google Loader: 5.8Kb 23Kb
Google Maps (2 seperate loads): 44.0Kb 145Kb

Perhaps Google servers are fully implementing compression, but OS servers are not?

If you load the original OL script direct from the OL site, the current version 2.10 is 961Kb which compresses to 216.6Kb in size, so OS coming in compressed at 220Kb is quite respectable considering the added functionality (though OS is based on v2.8, which may be a different size again).

However, you may be intereseted to know that you can bypass OS altogether and load tiles directly into OL. Three particular pages on my site which use mapping, and which need to load as quickly as possible, do this. However, even so OL's script was taking so long to load from their site that I decided to build my own version of it to include only the functionality required for those three pages, and the result is only 348Kb, which compresses to only 85.8Kb. If you want to know more about this, let me know.

> Plus because of the API key requirement it doesnt
> look like the .js file can be cached by the browser,
> so every page refresh is another 220kb pull.
>
> Are there any plans in the pipeline to reduce this
> size or enable it to be cached locally?

Certainly, any increase in loading speed that can be obtained would certainly be desirable.

prmaps

Posts: 170
Registered: 28/10/08
Re: openspace.js massive and uncacheable?
Posted: 09-Nov-2011 11:04   in response to: OS OpenSpace Team
  Click to reply to this thread Reply

> Thank you for your posts. When OS OpenSpace was
> first developed, everything (OpenLayers etc) was
> placed into the JS library and not thinned out but
> this is something we have now added this to our
> roadmap and will look at improving for the future.

IMO, the OpenSpace classes should be designed/released as an add-on to OL, which can then be included by website developers as needed with a build system like the one released with OL. The same principles that apply to OL builds, like only include the ones you need, also apply to OpenSpace ones. For example, if I'm not using postcode lookup, I should be able to exclude that code. By all means, have the complete library available as a url for those who want to use it, but don't force everyone to download everything whether they use it or not.

prmaps

Posts: 170
Registered: 28/10/08
Re: openspace.js massive and uncacheable?
Posted: 09-Nov-2011 11:06   in response to: prmaps
  Click to reply to this thread Reply

> the ones you need, also apply to OpenSpace ones. For

'ones' here means classes, of course :-)

chadwickBill

Posts: 390
Registered: 07/02/08
Re: openspace.js massive and uncacheable?
Posted: 09-Nov-2011 13:05   in response to: prmaps
  Click to reply to this thread Reply

If you don't wan't to do vectors, then you can load OpenSpace mapping via the fast loading, mobile friendly (pinch zoom) Google Maps V3 API as demonstrated here

http://wtp2.appspot.com/osdemo.htm

Observe however that vector rendering is broke for custom projections and Google have been showing no inclination to fix it over a period of many months. There is a work around for polylines and polygons using a custom svg/vml vector renderer.

If you whish to compose OS OpenSpace mapping with other Google map layers, draw vectors, draw routes, use Streetview etc then you can reproject the OS mapping in the browser as demonstrated here http://wtp2.appspot.com/warpdemo.htm

The first demo gives Streetview access but without the blue coverage overlay. The second demo includes the blue coverage overlay.

prmaps

Posts: 170
Registered: 28/10/08
Re: openspace.js massive and uncacheable?
Posted: 09-Nov-2011 15:34   in response to: chadwickBill
  Click to reply to this thread Reply

> Observe however that vector rendering is broke for
> custom projections and Google have been showing no
> inclination to fix it over a period of many months.

don't think Google are all that interested in supporting non-Google products. The documentation for it is sparse too. OL is much more versatile.

The new version of OL (2.11) has much improved mobile handling and, with the better compression from building with closure compiler, should lead to a much smaller file size. I plan to play around with this sometime soon, and will post some sort of demo.

Perhaps the OpenSpace team can tell us when they plan to incorporate 2.11.

cparker

Posts: 2
Registered: 31/10/11
Re: openspace.js massive and uncacheable?
Posted: 09-Nov-2011 21:25   in response to: cparker
  Click to reply to this thread Reply

Hi All,

Following up from my original post, I decided upon using jQuery.getscript in the end and used a button to show map. (I'm using jQuery already on the page)

This basically allows the page to load very fast and then the user decides whether they need the map, therefore quick page loads and saving bandwidth and not hammering OS either for every page refresh. Additionally should OS be offline with a problem, the page will still load and not hang, obviously minus the map :)

Here is my code;

** Load jQuery
<script type="text/javascript" src="jquery.js"></script>


** The FORM **
<form><input id="loadButton" onclick="initLoader();" type="button" value="Click to Show Location on OS Map"></form>



<script type="text/javascript">
var osMap, postcodeService;
function initLoader()
{

$.getScript('http://openspace.ordnancesurvey.co.uk/osmapapi/openspace.js?key=<YOUR KEY>', function(data, textStatus){
console.log(data); //data returned
console.log(textStatus); //success
console.log('Load was performed.');
osMap = new OpenSpace.Map('map');
var pos = osMap.setCenter(new OpenSpace.MapPoint(438760,114760), 9);
postcodeService = new OpenSpace.Postcode();
postcodeService.getLonLat('<?php echo $db_field['pf_postcode'] ?>', onResult);
return false;
});
}
function onResult(mapPoint)
{
osMap.setCenter(mapPoint, 7);
}
</script>

Note this still has debug code and just an initial proof of concept with a postcode lookup from a PHP database dropped in there.

Hope this helps future OpenSpacers :)

Cheers

chadwickBill

Posts: 390
Registered: 07/02/08
Re: openspace.js massive and uncacheable?
Posted: 09-Nov-2011 22:47   in response to: prmaps
  Click to reply to this thread Reply

OpenSpace mapping in OL2.11 sounds a good way to go. It would be nice if OpenSpace was quicker at catching up with OL.

A port of my GmapsV3 reprojection layer to OL would enable the composition of a wide selection of Google projection (EPSG:900913) map layers with OpenSpace mapping (EPSG:27700) . As an alternative, OS have acknowledged previous forum threads that have suggested that they serve both UK projection and Google projection map tiles.

If you do persue OL2.11 you might like to use the high accuracy (> proj4.js in OL I think) UK grid to WGS84 LatLon conversion in grid-projection.js at
http://osgbwebmaptools.sourceforge.net/OSGBWebMapTools.html - but you will want to minify it etc .

prmaps

Posts: 170
Registered: 28/10/08
Re: openspace.js massive and uncacheable?
Posted: 10-Nov-2011 09:46   in response to: cparker
  Click to reply to this thread Reply

> This basically allows the page to load very fast and
> then the user decides whether they need the map,
> therefore quick page loads and saving bandwidth and
> not hammering OS either for every page refresh.

yes, this is fundamental for browser code: only load things when users actually request them. For larger systems I've started using require.js to load chunks of code on demand. There's talk of structuring OL3 so this becomes easier, but at the moment it's only partly possible to load OL in a 'modular' fashion.

Google have put quite a lot of effort into streamlining the loading of browser code (which is why Bill's demo loads so quickly), but then when you have Google's resources . . .

prmaps

Posts: 170
Registered: 28/10/08
Re: openspace.js massive and uncacheable?
Posted: 10-Nov-2011 10:24   in response to: chadwickBill
  Click to reply to this thread Reply

> A port of my GmapsV3 reprojection layer to OL would
> enable the composition of a wide selection of Google
> projection (EPSG:900913) map layers with OpenSpace
> mapping (EPSG:27700) . As an alternative, OS have
> acknowledged previous forum threads that have
> suggested that they serve both UK projection and
> Google projection map tiles.

There's talk of having some reprojection ability in OL3 - I think similar to what you've done in your program - perhaps you could submit your code as a patch? I'm not a great fan of Mercator myself, as it's so inaccurate, particularly at the lower zoom levels. I deal with maps from a lot of different European countries, and they pretty much all use a different projection. Most of them make their tiles available in EPSG:4326 as well as their own projection, but I don't think any of them use 'Google Mercator'. Most of them also have aerial photography on their servers, and it would be nice if the OS would make some of their collection available on OpenSpace.

> If you do persue OL2.11 you might like to use the
> high accuracy (> proj4.js in OL I think) UK grid to
> WGS84 LatLon conversion in grid-projection.js at
> http://osgbwebmaptools.sourceforge.net/OSGBWebMapTools
> .html - but you will want to minify it etc .

have you found that to be significantly better than proj? I've always assumed that the difference would be negligible at the sort of scales we've got on OpenSpace, and I've not noticed any problems overlaying vectors.

chadwickBill

Posts: 390
Registered: 07/02/08
Re: openspace.js massive and uncacheable?
Posted: 10-Nov-2011 13:05   in response to: prmaps
  Click to reply to this thread Reply

If you search the threads on this forum, you will find that OsgbWebMap's grid-projection.js (as used in OpenSpace) is accurate to better than 2m over the standard OS test data set. I suspect proj4 might use a simpler WGA84OSGB1936 datum shift and so be slightly less accurate.

The most zoomed in OpenSpace mapping uses 1m pixels - consistent with the use of the OsgbWebMap conversion code.

chadwickBill

Posts: 390
Registered: 07/02/08
Re: openspace.js massive and uncacheable?
Posted: 10-Nov-2011 13:12   in response to: chadwickBill
  Click to reply to this thread Reply

Several requests to add imagery to OpenSpace have been made in the past and been declined by OS. I believe their thinking is that their imagery is 'premium product' (better than that Google/Bing serve) and so not appropriate for free release.

From an OpenSpace web site maker's point of view it would be nice if OS would host the same imagery as Google/Bing but reprojected to UK grid.

CharlesHarrison

Posts: 488
Registered: 28/08/08
Re: openspace.js massive and uncacheable?
Posted: 10-Nov-2011 15:52   in response to: prmaps
  Click to reply to this thread Reply

> > This basically allows the page to load very fast
> and
> > then the user decides whether they need the map,
> > therefore quick page loads and saving bandwidth
> and
> > not hammering OS either for every page refresh.
>
> yes, this is fundamental for browser code: only load
> things when users actually request them. For larger
> systems I've started using require.js to load chunks
> of code on demand.

Yes, I have a similar system, Requests.js, and an add-on for OS requests (for example, postcode lookups), UKOSRequests.js

> There's talk of structuring OL3 so
> this becomes easier, but at the moment it's only
> partly possible to load OL in a 'modular' fashion.

That would certainly be good.

One of the things I've noticed in pages like, for example, my satellite dish and TV aerial alignment calculators, which have both Google and OL/OS maps as well as requiring a lot of other ad-hoc script loading, is that I now have triplicate asynchronous loading mechanisms, (UKOS)Request.js, one in the Google code, and one in the OL code. It would be nice if we could all agree on just one and use that, instead of multiplicating code.

> Google have put quite a lot of effort into
> streamlining the loading of browser code (which is
> why Bill's demo loads so quickly), but then when you
> have Google's resources . . .

Yes, although in the past I have encountered problems with their loader.

Legend
Expert: 51 - 1000 pts
Advanced: 31 - 50 pts
Intermediate: 16 - 30 pts
Novice: 5 - 15 pts
Newbie: 0 - 4 pts
Helpful Answer
Correct Answer

Point your RSS reader here for a feed of the latest messages in all forums