[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.
Hi,
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,
Arnulf.
More information about the Mapbender_dev
mailing list