Author: James

So we’ve got yet another blog touting the future of the SpatiaLite format as being the next Shapefile. Now, don’t you dare look over at that search feature on the right side of my blog and type in SpatiaLite because you’ll probably see the same thing (though honestly, I can’t recall if I was of sound mind when writing it)? The simple fact is SpatiaLite is a favorite format for those of us with nothing better to do than tell the rest of the world what they should be looking at.

Ah! But like most things, just because a bunch of bloggers thinks it is a good idea doesn’t mean it will actually matter. In this case, SpatiaLite is dying a slow death because no one is actually implementing it. Now yes OGR, FDO, and other libraries support it, but you don’t see that making its way into mainline software (QGIS aside, but even its support is poor) and in turn, you rarely see it in the real world. Offhand I can only think of the “beta” format that GeoCommons has on their service (and they’ve had beta attached to it for almost a year).

Now yes, I think we all need a better format than the venerable shapefile (and it’s three amigos) which as a transmission format fails miserably. But there doesn’t seem to be any indication that this is a problem people actually want to be solved. I’ve seen much more effort put into KML, GeoJSON, and LAS by the community than SpatiaLite or even SQLite. This isn’t because the SpatiaLite project hasn’t given tools to us to implement, it has been the community could care less about it. SHP works for them and there isn’t any reason to change.

So what is going to change things? Well, it will be web services, not GIS formats that matter for users moving forward. So I say let’s stop focusing on SpatiaLite as a consumer format and actually work harder at making better web services for these users (like stop it already with the WxS please). SpatiaLite still has its place in the world, but does anyone really want to bother downloading GIS files anymore? Of course not…

Shapefile can’t #FAIL!

Oh and the FGDB API – just assume it is dead as well. ESRI can’t get it out the door and in reality, no one gives a hoot other than federal agencies that have to provide open data, but are locked into the ESRI stack.

So a week doesn’t go by where I don’t see some news about Ovi Maps.

The new, improved Ovi Maps will offer, live?traffic?flow information, a new drive assist mode, public transportation maps, a redesigned places page, and social check-ins. The public?transportation?maps will be available via a map layer for over 80 cities around the world and check-ins will allow you to broadcast your location via SMS or to your social network of choice.

OK, so does anyone actually use Ovi Maps on purpose? I mean MapQuest learned how to fit in with the new world order, but Nokia seems to still think we are all ready to jump on their platform. Part of why Where 2.0 doesn’t interest me anymore is they keep getting up there pushing this platform like it is viable or something. But hey I doesn’t matter right? Name one product of value that ever launched at Where 2.0? [editor’s note: I must remind Mr. Fee that his passion launched at Where 2.0]

I wonder where Ovi Maps is? At least Nokia is consuming their own dogfood.

I found this blog post on basemaps over at the 41Latitude blog (if you aren’t following this blog you need to start right now) to resonate with me.

perhaps, in trying to make a basemap that’s optimized for everything, we’re actually creating one that’s optimized for nothing.

We all see it quite a bit these days. Some data overlaid on a default Google Map and you can’t read a darn thing. Working for the GNOCDC, we picked the Terrain map as our basemap (even though there is no “terrain” in NOLA) because it was the least cluttered basemap.

Over in the ESRI world, I’ve had a couple people ask me to put their data on the Esri Topographic web map servicebecause it looks so good. Now I do agree, it is a beautiful basemap, but it isn’t one that lends itself to being a basemap. Esri should be offering a muted basemap and allow for the most important part of the data, the information being overlaid, to stand out.

Wait, what happened to 3 day weekends. I guess you get one and then you expect them all the time. Oh well…

Some interesting reading for a Monday morning:

• ArcGISEditor for OSM – Randal looks at the ArcGIS Editor for OSM and concludes it is complicated but powerful. I all Esri tools (they are “scientific” mind you) nothing is ever simple, but if you can get your hands around it, powerful results happen.
• FOSS4G 2010 Final Answer – Apparently there was a Geospatial conference going on somewhere. They all kind of start blending into each other, don’t they?
• Making a Data Portal With WordPress – Content management is content management, right? (bless his heart for trying to do this with WordPress) Just goes to show that if you can hack your way around code, there isn’t anything you can’t accomplish (assuming your billable time isn’t an issue).
• Gearing up for GIS in the Rockies – Time for the fall conference season to kick into high gear. Front Range GIS is a unique community that does some really great things with both proprietary and open-source tools (usually in combination). Bummed I can’t go.
• Why not GeoJSON? – Looks like France was good to Sean. He’s got a great post up on ESRI’s use of JSON in their RESTful API.

Oh and way to represent SEC!

Remember that FGDB API? The one we were talking about over two years ago?

FGDB API, get out of my dreams, and into my apps!

As was announced at the ESRI UC, the GeoServices REST Specification, Version 1.0 has hit the streets.

Services that follow the specification will “speak the same language” as the REST-ful Esri Web services. That means clients can consume them with the popular ArcGIS APIs for JavaScript, Flex, Silverlight, iOS, and Android; as well as other Esri client APIs. However, you don?t have to own or use any Esri software in order to implement the specification or to build a client that works with the services.

As you examine the specification, you’ll probably notice that it looks like the?ArcGIS REST API. This is deliberate. The pattern we have used at Esri for exposing REST-ful GIS services has been embraced by thousands of developers who use the ArcGIS Web APIs. It is a simple and intuitive way of structuring and talking to GIS Web services. We wanted you to feel free to implement services that follow the same pattern.

Whether or not this is truly an open spec (and not opening the debate as to how “RESTful” this spec really is), the rush begins for everyone to implement this spec on their own apps so they can be used with ESRI clients.

Jack opens his secret to getting RESTful with ArcGIS

So Pasadena’s buildings are now in the middle of the road. My suggestion to Pasadena is that they move the city to to get it aligned again with Google Maps.

Pasadena Problems

It seems like a day doesn’t go by where some company puts out some press release about some edge case implementation of their mapping api. I couldn’t care less guys.

Unless the implementation is built into how we as consumers use information (type it into my browser search bar, type it into my smartphone) there isn’t any way I’ll actually use it. Plus as a developer, you should be offering me the feed up so I can implement it in my own stack, not locking it up behind some weird specialized mashup UI.

In the ArcGIS 10 depreciation document this little tidbit catches my eye.

ArcGIS Server 10.1 will no longer support 32-bit operating systems. ArcGIS 10.1 will exclusively support 64-bit operating systems. Support for 64-bit native execution across all the tiers of ArcGIS Server has been a long awaited feature by many of our customers. 64-bit hardware is the norm in today?s market and most modern ArcGIS Server deployments do in fact run on 64- bit hardware. ArcGIS Server 10.1 will run as a native 64-bit application exclusively requiring 64- bit capable hardware.

Now we are talking about Server here, not Desktop, but a total 64-bit server suite is very nice. One more thing that for some reason seems to get people a bit riled up:

ArcGIS Server 10.1 will no longer support publishing non-optimized map documents (MXD files). ArcGIS 10.1 will only support publishing optimized maps (MSDs) as that is the best practice for map publishing. At ArcGIS Server 10.1, optimized map services (MSDs) will be enhanced to support many of the capabilities that are currently only available through MXD-based map services.

This is a total performance change now that MSDs will support just about everything you need from a cartographic standpoint. Oh and one last little tip of the hat to the workhorse:

There are no plans to release a new version of ArcInfo Workstation at ArcGIS 10.1.

Frozen in time will ArcInfo Workstation be (hmm did I just channel Yoda there?).

I reviewed ArcGIS for iOS a couple weeks back and liked what I saw. One of my biggest disappointments was the lack of OGC support. ESRI says it is coming, but in the meantime I took it upon myself to try out other iOS mapping clients. One that has caught my eye is iExtMap. You may recall Alper Dincer?from the 2009 ESRI Dev Summit Challenge where his ExtMap took first place. While not built upon ExtMap, Alper has released iExtMap for iOS.

So what does iExtMap bring to the table?

• Google Maps Base Maps
• Blank Base Map for your own base map
• Displaying ArcGIS Server Dynamic and Tiled Services
• Displaying WMS as Tiles
• Displaying KML/GeoRSS files
• Displaying static tiles (for Arc2Earth users)
• Bookmarking
• Geolocation
• Identify (in next release)
• Query (in next release)
• Measurement (in next release)
• Open Street Maps (in next release)
• WMS improments (in next release)

So let us look at iExtMap in detail.

The iExtMap Splash Screen

The first screen you see when you start up iExtMap is the Maps window. From here you can navigate whatever maps you have added to iExtMap. Google is the default background map and in the Base Maps screen you can see how you can choose which “base map” you wish to have in your background.

The Map Tab on iExtMap

Choose your Base Map

After choosing your background base map, you go to the Layers tab to add layers. The first thing I tried to add was a KML out of WeoGeo Market. This was easy to add and actually looked pretty good on the iExtMap screen on my iPhone. Just grab the URL to the KML and like that it is added. Adding ArcGIS Server services and WMS is also as easy as copying a URL and pasting. The only issue I ran into was that WMS needs to be in EPSG:900913 making your choice of WMS smaller than it should be. This is a know issue and an update is planned in the future to address it.

Adding a KML to iExtMap is very simple.

After adding the layer, put a check next to each one you want to view on your iExtMap Map.

And here is that KML – viewed on the iExtMap Map.

The bookmarks are very strait-forward. You either bookmark a view on the Map or manually input the coordinates.

Manually creating a bookmark in iExtMap

The Bookmarks tab in iExtMap

One actually fatal issue of iExtMap is that you can get caught in an info box and have no way to break back out. Make sure when you are on the Map tab, not to click on the links at the bottom of the view (I’m assuming these are the credit links). If you do you get stuck on the “about Google Maps” page with no way to get back to the map unless you exit the app. Hopefully this flaw will be fixed very quickly.

DO NOT CLICK!

Don’t get me wrong, the about page is very nice. You are just stuck on it if you get here – yikes!

Overall though, I think there is a ton to like about iExtMap. Out of the box you have OGC support (KML and WMS) which I really think is critically important. Support for ArcGIS.com (ArcGIS Online) layers is there as well so you have an iOS app that can work across OGC and proprietary services. Alper should be commended on his efforts and I can see myself using this quite a bit to work with OGC services.