Master Google Maps, Research WWII and Convert Data

Posted on

As I tooled around the web last week looking for anything useful, interesting or entertaining I came across the following four pages that I thought I would share. Hope you like them.

1. Gizmodo.com – 10 Tricks to Make Yourself a Google Maps Master

Google Maps MasterA great up-to-date look at Google Maps and what it takes to master its ins and outs. The bulk of the article deals with using Maps’ search box. That’s great because the search box is full of great functionality that most users probably don’t have experience with. No matter what your level of skill with Google Maps, there is probably a trick or two to learn here.

2. Worldology.com – World War II: Interactive Map

World War II Map

This is a great little Flash based map that gives you an interactive look at the progression of World War II in the European theater. You can visually see the progression of the war and you can read the popup excerpts as you mouse over the different countries. There is even an option to see current political boundaries overlaid on the map. Cool.

3. freegeographytools.com – Download Page

Free stuff is really neat. Free GIS stuff is even neater. Freegeographytools.com is a nifty little blog that focuses on, you guessed it, free geography tools. The download page provides links to many of these tools like data conversion utilities, KML tools and raster tools. It doesn’t seem like the blog has been updated since 2011. There might be better alternative out there but there is still some good information here.

Five Things I Love About the ESRI Javascript API

Posted on

Having worked with both the ArcGIS Silverlight and Javascript APIs I have to say Javascript has been much more fun. There is just something about working on the front end of a web map and being able to have it do so many amazing things. Here are my top five reasons I enjoy working with this API.

1. Your maps are device independent. Unlike the Flex and Silverlight APIs, Javascript and HTML5 can be viewed on almost any device. The obvious advantage here is that you can reach more people with your spatial data.  Of course having the ability to code for multiple devices means having to customize your code for different screen sizes which can turn into a lot of work. Check out this post from the Treehouse Blog for a great primer on responsive web design.

2. Plenty of code samples and live examples. Code samples are a great way to get your own map up and running quickly without having to figure everything out first. While the samples are not perfect they are a good way to discover map functionality that you might want to incorporate.

3. Support for a ton of layer and data formats. From GeoRSS and GeoJSON to KML and shapefile, this API pretty much covers it.

4. Well written API reference documentation. If you are going to use an API (any API) you want to be able to understand it so you can use it effectively. Good documentation is critical for this. The Esri JS API is (in my own humble opinion) extremely easy to read and understand. Each class has all the information you need to use it without having to decode any meanings. Furthermore, there are links from each class to samples that use it.

5.  Editing tools for online editing of SDE data. Let’s be honest, online editing through a web browser is not a great idea if you are trying to build accurate data. However, there is definitely a place for it. If you are trying to outline an area inhabited by a herd of elk or mark an area of weed infestation, browser editing is probably fine.  It is great just to be able to have this ability so more diverse mapping applications can be developed.

Wow, this list was a lot harder to write than 5 Things I Hate About the ESRI Javascript API. One reason is that there are other APIs out there that do a lot of what the ESRI API does (yes I am thinking about OpenLayers). Another reason is that as I write I think about things I would like ESRI to do better or differently. Oh well, you can’t have everything. Let me know what your thoughts are on the ESRI Javascript API – good or bad.

5 Things I Hate About the ArcGIS Javascript API

Posted on 1 Comment

Building a mapping application with ESRI’s Javascript API is a lot of fun. But it can also be a real pain. Here are five things that absolutely drive me crazy when writing an ArcGIS Javascript map.

1. It is based on Dojo. It’s probably just my lack of Javascript programming sophistication but I find Dojo a little hard to work with. Although the API documentation has improved in recent versions, I don’t find it very intuitive. If you are a beginner or new to Javascript, the getting started documents are just plain frustrating. Ben Farrell thinks there are seven stages of learning Dojo including anger and acceptance. I’m not sure if there are really only seven stages but I can attest to the anger and acceptance.

2. It uses multiple versions of Dojo. Here I go again with the Dojo thing. Half of the developer samples on the ArcGIS.com developer’s site seem to be written pre version 1.7 while the others are post 1.7 and rely on the AMD module format.  I understand that version transitions of supporting libraries can be difficult but this is ridiculous. Since the ArcGIS API updated to version 3.6, many of the developer samples have been updated to show the AMD require format. Unfortunately, the transition has been slow and there is still a lot of mixed version code and a lot of live samples are broken. If you are going to upgrade to a new version of your API, let’s have things ready to go.  

3. No built-in label engine for dynamic, on-screen annotationIt seems obvious to me that the users of a map would want to mark it up with text; especially in conjunction with a draw toolbar. Apparently it isn’t obvious to the ESRI developers. Instead we are left to work with with the labelPoints function which uses the geometry server to create an unseen point and then puts a text symbol on top of it.

4. The label engine problem above leads me to my next gripe. The LabelPoints function doesn’t allow line breaks. That means that if you want to label a polygon with something like, oh say, area and perimeter, you have to have it all on one line or call the labelPoints function twice and use an offset. How about we get the ability to at least use a newline character (\n) and be done with it.

5. No out-of-the-box support for a table of contents. There is a lot of debate about whether an ArcGIS-like table of contents is a good thing in a web map. No matter what side of the debate you fall on, the fact is that people are used to using them and users often want the ability to turn layers on and off. There are a few projects out there that attempt  to solve the problem but each has its own limitation and problems.  It is a little surprising that ESRI doesn’t have a solution for this one yet. Or, maybe it isn’t really that surprising.

I have plenty more gripes with the Javascript API than the ones listed above but I don’t want to get too depressing. Also, I actually enjoy developing with the API (most days) and there are some great things about it. If you want to add to my list put it in the comments.

CSS Shorthand for Clean Web Map Styles

Posted on

I see a lot of CSS code written inefficiently and sloppily, even on official and professional sites. It’s not that the code is wrong, it just could be much better. There is really no reason to have to write four lines of code to set a div tag’s margins or style a tag’s background. You can simply use CSS shorthand to get it all into one compact line.

The reason many people don’t use shorthand is because they’ve never taken the time to learn it. Instead, they lean on verbose style rules that spell everything out.   Below you will find a few common examples of CSS shorthand code that might help you when writing your CSS code. This is in no way a definitive guide. It is simply some of the more common properties you will encounter. You can also download a brief CSS shorthand cheat-sheet.

Margin and Padding:

There are four ways to define the four margins and padding of a CSS box.

  1. margin: [top] [right] [bottom] [left];

    Using four values defines each side individually. For example, margin: 1px 2px 3px 4px; would give an element such as a <div> box a top margin of 1px, a right margin of 2px, a bottom margin of 3px and a left margin of 4px.

  2. padding: [top] [right/left] [bottom];

    This notation relies on the same concept as above but now we only need three values to define our padding. padding: 3% 2% 3%; would give our html element a top and bottom padding of 3% and a right and left padding of 2%.

  3. margin: [top/bottom] [right/left];

    Here we only need two values to define our margins. margin 0 auto; gives a zero margin to the top and bottom and centers the <div> within its containing element.

  4. padding: [top/bottom/left/right];

    A single value defines all sides of an element equally. padding: 1em; applies a 1em  pad to the entire html element.

 

Background:

The background property can be defined by this notation –

background: [color] [url(image url)] [repeat] [attachment] [position];

The color property can be defined using hexadecimal(hex) notation, rgb or color names. The image property is written with the prefix “url” followed by parentheses containing the url to the image you want to use for your background. Repeat is used to tile the background image. If you use attachment you can control whether the background image scrolls with the page or not. Position tells the background image what position to start at on the page. The following is an example of a background:

background: #ffffff url(‘greatpic.gif’) repeat-x fixed center;

 

Font:

The font property can be demonstrated by-

font: [size] [weight] [style] [family];

Font size can be defined with a number and a unit such as px, % or em or with size value words like small, medium, large, etc. Weight is simply the thickness of the font characters. Style refers to the values  italic, oblique, normal or inherit. The family refers to the font family like Serif, Georgia or Helvetica. Here is an example:

font: 1em normal italic Helvetica;

 

Border:

Border properties are relatively simple-

border: [width] [style] [color];

The border of an html element is easy to style. You just need to designate the width, color and style. Width can be written using pixels or the pre-determined width designations thin, medium and thick. Style refers to values like solid, dotted and dashed. Color is written the same as in the background property and can be a hex number, rgb numbers or a written color.

border: 2px solid blue;

 

There are a lot more shorthand properties for CSS. Even some of the ones I posted above have further properties that could be included. For a more complete look at CSS shorthand methods check out this page from Mozilla.