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

Fri Feb 8 10:17:46 EST 2008

Hey Vitali,

thanks for your great introduction. It's not lengthy at all, but very 
interesting.

You are right in your criticism about Mapbender, there are several 
aspects that are simply illogical, inconsequent or plain ugly. Please 
bear in mind that the core is rather old and has not seen a lot of 
redesign or refactoring yet. Thanks for sharing your thoughts, an 
outside perspective is always refreshing and helpful.

How about joining the weekly IRC meeting on Monday at 1700? See 
http://www.mapbender.org/IRC_Meeting for details. It would be nice to 
chat a little more.

Thanks so far, talk to you soon

Christoph

Vitali Diatchkov schrieb:
> 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.
>
> _______________________________________________
> Mapbender_dev mailing list
> Mapbender_dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapbender_dev
>   

-- 
***************************************
FOSSGIS Konferenz
Freie und Open Source Software für GIS
vom 01.-03. April 2008 in Freiburg
www.fossgis.de
***************************************
---------------------------------------
WhereGroup GmbH & Co. KG
Siemensstraße 8
53121 Bonn
Germany

Christoph Baudson
Anwendungsentwickler

Fon: +49 (0)228 / 90 90 38 - 25
Fax: +49 (0)228 / 90 90 38 - 11

info at wheregroup.com
www.wheregroup.com
Amtsgericht Bonn, HRA 6788
-------------------------------
Komplementärin:
WhereGroup Verwaltungs GmbH
vertreten durch:
Arnulf Christl, Olaf Knopp, Peter Stamm
---------------------------------------