As the old saying goes, “The great thing about standards is that there are so many to choose from”. HTML, CSS, and JavaScript are fairly ubiquitous web development tools, and there are plenty of standards surrounding them. Sharing a web page with our visitors should be the easiest thing in the world. Unfortunately, there are as many browsers as there are standards, and each one implements standards differently.
I wish I could just hand you a list of what techniques will work every time, in every browser. But that just isn’t going to happen. Because even when the browsers are working right, there may be graphics issues messing with your display. The only thing that truly works is to look at your site in different browsers.
I don’t think there’s any question that Internet Explorer (IE), Google Chrome, Mozilla Firefox, and Apple Safari are the current top browsers. So it’s important to at least test on those four. But which versions? And because different operating systems use different rendering engines, the same browser will look different in Linux, Windows, and OS X – which one do we use as the standard? Earlier this year, Google celebrated the “death” of support for IE 6, and Microsoft itself has completely abandoned IE for the Mac. Yet there are a handful of people still using those browsers – how much attention should they receive? And that’s just for the desktop – the game changes entirely when you consider mobile web devices with matchbook screens.
Dealing with browsers is in some ways like dealing with small children – at some point, you have to put your foot down. I personally believe that a home user who is still surfing on a 5-year-old browser is going to have problems no matter what tricks and hacks I manage to crank out. And corporate clients, who are attached to an old browser because their IT infrastructure is dependent on an outdated framework are probably not allowed to be visiting my site during work hours, period.
In the end, the best strategy is to cross your fingers. If your web design looks good in Safari, Firefox, Chrome, and IE, I say publish it. It takes a lot of creative coding just to get that far – you’ve already solved 99% of the cross-platform compatibility issues. Let the remaining 1% fall where they may.
For better or for worse, I have three laptops – a Dell running Windows, a ThinkPad running Fedora Linux, and a Mac. Here’s a list of graphical browsers that I test my work on:
- Mac:
- Chrome
- Firefox
- Opera
- Safari
- Windows
- Chrome
- Firefox
- Opera
- Internet Explorer
- Linux
For more information on browser usage statistics, see here:
http://en.wikipedia.org/wiki/Usage_share_of_web_browsers
Almost everyone on the net has had the opportunity to use one of the big four web mapping sites: Google Maps, Bing Maps, Yahoo! Maps, and OpenStreetMap. It’s possible to host a custom map on your own site using one of these services, as long as you have some programming experience. But it only takes a few seconds to make a link to one of these sites. Today, I’m going to explain how to construct a URL which will have your visitors clicking through in no time.
Generally, the URLs contain a number of parameters, separated by ampersands. The order of the parameters normally doesn’t matter. Every map must have a location, and a zoom level and a type identifier are also common. Other parameters are possible, but most are beyond the scope of this tutorial. For the following examples, the mapped location will be Pioneer Square, in downtown Portland, OR. The approximate center of the Square is N45.518885, W122.679327. In each of the examples below, latitude North will be expressed as a positive number, and longitude West will be expressed as a negative number.
Google Maps:
Google Maps is one of the easiest URLs to deconstruct, because the only pieces of information required are the location and the zoom level. The zoom level is an integer specifying the scale of the map, with 1 showing the entire planet, and 20 being just below a square city block. For most of the US, the maximum zoom for satellite images is 21. To map the center of Pioneer Square, at a zoom level of 18, the URL would be:
http://maps.google.com/maps?q=45.518885,-122.679327&z=18
This URL will show the map view, and automatically place a default marker at the location. If you want to link to a different view, you need to add the ‘t’ parameter, signifying what type of map will be shown. Here’s a list of the main types available: ‘e’ is Google Earth view, ‘f’ is an orthographic view with 3-D buildings, ‘h’ is hybrid satellite view (with map overlay), ‘k’ is an orthographic view, and ‘p’ is elevation view. All other values (or no value) default to map view. To use the ‘t’ parameter, just add a simple value after the zoom level:
http://maps.google.com/maps?q=45.518885,-122.679327&z=18&t=h
OpenStreetMap
OpenStreetMap (OSM) uses a construction similar to Google’s:
http://www.openstreetmap.org/?mlat=45.518885&mlon=-122.679327&zoom=18&layers=M
The major difference between OSM and Google is that OSM reads latitude and longitude as separate parameters. If you would like to see a default marker at the location, use mlat and mlon; otherwise, use lat and lon. The zoom level is similar to Google’s, except that 19 seems to be the maximum possible zoom. The final parameter dictates what base layer map to use. ‘M’, the default, represents tiles rendered using the Mapnik library. Other available values include ‘O’ for Osmarender, ‘C’ for the Cycle Map, and ‘N’ for NoName.
Yahoo!
Yahoo!’s construction methods are similar to those used above:
http://maps.yahoo.com/#mvt=m&lat=45.518885&lon=-122.679327&zoom=18
Latitude, longitude, and zoom level are the same as OSM, except that the maximum zoom level is 18. The map type is somewhat different, though – unlike most other mapping parameters, the type must be at the beginning of the URL. Possible type values are ‘m’ for map, ‘h’ for map/satellite hybrid, and ‘s’ for satellite. Unfortunately, this URL does not show a marker at the desired location. To do that, it is necessary to trick Yahoo!’s direction finding service by adding a point called q1. This point will be the same latitude and longitude as our location, but it will be constucted as a single paired value instead of as 2 discrete values:
http://maps.yahoo.com/#mvt=m&lat=45.518885&lon=-122.679327&zoom=18&q1=45.518885,-122.679327
Bing
Bing draws really beautiful maps, but its URL construction is somewhat mysterious:
http://www.bing.com/maps/?v=2&cp=45.518885~-122.679327&lvl=17&dir=0&sty=r
The first oddity is that Bing uses a tilde (~) as the separator between the latitude and the longitude. Bing also uses ‘lvl’ to indicate the zoom, which goes up to 20. There are a number of other parameters here which have little effect on the map, including ‘v’ and ‘dir’. The last parameter, ‘sty’, indicates the style of the map. Possible values include ‘a’ for satellite, ‘b’ (or ‘u’) for orthographic hybrid, ‘h’ for satellite hybrid, ‘o’ for orthographic, and ‘r’ for roads. Convincing Bing to place a marker on the point involves adding an additional parameter, ‘q’, which is a coordinate pair. But note that the coordinate pair for ‘q’ uses a comma instead of a tilde:
http://www.bing.com/maps/?v=2&cp=45.518885~-122.679327&lvl=17&dir=0&sty=r&q=45.518885,-122.679327
Each mapping URL can also use properly constructed string values to designate a particular business or landmark, as opposed to the simple latitude/longitude example given here. However, this activity is left to the user. Experiment by running a search and then examining the resulting URL. Happy surfing!
Reblogged from Slashgeo:
This is certainly major news. Steve Coast, the OpenStreetMap founder, joined Microsoft’s Bing Maps team.
From the announcement: “Continuously innovating and improving our map data is a top priority and a massive undertaking at Bing. That’s why we’re excited to announce a new initiative to work with the OpenStreetMap project, a community of more than 320,000 people who have built high quality maps for every country on earth. Microsoft is providing access to our Bing Aerial Imagery for use in the OpenStreetMap project, and we have hired industry veteran Steve Coast to lead this effort. […] As a first step in this engagement, we plan to enable access to Bing’s global orthorectified aerial imagery, as a backdrop of OSM editors. Also, Microsoft is working on new tools to better enable contributions to OSM.”
Amongst the geoblogs reactions, James Fee provided his analysis of what this really means: ” Microsoft needs to get involved with OpenStreetMap to continue to be relevant in the web mapping space and OSM needs Microsoft, their aerial images, their big pocketbook and their need to dominate all spaces they exist to join up.” All Points Blog shares some more: “I don’t think OSM has all the data inputs needed, nor the paid and unpaid staff needed, nor the smart software needed to win this competition. Not yet anyway, but clearly their backers are slowly adding to their dowry.”
Overall, from the “open data” point of view, it can certainly be considered a major win. Last August, Bing Maps was already offering the OpenStreetMap layer, and MapQuest already dived into OpenStreetMap some time ago.
http://slashgeo.org/2010/11/25/OpenStreetMap-Founder-Steve-Coast-Joins-Microsoft
Good news? Bad news? Personally, I’m going to adopt a wait-and-see attitude. Obviously, an infusion of cash and resources could go a long way toward supporting the OpenStreetMap project, which would benefit everyone. But Microsoft has a history of acquiring and then consuming small companies, consortia, and standards. Only time will tell how this will play out. Hopefully, the OpenStreetMap players will keep their eyes open.
In the beginning, there was the command line – a text-only interface that controlled the computer. Typing and squinting in front of a terminal provided a lot of power to experienced users, but inexperienced users demanded something easier to use. Later, when memory and peripherals became cheap, the point and click interface was born, allowing simple device gestures to abstract the text interface. These days, it is almost unnecessary to type at all.
GIS, like most IT professions, is slowly edging out the command line for most users. Many years ago, students were required to learn ESRI’s text-only ARC/INFO interface, because it was the only way to access much of GIS’s real power. Now, one can complete a course in GIS without even using a command line once. However, the text-based interface is still around. Many users, especially in the back office, are building Python scripts and constructing their own SQL statements. And a good Linux server administrator needs to be able to seamlessly navigate the command line.
Rarely, one will come across a situation where the command line is the only viable option. As an example, this evening I found myself needing to run an SQL script remotely on one of my web hosts. The purpose of the SQL was to populate a PostGIS table with over 90,000 records, which made for an extremely long script. The web host was kind enough to provide phpPgAdmin, a highly useful graphical frontend for PostgreSQL, which helps users to upload and execute an SQL script. But the script file was so large that the operation timed out before it could complete. Fortunately, the web host also provided ftp and ssh access. I was able to upload the script file, and then use a remote terminal to execute the script. The whole operation only required three lines of code – yet without those three lines, the entire project would have stalled.
So an argument can definitely be made that most daily GIS users do not need to know much about the command line. But I’d like to counter-argue that just a few lines of code can exponentially expand one’s bag of tricks. Knowing how to do common operations more than one way makes a person more flexible, more adaptable – and ultimately more valuable.
Occasionally, when knocking up a demo or a quick project in ArcGIS, you may find that your scale bar is lying to you. In the majority of cases, most GIS users don’t even take notice of their scale bars, much less question the veracity of the distances implied. However, if you have a projection or units disagreement, the scale bar will be noticeably incorrect. There are two warning signs that this is happening to you. First, the scale will be wildly incorrect – a distance of 500 feet might read as five miles, for example. And second, there will be unnecessary decimal precision in the scale bar’s divisions. New or inexperienced users may feel frustrated by this, because ArcGIS (as of version 9.3) does not allow the user to set the actual range of the scale bar. It might make sense to force ArcGIS to produce a four inch scale with one-inch and half-inch divisions, which would make the numbers nice and even – but then the scale bar couldn’t scale if the scale is changed. So the ranging of the scale bar is better left to automated and dynamic processes when working on the Desktop.
Figure 1: Data frame properties dialogue box, ArcGIS 9.2
Fortunately, this problem is easy to fix. It’s not actually a scale problem: it’s a units problem. Take a look at the ‘General’ tab of the Data Frame Properties dialogue box (figure 1). There are two different units that need to be set: the map unit, and the display unit. If all of your layers are projected correctly, the map unit will be auto-filled, and the dropdown will be inactive (grayed). So the first thing to do is make sure your projections are squared away. In most cases, making sure all the layers are being projected correctly will solve this problem. But occasionally, you may end up working with a set of layers that doesn’t have a projection. If none of the layers has a projection, the map unit will be set to ‘Unknown Unit’, and the dropdown will be active. This problem can be easily remedied by selecting the correct map unit from the dropdown. Then you can set your display unit to whatever makes sense for the project. Generally, it is best to keep the map unit and the display unit the same. Different units make comparing measured distances with actual distances difficult, and can lead to general confusion.
What happens when you don’t know what the map unit is? The first thing to do is look for metadata. Metadata should include the measurement unit for every field in the dataset, including any spatial layers. However, if you don’t have a projection, you probably don’t have any metadata either. In that case, the best you can do is guess. I’d start with a roads layer, if you have one. Each segment of the road network will have a length available. US datasets will generally contain lengths in feet and areas in square feet. Assume that the length is in feet, and then convert that value to miles. Does that make sense? If it does, give feet a try. If it seems three times too large, then the map unit is probably meters. Eventually, you’ll find the right unit.
Did you know that November 17th is GIS Day? Probably not. GIS Day is an awareness campaign, sponsored by ESRI, which is designed to increase the visibility of the spatial arts. Which is important, because I don’t think GIS has become part of the everyday lexicon yet. Whenever people ask me what I do for a living, my answer always bewilders them. I usually end up telling them that I make maps with the computer – it’s just easier than describing the complex relationship between cartography, database management, and spatial modeling that GIS embodies.
I’m sure all the other GIS blogs out there are linking their visitors to gisday.com and ESRI’s gis.com. I thought it would be fun instead to link to some of the lesser known online resources that GIS professionals are using.
Color Brewer is a neat application that helps you cook up attractive and usable color schemes for your thematic maps:
http://www.personal.psu.edu/cab38/ColorBrewer/ColorBrewer_intro.html
Spatial Reference has a comprehensive catalog of spatial reference systems and projection info. Each system is available in a wide number of formats, including JSON, WKT, and XML:
http://spatialreference.org/
Getting tired of the icons and symbols included in your desktop GIS? Here’s a very large collection of replacements, in convenient scalable vector graphics (SVG) format:
http://www.sjjb.co.uk/mapicons/contactsheet
With today’s focus on green energy, GIS professionals in the land use and development fields will increasingly be called upon to calculate the solar potential of the building site. Sustainable By Design hosts a number of tools that can help you calculate solar angle, solar path, and even helps design window shades:
http://www.susdesign.com/tools.php
In a similar vein, the US National Renewable Energy Laboratory provides a number of different wind energy resources, which can be used to estimate the wind potential of a site:
http://www.nrel.gov/gis/data_analysis.html
Hope everyone has a happy GIS Day!
Hello, and welcome to Northwest Spatial Solutions! We are a small independent geographic consulting company working out of the Seattle area. Our main interests are GIS, cartography, and dataset maintenance, and our services are provided on a contract or freelance basis. We are professional, secure, and knowledgeable.
In this blog, we’ll be sharing news from the world of spatial technology, and tips for GIS users. We hope you find this information useful. If you would like to leave a comment or join a discussion in progress, please remember to be civil and clean – posts containing foul language and inappropriate content will be deleted immediately.
Thanks for joining us!
