[Mapbender-users] WMS administration of MapBender

Arnulf Christl arnulf.christl at ccgis.de
Thu Mar 23 15:24:37 EST 2006

Silke Reimer wrote:
> Hallo!
> I hope that I write to the right list since my comments and
> questions are rather technical. Please point me the right list if I
> am wrong here.

the better list for this kind of request is probably the dev-list which 
has recently moved to the OSGeo infrastructure (see CC). To subscribe 
there send an email to:
dev-subscribe at mapbender.osgeo.org

An automated response will ask you to confirm the request. Just hit 
reply (and don't bother about the ugly email address or whatever else 
the tin box says). Another response will confirm your confirmation and 
you are ready to go.

> A client has contracted us to develop a new tool for the
> administration of Web Map Services by the user. You can mainly think
> of it as a tool that combines the current 'Add WMS', 'WMS
> preferences' and 'Add WMS from filterd list'. Additionally there
> should be a search function to search by keyitem and/or a bounding
> box.

This is excellent as we are just about to start on exactly the same 
thing. We want to discuss this with a few other interested parties at 
the FOSSGIS Mapbender dev meeting. As you are probably going to attend 
to the FreeVZ-Aut meeting we might want to discuss this after the 
respective meetings in the evening.

> Of course I would like to share the result with the mapbender
> community and you can expect to get some scripts in near future.
> Before I can prepare them I have a few question about 'the right way
> to do' so that it doesn't break the implementation philosophie of
> MapBender.

We have planned to include this functionality as another way to enter 
the system altogether. Then it would also be available as an alternative 
to the standard login.php. It would be called broker.php or something 
like that and would not return the unfiltered list of services but - 
well the filtered list obviuously. Maybe we can join the two requests in 
a more generic approach.

> The combination of the three tools to a single tool is rather
> straight forward. It doesn't require any new infrastructure within
> MapBender. But for the search function I will need some new entries
> in the database or at another place:
> 1) The client wants  to add local keyword list about the external
>    WMS which can be searched. Thus each WMS will get something like
>    a 'local keywords'. I hesitate to add them to the table 'wms'
>    since this table is meant to hold the data from the external
>    capabilities document.
>    I see two alternatives:
>    * Either enhance the 'wms'-table by an attribute named 
>      'localkeywords' 
>    * or create a new table named 'wms_user' which is linked to 'wms'
>      and has at least the attributes 'fkey_wms_id', 'wms_user_id'
>      and 'keywords'.  
>    Are there any preferences? Or other solutions?

It has been suggested earlier to extend this approach to include the 
dublin core metadata but we refrained because it will explode the data 
model with all kinds of additional fields that nobody uses anyway. We do 
have some ISO 19115 elements in the mb_user table already as it will be 
useful to keep the reference to the loggedin user as publisher (who has 
some additional contact info, etc.). But this will be the extended 
version I guess...

> 2) A second search function should contain a list of lets say city
>    names which have a bounding box assigned. The current
>    implementation requires a prepared list of all necessary values
>    which have to be stored within the database. The dialog then
>    reads the data from the database and shows a selection box the
>    the city names.

The generic solution would be to query a WFS beforehand that returns the 
bboxes of the resultset as GML. This can already be handled by Mapbender 
to highlight, zoom, etc.

>    Since this procedure is not completely compliant with OGC specs I
>    would like to know whether you are interested to integrate this
>    functionality into MapBender. Otherwise I would prepare a version
>    without it for integration into MapBender (in the hope you are
>    willing to adopt my tool) and a patched version for the client
>    installation.

Lets try to figure out how much effort we can combine to implement the 
most generic approach. The most obvious problem that I can see with 
using a WFS is that there still are not many out there. Pity that the 
BKG only provides the street address level WFS for internal users - that 
would be a very good WFS resource to include. I believe that in the US 
you already get this kind of data.

> My last questions concerns the language settings. The client wants
> to have a German GUI but I saw that some tools have english GUI
> elements. Should I provide my implementation in english or german?

All language relevant captions that have a chance of ending up with the 
end user should be configurable through the GUI logic (as HTML 
attribute) or posibly by using the element_vars. All texts that pop into 
the administrators eye alone should be in English. We expect anybody who 
manages to get a Mapbender installation running to understand English 
error messages and hints :-)

> And furthermore: Are there any plans to integration i18n in
> mapbender?

Yes. Although the approach is different in that it will probably be up 
to the admin user (hoster, provider) to translate each GUI to whatever 
language is required. That way it is also possible to translate to 
Bavarian, Friesian or geek-lang. The idea is that there is no software 
that can really cope with the flexibility of rl language, hence the 
language domains of Wikipedia.

> Many greetings,
>     Silke

If we don't manage to discuss this at the FOSSGIS I'll suggest to 
continue in the Wiki as it will need further thinking to get this done 
in a useful way. If you want an account, drop me a note.

Best regards,

More information about the Mapbender_dev mailing list