| 95% 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.
Hopefully these lists will clarify some of what goes into a map, to help you plan it the way you want it.
The basic choice of framework
Which basic framework do you want to use? Google Maps and OpenLayers (or OL and GM for short) are the two most prevalent.
- Google Maps has that world famous imagery basemap built right in. OpenLayers does not include imagery and a basemap and we have to provide our own.
- However, Google Maps has restrictions. All maps must be freely available to the public without charge or login. They can modify or disconnect the service or add banner ads without warning. Also, saving/printing of the map is both impossible and illegal.
- Google Maps' basemap often has a problem with aligning with other data, and Google Maps overlays do not properly support reprojection of other data. Google Maps is best used only with KML overlays using the Google Maps API. But, it's very simple to use if you don't need anything complex.
- OpenLayers' API is somewhat richer than Google Maps' in terms of how the map and the rest of the page can interact. Many tasks are easier in OpenLayers than in Google Maps. And when we say "easier" we mean faster to deploy, easier to test, and less expensive for you all around.
- The OpenLayers API supports many layer types: WMS, MapServer for advanced filtering, KML and RSS, WFS/GML. It also supports several commercial basemaps: Virtual Earth, Google Maps, and Yahoo Maps. This means that you can in fact use the Google Maps basemap inside a OpenLayers framework, subject to Google Maps' terms of use.
- OpenLayers maps can be printed or saved to a PDF. Google Maps' programming API makes that impossible, and their terms of use make it illegal.
Getting the data together
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.
- 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.
Users uploading and editing stuff
A lot of apps allow folks to be able to post points, edit things, comment on them. Easy stuff, 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 (those 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 a not-so-nice person to damage your database. Security inside your program is as important as making sure that they're logged in!
Administration
- 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?
|
