[Mapbender-dev] Hello! I am future contributor for Mapbender

[Vitali Diatchkov]

Hello! My name is Vitali Diatchkov, I am GIS software engineer at Arbonaut
Oy LTD (Finland).

Some times ago we looked to open source web mapping projects to choose one
for our GIS RIA (rich internet applications) development to be based on.

After analysis of the project requirements had been starting at that time we
preferred a Mapbender to OpenLayers. Because of a lot of good stuff had
already been implemented for the server side and power of database-founded
configuration and user management. 

Our challenge was to incorporate Mapbender as a mapping component to the
main Java enterprise application running at the appserver. The challenge
here is because of totally different environments (J2EE an PHP). It means it
is impossible just simply wrap Mapbender as a component in particular
presentation layer component technology (like JSF or whatever) and utilize
it. In our case it is a ZK Java and server-side-based Ajax framework
(www.zkoss.org). 

Briefly to say about the chosen architectural solution:  zkMapbender
component for the server side is developed in ZK framework technology that
wraps a particular Mapbender GUI instance living in a IFRAME inside of the
main frame of J2EE web application. All the business logic is running in
J2EE web application at the appserver. zkMapbender component generates an
IFRAME where Mapbender instance for the particular GUI is loaded from PHP
environment through proxy servlets of the appserver where the man J2EE web
application is running. It solves security issues  of JavaScript interaction
through multiple documents loaded in different frames from different
servers. Special GUI is developed for Mapbender where the mapframe takes all
the place and tools are located on the top of the rendered map. 
This is a background information to figure out what we are doing.

To make Mapbender working in a such heterogeneous environment, some PHP
modules are replaced by Java modules developed for zkMapbender component and
JavaScript for the client is also re-implemented. Most of the modules like
navigation tools are working fine without any hackings. Re-implementation
concerns only those modules (from PHP to Java environment) where
long-running asynchronous communication is needed: selection of features,
creating of new features by digitizing tools and so on.  An example: spatial
request goes directly to zkMapbender component living at the J2EE
application that knows how to request features (whether from WFS server or
directly from PostGIS database e.g.) and the component configured for the
particular application business logic and data model knows how to load
features and generate the same JavaScript output like mod_wfs_result.php
generates in PHP environment.  Small conclusion: we use Mapbender as not
like a mapping application framework, but more as a mapping component
utilizing existing Mapbender's functionality implemented in PHP and
extending by new custom functionality implemented in Java needed for the
particular enterprise web application.

I could write much more technical issues about how do we solve unsolvable
problems during merging of so different environments.. But now I would like
to  share some thoughts about Mapbender itself. Like I said I consider
Mapbender as a very powerful mapping application framework. It is more
intended for the application development not serving like a component.

I have been developing for GeoTools, UDIG and GeoServer (great open source
Java-based GIS frameworks) during several years. One big drawback of
Mapbender from my point of view that in some places it tries to invent the
wheel: implementing its own geometry model, feature model in javascript for
the client side when there are consistent and widely accepted OpenGIS
Consortium API specifications, and their different implementations  (GeoAPI,
JTS - JavaTopologySuite) that follow standard API naming conventions and
design patterns. 
An example: in GIS a Feature model is on the top of Geometry model. Seems
Mapbender is more "geometry"-term-centric  when Geometry object has a child
Wfs_element that represents a "Feature" entity. It is very misleading for
the "GIS standards"-based development.

Another example where I see the potential future refactoring: selection and
digitizing tools are tightly coupled with modules at the server side
handling WFS  requests. In current conditions to change PHP server-side
logic by the Java-implemented logic for these tools we had to refactor
almost all the javascript code for the client side. What if the client-side
javascript would be server-side agnostic to easily replace server-side
logic? In our case GeoServer (that having good modular architecture) is
injected as a module to out J2EE application - it is not a standalone
application anymore - and all operations serving by Mapbender like
query/create/modify/delete features are processed without WFS XML
requests/responses being sent by mod_wfs_result.php to GeoServer but they
are executed directly by our J2EE application against PostGIS or
OracleSpatil database. And we have very improved performance of vector data
processing operations (by other words feature management operations) because
of eliminating redundant components (standalone WFS server) for the
particular project with very limited and constrained spatial data model.
If selection and digitizing tools would work through listeners design
pattern and architecture would have several abstraction layers we could just
easily replace server-side logic and communication protocol but client
javascript of tools would still work without any changes. In case of
digitizing tools I mean replace geom2wfst.php by the custom logic in J2EE
web application and WFS requests protocol by geoJSON for example (for
transferring features between client and server-side component responsible
for create/modify/delete features).

Sorry for the long set of words :) We are ready to improve thing together in
future. I have just described several use cases where things would look much
better for the utilizing Mapbender as a mapping component framework, from my
point of view and also as a great mapping application.


Any comments and criticism are appreciated.

Regards, Vitali Diatchkov.