SpatiaLite is not the Shapefile of the Future

September 16, 2010 32 Comments

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.

GeoMonkey loves the shapefile because it just works.

Ah! But like most things, just because a bunch of bloggers think 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 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 lets 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 give a hoot other than federal agencies that have to provide open data, but are locked into to the ESRI stack.

Filed under GIS Tagged with , , , ,

Mercator Projection Hating Continues

August 13, 2009 20 Comments

Jeff Thurston asks a simple question:

Why take perfectly projected GIS data and stick it into Bing Maps or Google Maps? Isn’t it time that the 49th parallel was not a straight line?

I hate to break it to Jeff but 90% of the world has no idea that Bing or Google maps have a projection.  People expect their web maps to look a certain way (you know where Greenland is bigger than Brazil) and because of that we’ll continue “sticking” our data in Bing or Google Maps.  Anyway when projections matter, use something other than Mercator.  I talked a little bit about my problems trying to work with the poles before here and here.

Much like the flat earth society, these Mercator haters want to make lives harder for average users to navigate maps.  If projecting your data to Mercator is causing it to be incorrect, then you are obviously doing it wrong.

The GeoMonkey has always enjoyed the Mercator projection because he doesnt like going to the poles

The GeoMonkey has always enjoyed the Mercator projection because he doesn't like going to the poles

Filed under GIS Tagged with , , , ,

GSS – Style your web maps with CSS client side

May 22, 2009 2 Comments

As Steve pointed out, this is does deserve two exclamation points!!

Just like CSS for styling web pages, GSS is a specification for designing maps. Adapted for dynamic data sources, GSS can define changing geographic elements, display multiple datasets, and even respond to contextual tags like “condition:poor”.

Very tasty!  Just look at this simple GSS and how you can render maps on the client.

body: {
fillStyle: "#fff",
lineWidth: 0,
},

node: {
fillStyle: "#ddd",
strokeStyle: "#090",
lineWidth: 0,
radius: 1
},

way: {
strokeStyle: function() {
return "rgba(1,1,1,0.7)"
//return color_from_string(this.user)
},
strokeStyle: "#ccc",
lineWidth: 3
},

leisure: {
fillStyle: "#2a2",
lineWidth: 3,
strokeStyle: "#181"
}

Previous conversation about styling GIS data.

Filed under GIS Tagged with , , , , ,

Sharing Cartography

April 21, 2009 62 Comments

There are tons of ways to store spatial data, but sharing cartography is much harder. ESRI seems to be using their new Layer Package “format” to keep the ESRI layer file with the datasets. Outside of that I don’t really see much in the way for cartography support with data layers (other than the odd ESRI LYR file offered up on FTP sites). In a way, there is much to like about ESRI’s decision to use essentially a sidecar file for storing symbology and maybe there is a more open method of sharing this information.

Most of the time when you download data, you just get the raw file format (usually shapefiles). You then drag your new downloaded dataset to your viewer (possibly ArcView, maybe uDig) and then you proceed to try and figure out how to color the map up (of course there is no metadata so you can’t figure out what field you should symbolize on) in an attempt to match that PDF of a scanned map that someone gave you.  Wouldn’t it be better if there was included symbology that allowed you to view that data layer the way the author intended?

Well as I said, ESRI’s Layer Package format does this.  The Layer file is of course a problem because you need ArcObjects to read it.  But in an ESRI world, that isn’t too much of a problem.  Outside of an ESRI world, maybe the MapServer Mapfile might be the best way to get symbology information in (heck you can write out a Mapfile from ESRI, let alone all those open source clients).  Some have said KML is that format.  I disagree because it doesn’t lend itself to storing attribute information (maybe there are ways, but I still question if KML should be used this way).  At least KML does store simple symbology with the dataset.

Ron Lake offers up SLD/SE as an option, but acknowleges that it really has no traction.  I really haven’t seen SLD used much beyond some GeoServer documentation and I’ve not seen anyone try and use SLD for storing cartography in desktop clients (NOTE: According to comments uDig does support SLD, but not be default which is a good starting point).  Sean Gillies thinks CSS is the best option but again we run into the issues of desktop clients not supporting it and probably won’t (though Sean gets GeoMonkey cred for continuing to use the term “GeoWeb” every chance he gets).

What about Mapnik?  It does a superb job at rendering great maps and Andrew Turner says there is a project that can convert CSS into Mapnik.  Now that might be a workflow.  CSS is very easy to edit and and work with and  Mapnik is great at rendering cartography (and could easily be supported by desktop clients).  CSS gets stored as a sidecar file to the dataset and the rich cartography can be read with Mapnik to render the maps as the author wishes the maps to look.  Maybe Sean is on to something after all…

If we are going to go out on the GeoWeb wall of death, well need a sidecar.

If we are going to go out on the GeoWeb wall of death, we'll need a sidecar.

Filed under GIS Tagged with , , , , , , , , , , , , , , , ,

Licensing on the GeoWeb

April 12, 2009 40 Comments

The GeoWeb is easy, right?

The GeoWeb is easy, right?

OK, love or hate the term GeoWeb, it does reflect the reality of our workflows today.  We are taking our applications off of the desktop and running them on the web, we are combining data silos right inside the browser and we are giving tools to that used to be reserved for technicians on UNIX workstations to users via their mouse.  It is truly a new way of working, but I see it running directly in a wall.

Licensing

Here we are at the tip of the iceberg changing the world (maybe a self-serving statement), but we’ve got a chain around our necks limiting our potential.  Google and Microsoft’s (among others) APIs are sold the same way IBM sold software before there was the world wide web, large companies can cut great deals, smaller users are left paying full price because we don’t matter.  ESRI’s ArcGIS Desktop and Server licensing doesn’t reflect how users are using the applications in the real world (sure, allowing editing on ArcGIS Server Standard instead of Advanced is a step, but it is just one in a long list of problems with the licensing model).  Don’t even get me started on Oracle’s licensing.  Arbitrary levels of licensing that have no real world basis are killing innovation and requiring consumers of the services to look elsewhere or limit what they can do with technology.  I’m not advocating abandoning any of these companies here because there are great business cases to use their software, but their customers are not able to continue business as usual.

Wont someone please think of the users?

Won't someone please think of the users?

Just last Friday, I was talking to a client who was paying for ArcInfo because one hour a month he needed a function that it handled.  The rest of the time ArcView was good enough for him.  This isn’t just limited to ESRI, most software companies sell software this way and users are expect to pick up the cost just to get some functionality that some committee, in a dark room in their software design center, determined that only “power users” would need is crazy.  Sure there are ways to get around most of these limitations using other software, but all these companies are doing is pushing their customers away.

So what do we need here?  Google offers their products as SaaS and so does Microsoft.  Why does this make sense for “Office” applications and not Geospatial software?  Now these efforts of course don’t replace Microsoft Office and that isn’t their mission (well at least Microsoft’s).  But what do they do is allow users to extend their collaboration further than the office conference room.  Geospatial software is well set up to take advantage of services.  Pay for what you use and spend the savings on tools that benefit the end users and not tools that you’d never need.

So I’m not exactly expecting a revolution here in the next year, but unless companies start thinking about the realities of how users are using their software or APIs, we are going to have to look elsewhere or create our own tools.  Given what the licensing costs these days, there is money to get that done.  Personally I’d rather just use an off the shelf solution and pass those savings on to my clients and get back to building great applications for them

The GeoMonkey only wants what is right...

The GeoMonkey only wants what is right

Filed under ESRI, GIS Tagged with , , , , , , , ,

On to GeoWeb 2.0?

December 11, 2008 11 Comments

What?  I need to use Flex APIs (and thus GeoWeb 2.0) to do this?

GeoWeb 2.0 would need to be able to answer spatial questions and solve real-life problems in the spatial context—in addition to locating and visualizing data on maps. For example, it should be able to answer questions, like when the fire broke out, taking into account wind direction and speed, which area will be effected by the smoke and how many residents will be effected; or what critical infrastructure needs to be protected. It should also be able to pinpoint the nearest safe shelters for residents likely to be affected, the best evacuation routes; and the best way to setup road blocks so that the least number of U-turns will occur.

Why does someone need to propose GeoWeb 2.0 (other than I’m sure O’Reilly requires appending the 2.0 suffix to any article you write) when we can do everything Zhang outlines with GeoWeb Classic 1.0?  Good grief indeed!

GeoWeb 2.0 - with new Flex

 

Filed under GIS Tagged with , , ,

Happy GIS Day from the GeoMonkey!

November 19, 2008 5 Comments

 

Have a merry GIS Day!

Have a merry GIS Day!

Filed under GIS Tagged with ,

Where is Metered Pricing for Internal Mapping Applications?

November 13, 2008 39 Comments

So I’ve got a (theoretical) simple internal website for a client that basically puts pushpins for their locations on a map. Since this is on their intranet we’ll have to pay approximately $10,000 to Google or Microsoft to license their products internally. This small company doesn’t have the kind of money (especially in this economy) to put down on such an application. Essentially spending $5-$10K before any coding has taken place is not going to get anywhere and the project is dropped. 

Why is it that both Google and Microsoft are stuck in archaic licensing agreements? The logical way to price these services is a metered service. Much like Amazon AWS works, you’ll pay for what you use (with per-session costs decreasing as usage goes up). It would be monitored so I could see what kind of traffic I’m generating with the service and I could be billed monthly via credit card. We’ve been using Amazon S3 and EC2 with great results and it is very easy to justify the low initial costs and still be able to scale to larger applications if warranted.

How do you get Scrooge McDuck to part with money to pay API licensing costs to Google or Microsoft?

How do you convince Scrooge McDuck to part with money to pay API licensing costs to Google or Microsoft?

The other problem is that if I’ve got to spend that kind of money, I’m going to be developing larger internal applications than I would externally. You can’t do a simple internal mashup if you have to pay large enterprise licensing costs. I was told by one potential client who wanted a Virtual Earth application that “For that price we might as well buy another ArcGIS Server license”. For someone to say that it is cheaper to roll out ArcGIS Server for a simple mashup really puts it all into perspective and if you are going to develop with ArcGIS Server, you’ll probably have a larger application than a “simple” Virtual Earth map.

So I’m pleading with Microsoft and Google to revisit their map API licensing and move toward more of an Amazon AWS type service that will help get their mapping tools into more places than today. Everyone wants a Google or Microsoft map on their intranet website, but the current licensing is killing projects before they can start.

The GeoMonkey is a huge supporter of Amazon Web Services

The GeoMonkey is a huge supporter of Amazon Web Services

Filed under GIS Tagged with , , , , , , , , , , , , ,

GeoCommons Maker! – the next day

October 2, 2008 14 Comments

Well kudos for FortiusOne for getting the word out on Maker! especially since the launch was delayed from the original PR blitz.  As with most GeoBloggers, I’ve had access to Maker! since last week and have really been impress with its output.  Sean has been teasing us for months it seems with the cartographic output of Maker! in his blog posts, so I was glad to finally get my  hands on Maker!. (side note, do you put a period after a product name that ends in a punctuation mark?)

Maker! is the map production portion of GeoCommons and Finder! is the search engine for geospatial data.  Together they allow users to create web maps that can be shared with the world.  So to get information in Maker!, you first upload your data to Finder! and then add it to your map.  The byproduct of this workflow is more data gets added to Finder! and in turn more data is available to the community at large.  Freely sharing data is one the core components of GeoCommons (compared to WeoGeo which is more of a marketplace).

Stefan Geens does a good job of showing how the map is created and how you set what we usually refer to the symbology of layers.  What I like about this approach is you can bring to light the data in ways that before Maker!, required custom programming to achieve good looking results (if even possible).  FortiusOne, according to Sean, worked with cartographic professionals to create the rich (I’m sorry) map production tools.  These tools are so good in fact that I’ve heard a couple GIS professionals lament that they’ll be out of a job soon (of course we all know that Maker! will only increase our workloads to produce data for public consumption).  What we have here are two really simple tools that allow anyone to upload geospatial content, combine that information with other datasets and then create a wonderful looking map that visually tells a story.

You can argue all day and night about what the GeoWeb is or isn’t, but I think we have an excellent example of what the GeoWeb should be right here.  Finder! has discoverable web services of data (with metadata to boot) and Maker! allows you to leverage those services together to create derivative value content to share with the world.  Moving forward, the data of GeoCommons should support more OGC services (beyond KML) for those who need that support and the maps created with Maker! should be more easily shared beyond just an web map.  But the groundwork is there for sharing data with the world.

Despite the lack of monkey maps, the GeoMonkey approves of Maker!

Despite the lack of monkey maps, the GeoMonkey approves of Maker!

Filed under GIS Tagged with , , , , ,

County GIS Mapping Websites

August 15, 2008 61 Comments

Adena blogged about a county mapping site from Morris County, New Jersey (OK, I’ll admit right now I was born in Morristown, NJ; the county seat of Morris County).  I had not seen the website before, but this comment from Adena got me curious:

It’s a quite complex app, the kind I’ve not seen implemented in Flash. It must be pretty slick; it was named site of the day by Adobe earlier this year. Do be warned: you may need to read the help to use the site!

Go to the website yourself and take a look.  I don’t want to take away anything from the people who implemented it because it is very impressive, but is this the kind of GIS web map site that should be the public face of a county?  My current county has a horrible MapGuide mapping site (you know the classic ActiveX plugin MapGuide thing?) that is difficult for even me to use.  Most county websites (no matter if they use ESRI, Autodesk, open source, other*) are very difficult to use, take forever to load, run very slow, require plugins, require reading a manual and frustrate the heck out of me.

Shouldn’t a country web mapping site be simple and easy to use?  I would assume the average user of a county website doesn’t have an engineering degree so why not aim these sites at the user level?  And we need to be held acountable for accepting them (I’ve been using the Maricopa mapping site for as long as I can remember and I’m pretty sure I’ve never complained to the county, just on this blog).  So right now I’m going to contact my county and let them know their website isn’t useful and you should do the same.

Wont someone please think of the GeoMonkey?

Won't someone please think of the GeoMonkey?

* Manifold

Filed under GIS Tagged with , , , ,