Recently I began evaluating Oracle MapViewer to determine if it is the right tool for me. I’m looking for a mapping API that will allow me to manage vector graphics, points and polylines, independently from the base map. Today, I write too much repetitive code for map providers like Google Maps and OSM. Oracle MapViewer it is a good tool for people working in a Java EE environment. It also has a place as part of Oracle’s Business Intelligence Suite, and is a very handy ad-hoc spatial data viewer, but does it belong in my website development toolbox?
My personal preference is open source and lightweight, as this graphic illustrates, with a client-side JavaScript MVC framework making AJAX calls to JAX-RS web services. The RESTful web services should run in a standard Java web container and not depend on Java EE server containers.
In order to do vector graphics and event handling for polylines and points independently from the base map, my map API abstraction layer must be replaced. Ideally, the replacement framework should be purely JavaScript and should not require any server-side changes, something like Leaflet.
MapViewer Components
MapViewer is much more than just a JavaScript framework for maps. It has several server-side components that support its client-side AJAX-based JavaScript API:
- A core rendering engine Java library, SDOVIS, that performs cartographic rendering. A servlet exposes the rendering functions to Web applications.
- Application programming interfaces for programming MapViewer features. These APIs include XML, Java, PL/SQL, and an AJAX-based JavaScript API.
- A graphical Map Builder tool that enables you to create map symbols, define spatial data rendering rules, and create and edit MapViewer objects.
- Oracle Maps, which includes map cache and FOI (feature of interest) servers that facilitate the development of interactive geospatial Web applications.
The MapViewer architecture is not targeted towards my ideal environment of simple Java web containers. The preferred environment is Oracle WebLogic or Glassfish.
That being said, MapViewer does support Tomcat, but to what extent I’ve yet to discover. The following table is from the Map Viewer J2EE Servers Support page:
J2EE Server Name and Version
|
Oracle WebLogic Server |
10g and Later |
GlassFish |
3.1.2 or later |
Oracle Application Server |
10g (10.1.3.x) |
WebLogic |
9 |
Oracle OC4J Standalone |
10g (10.1.3.x) |
Apache Tomcat |
6.x and Later |
WebSphere |
6.x and 7.x |
JBoss |
4.x and Later |
This architecture is illustrated in this graphic from the Oracle Fusion Middleware MapViewer Primer.
In my current work environment, pools of servers support different domains of our site. There is nothing to say that one pool of servers cannot include Java EE servers to handle the mapping load. It would still serve to isolate the mapping services from other server pools as well reduce the workload on the other servers. The business justification for the new pool of mapping servers depends on how many MapViewer features add value to our site, things like dynamic heatmaps, for example.
I’ll start my deep dive with the tutorials that come with the project, and then will explore some of the extensive features list in MapViewer data sheet.