Average users don't care about zoom level numbers, but some people do. Developers do.
I created a 'semihidden' zoom level display for my pages. Google provides hints like "zoom in" and "zoom out" if you hover the zoom control element (slider). I thought that average map users already know those things.
Try hovering zoom slider of the first quadtree example page. Yes, hovering the zoom slider will display also meters/px resolution. That is an extra bonus for those who are interested in the World.
Have a look in the source code. It is commented there as "zoom tooltip hack". Feel free to copy the hack, if you like it. You can molest the code any way you like. Shall this post be the license.
Sunday, May 08, 2011
Thursday, May 05, 2011
Distance Matrix
Distance Matrix service was introduced in the latest update of v3 API. It returns maximum 100 driving distances and durations by a single request. Reference.
All of you who have a store locator, can now add true driving distances and estimated driving times in search results. Also you can filter out results that exceed a distance limit. If user searches by 100 km radius, you may want to return only results that have a true driving distance less than 100 km.
It is like driving directions without directions. Some people have tried to implement something similar by making multiple driving distance requests. Many of them faced problems with the asynchronous responses not coming back in the same order that requests were made. The new service is very simple to use.
It has travelMode option too. So it can be used for walking distances in city maps.
This is a useful service.
All of you who have a store locator, can now add true driving distances and estimated driving times in search results. Also you can filter out results that exceed a distance limit. If user searches by 100 km radius, you may want to return only results that have a true driving distance less than 100 km.
It is like driving directions without directions. Some people have tried to implement something similar by making multiple driving distance requests. Many of them faced problems with the asynchronous responses not coming back in the same order that requests were made. The new service is very simple to use.
It has travelMode option too. So it can be used for walking distances in city maps.
This is a useful service.
Thursday, April 28, 2011
Quadtree
Quadtree is a powerful spatial indexing technique. Wikipedia.
Every now and then I been thinking to implement a collision detect function using quadtree. Playing with quadtrees is so fascinating that I haven't got as far as collision detect, but I have a simple general quadtree demo page online. Play with it. It's inspiring.
If you are interested in experimenting, I enclosed the basic functions in QT.js library. The collision detector will be there too but I have some different applications in mind first.
Every now and then I been thinking to implement a collision detect function using quadtree. Playing with quadtrees is so fascinating that I haven't got as far as collision detect, but I have a simple general quadtree demo page online. Play with it. It's inspiring.
If you are interested in experimenting, I enclosed the basic functions in QT.js library. The collision detector will be there too but I have some different applications in mind first.
Monday, March 14, 2011
Category sidebar - there is no sense without priority
Thanks for many of you that been applying the category sidebar script I wrote a long time ago for v2. Sure It works on desktop but what happens if all the entries don't fit in the limited viewport of a mobile browser?
Web has changed since. Now we have to make pages that can be used by mobile browsers too. The screen size can be equal or smaller to the first Mac.
The idea of 'gategory' is still living strong. I have extended makeMarker so that each marker has a 'cat' property. If you click one category visible, all those markers and their sidebar entries do not simply fit in view in iPhone. Also remember that mobile 'touch' devices do not support scrollbars at all. They simply cut the material! (People are shouting about Flash, hehe!)
We have to bring one more parameter to a marker - that is priority. In my current design, the default priority is the distance from map center.
The smallest mobile screen can display a sidebar with a few (<10) entries. You have to decide, which of those 1000 they are.
Ideas?
Web has changed since. Now we have to make pages that can be used by mobile browsers too. The screen size can be equal or smaller to the first Mac.
The idea of 'gategory' is still living strong. I have extended makeMarker so that each marker has a 'cat' property. If you click one category visible, all those markers and their sidebar entries do not simply fit in view in iPhone. Also remember that mobile 'touch' devices do not support scrollbars at all. They simply cut the material! (People are shouting about Flash, hehe!)
We have to bring one more parameter to a marker - that is priority. In my current design, the default priority is the distance from map center.
The smallest mobile screen can display a sidebar with a few (<10) entries. You have to decide, which of those 1000 they are.
Ideas?
Friday, December 10, 2010
v3 Marker z-index, the way I thought it was
The way it is
Marker.getZindex() returns 'undefined' if you did not set any value for it. Looking under the hood reveals that actually there is a latitude dependent value set for the marker DOM element. The value seems to be equal to 'top' position of the marker in map container. That is clever. It takes care that markers are displayed in right order by latitude (South on front). But why is the value not returned?
Set any value for Marker z-index. Now getZIndex() returns the value and that set for the Marker DOM element. So setting a z-index value of your own ruins the order set by API.
The way it might be
User z-index and actual DOM z-index should be separated.
Markers should have the default DOM z-index as it is now.
Marker.getZindex() should return zero if you did not set any z-index.
So user z-index would be relative to the actual DOM value.
API would take care of order by latitude (of overlays with equal z-index) like it currently does without any z-index settings.
Why
That would make the zIndex property of Marker, Circle, InfoWindow etc much easier to use. Currently you have to rewrite all the z-index values if you want to raise z-index of a single marker..
I have a feeling that it was originally meant to work that way.
Marker.getZindex() returns 'undefined' if you did not set any value for it. Looking under the hood reveals that actually there is a latitude dependent value set for the marker DOM element. The value seems to be equal to 'top' position of the marker in map container. That is clever. It takes care that markers are displayed in right order by latitude (South on front). But why is the value not returned?
Set any value for Marker z-index. Now getZIndex() returns the value and that set for the Marker DOM element. So setting a z-index value of your own ruins the order set by API.
The way it might be
User z-index and actual DOM z-index should be separated.
Markers should have the default DOM z-index as it is now.
Marker.getZindex() should return zero if you did not set any z-index.
Setting a z-index value would be added to the default value.
So user z-index would be relative to the actual DOM value.
API would take care of order by latitude (of overlays with equal z-index) like it currently does without any z-index settings.
Why
That would make the zIndex property of Marker, Circle, InfoWindow etc much easier to use. Currently you have to rewrite all the z-index values if you want to raise z-index of a single marker..
I have a feeling that it was originally meant to work that way.
Saturday, October 16, 2010
Automatic API v3 reference
I have a test page that analyzes contents of google.maps namespace. I've had it for a long time. The trouble was that controlling the version needed some hackery with v3. Now when the version control was released, I decided to polish and share the page. Actually it is a site of three pages, one for each version. Frozen (3.0), Release (3.1) and Nightly (3.2).
API v2 is from 2005 and no namespace thinking was applied. The constructors and all the stuff that v2 offers is introduced in global scope. I never faced any troubles with that but nowadays some people like it as 'bad programming practice'. Actually it really was much trickier to write a similar test page for v2. Global scope (window) has a lot of stuff that is introduced by the browser and must be filtered.
The test page scans google.maps object by a for-in loop. No rubbish is found and no additional filtering is needed. The results contain the constructors and some objects. Those are listed on page and also on the index in the header. All the members that were found are scanned by a for-in loop again. This time looking inside prototype objects. If prototype is not found, the object itself is looped. Resulting properties are listed in a row.
The pages are coded for Firefox only. Firefox presents some unique features for this kind of work. One of them is .toSource() method of Object. It creates a string representation of source code. Firefox presents source code in nice prettyprinted format in alert() dialog box.
With Firefox, you can click any listed method on page and see its internal code. Also there are links to search the method name from documentation, API forum or Google Code Search.
The resulted listing proves that API v3 is written following good programming practices. Almost no internal variables are leaking. The internal source code of the constructors and their methods doesn't reveal much. Still it is worth exploring, you always find something that deepens your understanding about API.
The documentation practice of v3 is different to v2 in the way that there are not many undocumented methods in v3. Still you can find some. Today I saw some new methods of Marker.
You can use the pages for comparing versions. Yes, they are documented separately but still you can find something meaningful.
API v2 is from 2005 and no namespace thinking was applied. The constructors and all the stuff that v2 offers is introduced in global scope. I never faced any troubles with that but nowadays some people like it as 'bad programming practice'. Actually it really was much trickier to write a similar test page for v2. Global scope (window) has a lot of stuff that is introduced by the browser and must be filtered.
The test page scans google.maps object by a for-in loop. No rubbish is found and no additional filtering is needed. The results contain the constructors and some objects. Those are listed on page and also on the index in the header. All the members that were found are scanned by a for-in loop again. This time looking inside prototype objects. If prototype is not found, the object itself is looped. Resulting properties are listed in a row.
The pages are coded for Firefox only. Firefox presents some unique features for this kind of work. One of them is .toSource() method of Object. It creates a string representation of source code. Firefox presents source code in nice prettyprinted format in alert() dialog box.
With Firefox, you can click any listed method on page and see its internal code. Also there are links to search the method name from documentation, API forum or Google Code Search.
The resulted listing proves that API v3 is written following good programming practices. Almost no internal variables are leaking. The internal source code of the constructors and their methods doesn't reveal much. Still it is worth exploring, you always find something that deepens your understanding about API.
The documentation practice of v3 is different to v2 in the way that there are not many undocumented methods in v3. Still you can find some. Today I saw some new methods of Marker.
You can use the pages for comparing versions. Yes, they are documented separately but still you can find something meaningful.
Tuesday, April 27, 2010
Circle in v3
Circle object of v3 creates a circular overlay as expected. It is more useful than I first thought.
If you want to zoom your map to show an area of say 50 km radius, that would mean some maths. Create a Circle() of 50 km radius and take its bounds by now provided getBounds(). You can use the bounds to zoom the map by fitBounds(). No calculations needed. An example.
Circle can be used as a marker as well. It is clickable and it works as an anchor for InfoWindow. Marker keeps its size when you zoom. Circle does not but Circle has a minimum size based on stroke width. That is actually nice behavior in many cases. Now there is an updated version of makeMarker(). It creates a Circle instead of Marker if you set any value to 'radius' option.
'title' option does not create a flyover tooltip. However Circle supports all the usual mouse events. So you can create a custom tooltip for the purpose.
If you want to zoom your map to show an area of say 50 km radius, that would mean some maths. Create a Circle() of 50 km radius and take its bounds by now provided getBounds(). You can use the bounds to zoom the map by fitBounds(). No calculations needed. An example.
Circle can be used as a marker as well. It is clickable and it works as an anchor for InfoWindow. Marker keeps its size when you zoom. Circle does not but Circle has a minimum size based on stroke width. That is actually nice behavior in many cases. Now there is an updated version of makeMarker(). It creates a Circle instead of Marker if you set any value to 'radius' option.
'title' option does not create a flyover tooltip. However Circle supports all the usual mouse events. So you can create a custom tooltip for the purpose.
Subscribe to:
Posts (Atom)
