SearchInterface

From MapbenderWiki

Jump to: navigation, search

Contents

Summary

Mapbender itself can be seen as a registry for OGC webservices and other standardized resources with an implicit geocoding. At this time following resources are adminstrated in the mapbender database:

  1. OGC WMS
  2. OGC WMS layer
  3. OGC WFS
  4. OGC WFS featuretypes
  5. OGC WFS client configurations
  6. OGC WMC documents
  7. ...

Seen from the development of mapbender, the view on these resources is driven by building a simple interface for using this resources for the mapbender webgisclient. Most of this use cases have practical backgrounds. Mapbender itself can be seen as something like a swissknife for OGC webservices. In case of accessing WMS and WFS the mapbender database is used as a cache for the capabilities documents and other originary XML based resources like WFS data schemas. The resources have relations to the individuals (users) which put the describing documents in the database (register them). In combination with the integrated user and group management, mapbender has the best potential to be used as a registry in sense of http://de.wikipedia.org/wiki/ISO_19135. This is not a generic (like the ISO itself) but a very practical approach for distributing and administration of OWS. As the mapbender database schema includes most necessary elements of the above listed resources, it suffers of a simple webbased interface to find the registered resources. This page will show a possible solution for this problem. In many geoportals which are based on mapbender the searching for geographic information units is based on CSW or properitary interfaces. The CSW based approach has the problem, that many relevant information which is needed to implement a SDI's cannot be exchanged with this interface. The schemas which are used (ISO19139) are based on abstract descriptions of geographic data (ISO19115) and a very generic definition of geographic webservices (ISO19119). Things like availability, reliability and the actual status are not defined. There are many unsolved problems in the environment of the OGC Catalogue Services which prevent the suitability of the CSW for building operative SDI's. The reasons which are listed before lead on to use another approach. This approach doesn't inhibit to implement the well known catalogue interfaces but makes these needless for an closed local level SDI.

Demos for Geoportal.rlp

  1. Integrated in typo3 http://www.gdi-rp-dienste3.rlp.de
  2. Start by cloud tags: http://www.gdi-rp-dienste3.rlp.de/mapbender/php/tagCloud.php?type=topicCategories&scale=linear&maxObjects=25&maxFontSize=30&languageCode=en - another usefull service for a service registry ;-)

Flowcharts

How the search modul works

Queryable properties

  1. type
    • parameter name: searchResources
    • default value:
      • wms
    • parameter examples:
      • searchResources=wms
      • searchResources=wfs
      • searchResources=wms,wfs - only possible if target is filesystem!
    • Description:
  2. any text
    • parameter name: searchText
    • default value:
      • e
    • parameter examples:
      • searchText=digital
      • searchText=bplan+ah4
    • Description: The searchText is used for a full text search in forllowing fields: title, abstract, keywords. A combined search like searchText=a+123 searchs with searchtext like '%a%' AND searchtext like '%123%'
  3. search identificator
    • parameter name: searchId
    • default value:
      • dummysearch
    • parameter examples:
      • searchId=1
      • searchId=userX
    • Description: The searchId will internally be hashed to prevent external access to filesystem
  4. max results
    • parameter name: maxResults
    • default value:
      • 10
    • parameter examples:
      • maxResults=5
      • maxResults=99
    • Description: The highest possible value will be 99
  5. search Pages
    • parameter name: searchPages
    • default value:
      • 1
    • parameter examples:
      • searchPages=1
      • searchPages=1,1 - only possible if target is filesystem
    • Description: The highest possible value will be 99
  6. result target
    • parameter name: resultTarget
    • default value:
      • debug
    • parameter examples:
      • resultTarget=debug
      • resultTarget=web
      • resultTarget=file
    • Description: The resultTarget parameter defines where and how the results should be generated. The normal target for a searchInterface for mapbender istself and a CMS will be file. The results then will be written to a a temp folder and an ajax based interface can search for the different result files to pull them to html client side.
  7. output format
    • parameter name: outputFormat
    • default value:
      • json
    • parameter examples:
      • outputFormat=json
      • outputFormat=georss - not yet implemented
      • outputFormat=iso19139 - not yet implemented
    • Description:
  8. needed CRS
    • parameter name: searchEPSG
    • default value:
      • EPSG:31466
    • parameter examples:
      • searchEPSG=EPSG:4326
      • searchEPSG=EPSG:31466
    • Description: This value allows the client to give its own actual crs value to the Search Interface. The Interface checks if the resources can deliver an output in this CRS and put this information into the result dataset.
  9. language
    • parameter name: languageCode
    • default value:
      • de
    • parameter examples:
      • languageCode=de
      • languageCode=en
    • Description: The server side can deliver the resulting metadata in different languages. The parameter doesn't have any effect on the metadata itself but on the classifications and headings
  10. responsible organization
    • parameter name: registratingDepartments
    • default value:
      • NULL
    • parameter examples:
      • registratingDepartments=1
      • registratingDepartments=2,3,4
    • Description: This is a parameter where mapbender group ids can be defined. In a geoportal many different groups have rights to publish service and other information. This groups are mapped to mapbender groups (mb_group table).
  11. registrating date 1
    • parameter name: regTimeBegin
    • default value:
      • NULL
    • parameter examples:
      • regTimeBegin='2010-01-01'
      • regTimeBegin='2010-02-12'
    • Description: This parameter allows to set a date filter
  12. registrating date 2
    • parameter name: regTimeEnd
    • default value:
      • NULL
    • parameter examples:
      • regTimeEnd='2010-01-01'
      • regTimeEnd='2010-02-12'
    • Description: This parameter allows to set a date filter
  13. actuality 1 - for searching after dataset metadata - to be implemented in a few weeks
    • parameter name: timeBegin
    • default value:
      • NULL
    • parameter examples:
      • timeBegin='2010-01-01'
      • timeBegin='2010-02-12'
    • Description: This parameter allows to set a date filter
  14. actuality 2 - for searching after dataset metadata - to be implemented in a few weeks
    • parameter name: timeEnd
    • default value:
      • NULL
    • parameter examples:
      • timeEnd='2010-01-01'
      • timeEnd='2010-02-12'
    • Description: This parameter allows to set a date filter
  15. bounding box
    • parameter name: searchBbox
    • default value:
      • NULL
    • parameter examples:
      • searchBbox='5,48,10,53'
      • searchBbox='-180.0,-90.0,180.0,90.0'
    • Description: This parameter allows to set a spatial filter - posgis is needed
  16. bounding box operation
    • parameter name: searchTypeBbox
    • default value:
      • intersects
    • parameter examples:
      • searchTypeBbox=intersects
      • searchTypeBbox=outside - postgis newer than 1.3 cause the older ones are to slow - must be activated in class_metadata_new.php
      • searchTypeBbox=inside - postgis newer than 1.3 cause the older ones are to slow - must be activated in class_metadata_new.php
    • Description: This parameter defines how the spatial filter should work - posgis is needed
  17. custom categories
    • parameter name: customCategories
    • default value:
      • NULL
    • parameter examples:
      • customCategories=1
      • customCategories=1,2
    • Description: This parameter allows a categorized search after self defined categories which are managed in the mapbender database
  18. iso 19115 topic categories
    • parameter name: isoCategories
    • default value:
      • NULL
    • parameter examples:
      • isoCategories=1
      • isoCategories=1,2,4
    • Description: This parameter allows a categorized search after the iso topic categories which are defined as a enumeration in ISO19115 and are managed in the mapbender database
  19. inspire themes
    • parameter name: inspireThemes
    • default value:
      • NULL
    • parameter examples:
      • inspireThemes=1
      • inspireThemes=1,2
    • Description: This parameter allows a search after the 34 different themes which are defined in the EU INSPIRE Directive (http://eur-lex.europa.eu/JOHtml.do?uri=OJ:L:2007:108:SOM:EN:HTML) . They are part of the mapbender database.
    • parameter name: orderBy
    • default value:
      • rank
    • parameter examples:
      • orderBy=rank
      • orderBy=id
      • orderBy=title
    • Description: This parameter allows a definition of the order of the results, if id is used, the services came back with their hierarchical structures.
  20. name of the requesting host
    • parameter name: hostName
    • default value:
      • NULL
    • parameter examples:
      • hostName=www.geoportal.rlp.de
      • hostName=geoportal.rlp
    • Description: This parameter allows the CMS Client to give the HOST to the mapbender search modules. The hostName is needed to generate the new filter links when the search is invoked by cli!
  21. requested EPSG
    • parameter name: searchEPSG
    • default value:
      • EPSG:31466
    • parameter examples:
      • searchEPSG=EPSG:4326
      • searchEPSG=EPSG:31466
    • Description: This parameter is used to request a special CRS. The search result gives information about the availability of the resource for the requested CRS!

Returned Information

WMS

  1. The search is done on WMS Content level resp.:layer-level. The layers are ranked by a monitoring function of mapbender which counts following events:
    1. the adding of wms layers to the mapbender client in the portal
    2. the GetCapabilities calls to services in the rhineland-palatinate registry - all Capabilities Documents will be served by the mapbender-registry!
    3. the loading of wmc documents in the geoportals client - the id's of the services which came from the registry will be stored in an extension of the wmc document.

WFS

WMC

Webservices

HTTP-GET

Demos

Introduction

The following examples come directly from www.geoportal.rlp.de. There are more than 200 WMS with more than 1300 layer and many WFS available. The resources came from more than 40 different departments.

Examples

WMS Resources
  1. Request for page 1 of all wms resources in the registry:
    • http://www.geoportal.rlp.de/mapbender/php/mod_callMetadata.php?searchId=test&languageCode=en&resultTarget=web
    • json pretty result
  2. Request for page 1 of all wms resources in the registry with search text niedersachsen and maxResults = 80. This example shows how the structure of the layers of a nested wms can preserved.
    • http://www.geoportal.rlp.de/mapbender/php/mod_callMetadata.php?searchText=niedersachsen&searchId=test&languageCode=en&resultTarget=web&maxResults=80
    • json pretty result
WFS Resources
WMC Resources
Result List

To integrate a mapbender registry search page in external applications or content management systems (CMS) not only the results like shown above are relevant, but there must be shown some other information about the found results. The idea is to show the following things:

  1. a header which shows the used filter for the current search
    • the header includes links to delete the actual filters
  2. a list of classifications of all results which are found by the current search
    • the classifications are stored in the mapbender database and a metadata editor allows the setting of this classifications
    • List of the classification types:
      1. ISO 19115 Topic Catagories
      2. INSPIRE Categories
      3. Custom Categories - which can be defined by the community who uses the mapbender registry


Header
Categories

Schematic example for Result Page

Whole Results

Result List

Results per class

WMS

Result List Origin
Retrieved from "http://www.mapbender.org/SearchInterface"
Views
Personal tools