I know this is not nearly as straightforward as it is with the Maps API v3, but what would be the best way to effectively limit the zoom or viewable area (if the latter is even possible) with the Earth API? We are trying to prevent people from inadvertently zooming out too far when navigating the small focus area of our map.
Untested, but my first attempt would probably be to listen for the viewchanged event, and check the current view to see if it matches your criteria. If not, you could then flyTo something within your view, and hopefully the effect would be somewhat smooth (but I'm not too sure it would be totally smooth).
See http://code.google.com/apis/ajax/playground/#viewchange_event_(and_viewchangebegin,_viewchangeend) for an example of checking for the viewchanged event.
Related
Background
I'm writing a browser extension which paints over the map of komoot.com/plan.
Currently I do this by placing a canvas on top of the existing canvas.
This works well but it is static and does not yet react to when the user moves the map around or zooms into it or the website focusses a particular location on the map.
Question
How do I best tie into this event loop of map updates?
Approaches considered
I could mimic / reimplement how komoot processes user input, but this sounds fragile and unreliable and messy. I would do this by adding listeners for mouse button events and cursor movement, etc.
The page's URL contains the lat and long coordinates together with the zoom level, e.g., https://www.komoot.com/plan/#49.9535480,5.3956956,11.345z. It changes after the map has changed. I assume there's a way to be notified of changes in the URL. If so I could then dynamically update my canvas.
This would still require some level of imitation of the page's internals. However, considerably less so than option 1.
Doing so I could only update my canvas after the animation is finished. Not a deal breaker but ideally I'd want to update it frame by frame together with the map itself for a more pleasing user experience.
Additional Details
Komoot seems to be using mapbox-gl
It's a Manifest 2 Content Script extension
This is my first browser extension ever
I'm writing this in Scala.js using this excellent template
Don't let this keep you from posting javascript solutions or pointing me to javascript documentation!
Screenshot
You don't seem to have mentioned the obvious way: use the move event:
map.on('move',e => {...
// get center with map.getCenter()
});
But it's not really clear exactly what you're trying to do, so hard to advise more specifically.
I'm using the leaflet L.esri.dynamicMapLayer to display a large amount of polylines on the map, and the export request to ArcGIS Server to draw them can take a while. If the user quickly makes several zooms or pans, I can end up with a bunch of pending export requests, which also blocks other requests to ArcGIS Server. All those export requests except the last are useless.
For other client side layers, I'm already controlling the refresh by making sure the user has stopped zooming or panning for at least 2 second before refreshing the layers myself. How can I do the same for the dynamicMapLayer, can I pause or stop the automatic refresh and decide myself when I want the export request to be made?
Note that we cannot use tiles for better performance, because of other reasons the layer must stay dynamic.
How do I prevent a dynamicMapLayer from refreshing on every zoom or pan of the map?
You can not. It is designed that way.
Unless the esri folks redesign that to make a subclass of L.GridLayer instead of L.ImageOverlay, there's hardly any way around it.
I'm already controlling the refresh by making sure the user has stopped zooming or panning for at least 2 second before refreshing the layers myself. How can I do the same for the dynamicMapLayer?
With a horrible, ugly hack. Overwrite the private L.Esri.DynamicMapLayer._update method so that it becomes a decorator over the previous method, e.g. something like:
(function() {
var previousProto = L.Esri.DynamicMapLayer.prototype;
L.Esri.DynamicMapLayer.include({
_update: function(){
throttle(previousProto._update, 2000);
}
});
})();
It's ugly, it's against most good coding practices (overwriting private methods, eeeew), and it might break.
Note that we cannot use tiles for better performance, because of other reasons the layer must stay dynamic.
I disagree. "tiles" doesn't mean "static". You can easily apply cache-busting, or use a time dimension, or send all data to the client and let it slice it into vector tiles for quick rendering, or use something fancier like Carto(DB)'s Torque.
The fact that your Esri tools don't allow you to readily create different sets of tiles, or do not allow for tiled access of changing resources, or do not allow for triggering client-side data invalidations, doesn't mean that it cannot be accomplished.
I am using Google Maps Javascript API for rendering a map. When we zoom out on the map there is a brief moment that we see a grey area (while waiting for new tiles). Is there any workaround for this behavior in order to provide a similar user experience as mobile devices (Google Maps SDK Android and Iphone), where we always see a map on zoom out and not that brief grey area around the map?
The grey area around the map exists because it takes time to access the image tiles over the Internet connection from the server. My presumptiosn as to the reason why the mobile version does not do this are either that they have a special function that accesses the cache instead of re-querying the image on mobile, or that mobile simply has a built-in cache of, say, the entire world at zoom levels 0-3.
In other words, I do not know of a way to avoid the grey space. To get a work-around would require re-writing a good portion of Google's code, specifically to access the browser's cache. Even if you did succeed, a first-time user of the webpage would still get the grey space simply because a cache does not already exist.
My advice is to ignore it, as it is "brief" (and likely will not have much of any impact on the user experience), and that there are no easy fixes.
I try to draw a very large dataset on google map (2500+ rectangles). The rendering of the rectangles take more than 5 secs. The whole page just stuck for the 5 secs, so I am thinking about adding a loading indicator or progress bar during the rendering.
To do this, I need to trap events of rending (start,finish rendering).
I checked the google maps Api documentation, did not find anything useful. Just what to know whether there is some work around or something I miss in the api doc that can help me to trap rendering events.
As of Google Maps v3.14 the answer is no. There's no such event to listen for in the API. If you dug through the code long enough you might be able to find a hack, but given that you're in control of the rectangles you're drawing and you have a count of them, why not iterate the progress bar as you add them? Individually they will render very quickly so whether you iterate the progress before or after each is added to the map should make no difference to the user, despite the fact that it feels like the wrong order to the developer.
This gives an overview of all the events in GMapsV3 http://gmaps-samples-v3.googlecode.com/svn/trunk/map_events/map_events.html
Check if the events you need are there.
my site looks fine untill people start zooming in and out and after hours of work on it and messing with its css I am clueless on how to fix this zoom problem. Should I somehow fix the zoom to a certain level? if so, how can I do it? I tried fixing this zoom issue but putting everything into a table but that isnt really working so I dont know what to do..help..
This is how it looks on safari, its fixed if i adjust my zoom level but initially looks like this:
Then on firefox and chrome looks perfect:
The zoom level of the browser is something that is strictly the domain of the user - it is bad practice to interfere with user-level choices such as page zoom, and usually you are technically unable to do so anyway. A user will zoom a webpage because they wanted to enlarge it, the reasons are their own and an individual site should not (and can not) interfere with that choice.
Instead of fighting the user, you should seek to design your site in such a way so as to make the content the most important thing. You should craft your design in such a way so that when a user zooms (or makes other changes like disabling CSS or Javascript), the content (presumably the point of having a website at all) is the focus.
Using percentages for your layout, using em for font sizes, and other such techniques will increase the accessibility of your site. See articles like http://24ways.org/2007/css-for-accessibility or http://www.w3.org/TR/WCAG10-CSS-TECHS/ for information on using accessible web design techniques.
EDIT
The screenshots demonstrate one of the many pitfalls in trying to prevent accessibility support - different browsers implement zoom in different ways. Some only increase the font size, some enlarge the images, it is not consistent. The trick is to make it not matter, not to prevent it from happening.
Here's an IE fix
http://www.bennadel.com/blog/1354-The-Power-Of-ZOOM-Fixing-CSS-Issues-In-Internet-Explorer.htm
.css
{
zoom: 1
}
Short answer: No, You cannot modify the end user's browser setting for zoom level.
Maybe you should look into CSS patterns for designing sites that zoom nicely. For example I beleive em's zoom better than point based font sizes. etc
take a look at articles like these: http://kyleschaeffer.com/best-practices/css-font-size-em-vs-px-vs-pt-vs/
Also, if you post specific problems we may be able to help solve them on a one off basis