The Google GEO APIs team developed a KML Interactive Sampler page. Now people, who want to learn KML, can learn by examples. The Sampler page uses the Google Earth Plugin to demonstrate various features while displaying KML code.

Next week, George Mason University and the University of Virginia are celebrating GIS Day(s). They invite the general public to their GIS festivities. GMU’s featured speakers include Carmel Menzel, ESRI and Justin Procopio, National Geographic Society. David Rumsey, an expert on historical maps, will speak at UVA’s GIS Day.

The Google Maps API terms of service is causing the Ordnance Survey grief. The OS was unhappy with local authorities signing up to the Google Maps API terms of service as it required a “broad” re-licensing of the data to Google and the users of Google maps based sites. According to the OS, Show Us a Better Way broke copyright regulations by embedding info on Google Maps that was “derived” from OS data. Yesterday, Google released an updated Terms of Service for both Google Maps and Earth. For OS’ sake, the new published terms should help solve this issue.

Google announced the Google Geo Challenge Grants. The challenge encourages organizations, especially non-profits, to use maps as mediums to communicate issues and implement plans. The grants range from US$5,000 and US$100,000. For more the challenge guidelines, visit the Geo Challenge page.

Yesterday was “Make Slashgeo Known to the Community Day!” We encourage our readers to also show their support for our fellow GeoFriend!

Popularity: 16% [?]

There has been an interesting discussion going over on James Fee’s blog on the merits of ESRI’s new javascript API and Flex API. James has thrown his lot in with the JavaScript API, and a host of Flex/Flash developers have been exposing their technology’s merits. While we don’t use either of ESRI’s APIs internally we did have to make a choice between Flash and JavaScript/HTML when we were developing Maker. At the end of the day we ended up blending the two approaches – implementing JavaScript where it made sense and utilizing Flash when we needed powerful vector rendering capabilities.

One of the most useful references for me in this process was a workshop Tom Carden gave at ETech last year on the data rendering capabilities of a variety of approaches. The readers digest version of the workshop went something along these lines:

HTML/Javascript – handles 100-1000 data points – loads in .1 seconds
Flash – handles up to 10,000 data points – loads in 1 second
Java/Processing – handles up to 100,000 points – loads in 10 seconds
OpenGL – handles upwards of 1,000,000 points – loads in 100 seconds

For Maker we wanted to be able to handle 10,000+ points/polygons and there was no way JavaScript was going to be able to handle it. Of course rendering the data was just one of many problems. Not only did we have to render the data but also parse it from the server out to the client while running the mathematical operation enabling you to take advantage of the structured data being sent. The team came with lots of clever tricks to pull it off, but the level of performance afforded by using Flash for rendering the vector data was not available with JavaScript. Processing could be a very cool option as the technology matures. Silverlight could also be a great option if they can get the plug-in universally embedded into browsers as with Flash.

While Flash was a great option for the tiling and vector rendering we did not want to build out the entire application in Flash for a variety of reasons. In GeoCommons everything outside of the map itself is JavaScript/HTML. This is probably rudimentary for many folks, but reading the debate on James’ blog I think sometimes developers lose sight of picking the best tool for the job. Oftentimes it is easy to get wedded to an approach just because it is what you know well. We were complete Flash rookies when we started, but got some great help from Tom with Modest Maps, Axis Maps with the Flash development and cartography, hired some full time resources, and learned a lot on our own. It ended up being a great approach for the specific problems we were facing. As long as you are using standard interfaces in your development, you should be able to fluidly adapt to the technology that makes the most sense for your set of problems.

Popularity: 25% [?]

*Post updated at 2:00 PM, September 9, 2008 to reflect blogs we missed. Our next edition will include ONLY the top 25 blogs, but we wanted to keep all on the original list from this week.*

Here at Off the Map we’re always interested in what bloggers have to say about new technologies and services in GIS and on the GeoWeb. With our interest in cartography through the development of Maker!, we’ve broadened the categories beyond just GIS and GeoWeb blogs.

We decided to have a little fun and do a friendly ranking of some relevant blogs. The Top 25 Blogs in GIS, GeoWeb and Cartography will be ranked according to the number of sites/blogs linking to each, as reported by Technorati. If a blog does NOT have Technorati Authority (if they have not registered for example), then we’ll take the number of blog reactions listed and divide by 3 for an estimate.

We realize Technorati is not a perfect barometer, but it is open, and this is not a FortiusOne subjective ranking. We think this will be a great way to share blogs and get feedback from others regarding their top GIS, GeoWeb and cartography blog picks. We’ll note changes in rankings, new blogs and up and coming blogs.

If you’re on the list and feel so inclined, you’re welcome to place the following badge on your blog to share your ranking.

Our first ranking follows. We’ll be updating the list bi-weekly and note changes in ranking and inbound links. Since we’re only doing a Top 25 list, we’d like to give a shout out to some other great blogs out there such as Indiemaps and Cartogrammer. If there is another blog you feel should be included, please let us know!

1. O’Reilly Radar Geo Blog 2,733 – overall O’Reilly (5 Blog reactions for Geo Blog)
2. Strange Maps 1,895
3. Google Earth Blog 950
4. Google Maps Mania 553
5.  Ogle Earth 186
6. All Points Blog (Directions Magazine) 176
7. James Fee GIS Blog — Blogging GIS, Google Earth, Virtual Earth and Programming 156
8. The Map Room: A weblog about maps 139
9. The Beer Mapping Project 91
10. Geobloggers 73
11. Mapperz 72
12. Very Spatial (Blog and Podcast) 66
13. Bret Taylor’s Blog 64 (estimate based on 195 Blog Reactions)
14. Mibazaar 61
15. Dave Bouwman – GIS Blogs: Where’s the Conversation? 53
16. Ed Parsons 52
17. What is so special about Geospatial? 52
18. Chris Spagnulo’s Geoscrum 51
19. AnyGeo – Anything Geospatial 46
20. Mandown 35
21. The Earth Is Square 35
22. Mapdango 34
23. GIS Lounge 31
24. Mapping Hacks 28
25. Geography Matters – Est. 27 (based on 83 blog reactions)
26. Geospatial Semantic Web 26
27. Vector One 26
28. Computing, GIS and Archeology in the UK 23
29. GeoNames Blog 18
30. GeoMusings 14
31. Slashgeo 14
32. Geocarta 12
33. Webmapper 10
34. Sean Gillies 10
35. Indiemaps 8
36. Cartogrammer 7
37. Geography 2.0 2

Popularity: 60% [?]

When Laurie was working on her blog post covering the geopolitics of oil, she asked Raj and I to help out with creating some maps. She had some nice data showing the known oil and natural gas reserves around the globe. Specifically, she wanted some 3D maps to really show the relative amounts of oil and natural gas in different geographies.

Creating the map presented us a classic cartographic decision – should we do a data visualization or a data analysis? While this is a very distinct difference, I think it gets largely lost by most GeoWeb users, and hopefully this little example will help illustrate the importance of the difference.

For Laurie’s maps she wanted to show the relative amounts of known natural gas and crude oil around the globe. The data set she had collected from the USGS provided polygons where petroleum and natural gas were located. The most straight forward way to map the data was to create a thematic map shading the polygons based on the amount of oil or natural gas contained in each. In cartographic circles this is called a choropleth map. Below is an example of a choropleth map in Maker! with the oil data from Laurie’s post:

Known Petroleum Reserves

You could also use the centroid of each polygon to make a proportional symbol map – where the size of the symbol is representative of the amount of oil or natural gas in the location. Here is an example of using the natural gas data set but rendered as proportional symbols:

Known Natural Gas Reserves

Proportional or graduated symbols are a great choice when you have small polygons with high values that might get lost in a choropleth map with many large polygons. For instance in the oil reserve map Venezuela has a very high oil reserve, but since the polygon is quite small it is easy not to notice it on the map.

Another technique for getting small places noticed is using extruded polygons, which are 3D. Bjorn Sandvik has done a great job promoting these techniques in Google Earth with his Thematic Mapping Engine. Below is an example of the oil reserve data as extruded polygons on a 3D globe:

3D globes have some shortcomings like accuracy and not being able to see the whole globe at once, but offer a great dynamic way to interact with data. For the geopolitics of oil, we decided to go with creating a thematic map using extruded polygons but on a 2D projection of the earth. That way we could see all the continents and curvature of the earth accuracy would be diminished. While not as cool as Bjorn’s virtual globe maps they got the job done:

A second option we looked at was doing a spatial analysis of the oil data. Instead of visualizing the data values for the polygons, we did an analysis of the spatial distribution of the data. In this case we thought it would be interesting to analyze the spatial density of the oil reserve locations. To do so we needed to convert the polygons to points based on the centroid of each polygon. Then we could run a kernel density analysis of the data. This sounds fancy, but it’s really just placing a grid over the data and tabulating counts for each cell with a bit of fancy math for smoothing to create a continuous surface. While this is not terribly complex, it is much different than just visualizing the data. The results of the density analysis for the oil data can be seen in the map below:

We ended up not using the density analysis because it was not really accurate since the source data had been polygons and not points. If the source data had been well locations weighted by oil production it would have been spot on.

The confusion between geodata visualization and analysis was one of the reasons we deprecated GeoIQ (sometimes called heatmaps for Google maps). Spatial density analysis has popped in lots of applications since the original work but I think it is still commonly misunderstood by users. We found many users that thought the hot spot was the highest single point value on the map, which often it was not. Few realized the hot spot was the cluster of points that were closest together with the highest aggregate value. I think with the right work flow or user interface it can be a great tool, but we are not quite there yet. The difference between the two only becomes apparent when users can have access to geodata visualization tools (i.e. thematic maps) and geodata analysis tools (i.e. density maps).

Popularity: 22% [?]