Planning Your Map
The bulk of the work in most map applications isn't in the map at all, but in the peripherals such as user logins,
a "Forgot Your Password" link, and administrative panels for editing and "approving" submissions or user accounts.
These lists will clarify some of what goes into a map, to help you plan it the way you want it.
Basic framework and basemaps
- We use OpenLayers as our front-end of choice. OpenLayers provides a slick, familiar interface; and a rich API for
making the map interactive with the rest of your page. OpenLayers supports many types of layers: WMS, MapServer,
TileCache, GeoRSS and XML, Bing Virtual Earth, Google Maps, and Yahoo Maps.
- For the backend, you can use MapServer or GeoServer. MapServer is slightly faster and uses less RAM, while
GeoServer has a nicer management interface, and can be faster for you to learn if you'll be administering the data
yourself. MapServer is configured via text files and can be programmed in PHP, which makes for interesting
opportunities for making your mapping backend as dynamic as the frontend.
- For the basemaps, you have several choices. OpenLayers supports several of the big-name basemaps out there such
as Google and Bing. However, these services often have restrictions on their use, and for some projects it may be
more appropriate to purchase imagery, or to use some of the freely-available sources out there such as NAIP.
- * Google requires that your map be publicly available and that you don't require people to login. All of
the providers forbid the printing or automated download of their map content, and do not provide a
computer-friendly means of downloading their map content anyway.
- Google and other providers often have alignment issues when it comes to overlaying other data. In some regions
and latitudes, the error can be several dozen meters. We have workarounds, but sometimes the drift is still noticeable.
Although we have some connections for purchasing imagery, we specialize in hosting and support rather than data
acquisition. But if you have the data and need it massaged, great!
- Do you have the data in a usable format? The most widely used are GeoTIFF, MrSID, and Shapefile. Other formats
such as spreadsheets, CSV files, and sometimes even tables on a web page, can often be adapted into a map-friendly
- We can deal with some of the more obscure formats, but conversion is a case-by-case sort of thing. For example,
Coastwatch "CW HDF" requires specialized Java programs to render it to TIFF before it can be used.
- MrSID imagery must be converted before use, and GeoTIFF is the only format which is fast enough to be usable.
GeoTIFFs typically take up 5X to 10X the disk space of a corresponding MrSID, so it's usually best to transfer the
MrSID to the server and then translate it to TIFF there.
- Shapefiles are great, but what about PostGIS? PostGIS is basically the ability to use a database table as a
shapefile, and to perform operations on the data in that table such as buffering and reprojection, distance
calculations, and finding the nearest other shape. If you don't need any of those advanced features, shapefiles are
great. But if you want the data to be searched, manipulated, or even updated via the web, PostGIS is the way to go.
- Remote image services (WMS) are a great resource.
User Functions and Controls
A lot of apps allow users to be able to post points, edit them, comment on them. This is easy to implement, if you plan it.
- Who should be able to login? A single password is the most expedient mechanism if it's just you, or if you and
your staff sharing a password isn't a problem.
- Should there instead be multiple users and passwords? Do they all have the same administrative level of access,
or is there an idea that some people have more access than others?
- Is there a concept that the user who created a map features "owns" it? Is that feature visible or
editable by others and under what conditions? This ranges from "all points are visible to everybody" to
advanced sharing and permissions.
- Can people sign themselves up? If so, a CAPTCHA (scrambled letter verification codes) is great for preventing
robots from signing up. Do you want some sort of approval or activation process after signup, to verify the person's
email address or to manually review them?
- How does the user enter their data? By clicking and drawing on the map? By typing in coordinates? By uploading a
GPX file? By uploading shapefiles?
- When should a user NOT be allowed to submit data? Are the title and description required fields? Do they need to
submit a credit card payment? Is there a limit on the number of submissions?
- How secure is the code that allows their submission? A badly written SQL statement can allow damage to your database.
Security inside your program is as important as making sure that they're logged in!
- How do user accounts come to exist on your system? Do they sign themselves up? Do you? Will they forget their
password? Should they be able to cancel?
- Do you need an administration panel to approve new user accounts and/or to manage existing users?
- How about for administering the data? Do new submissions need to be approved? Do already-approved submissions
need to be accessible for editing or deletion?
- Do you want the admin pages to sort or filter the lists?
Knowing what you want is the surest way to get it. When you work with your developer to make a clear plan, your project
can be implemented as quickly as possible, in exactly the way you need.